Phone Utility

[The Brit]

Thanks to Volker, for supplying a link to an old thread which didn't come up, or which I must have missed, on my original search.

Dave

[Volker Halle]

Dave,

I believe, I've found the real error in the PHONE utility. If you have a support contract with HP, please consider to log a call:

There is a $GETJPI call in [PHONE]LINKSUBS, which specifies - among others - the following item code:

...
word(7),word(jpi$_terminal),
long(term_number+8),
long(term_number)
...

The '7' is supposed to be the output buffer length for the terminal name (TNAxxxx will fit, but TNAxxxxx will NOT !). And the term_number in this routine is only 7 bytes long, so this cannot be easily fixed by PATCH

The OpenVMS V8.3 Release notes describe the the change of the field PCB$T_TERMINAL from 8 to 16 bytes in V8.2. It also suggests to increase the buffer specified for the JPI$_TERMINAL item code to 16 bytes !

So fixing this bug in PHONE would be a nice task for an OpenVMS engineering newhire after his first lesson in BLISS ;-)

Volker.

[Volker Halle]

Dave,

this can be PATCHED !

$ PATCH X.EXE ! a private copy of PHONE.EXE
PATCH>exa 800+124
00000924: 00000007
PATCH>dep/long .=8
old: 00000924: 00000007
new: 00000924: 00000008
PATCH>update
%PATCH-I-WRTFIL, updating image file X.EXE;2
PATCH> EXIT

This static data is in an OCTAWORD aligned PSECT:

.PSECT $OWN$, OCTA, NOPIC, CON, REL, LCL, NOSHR,-
NOEXE, RD, WRT
USER_NAME:
010C .LONG X^C ; .LONG 12
0110 .LONG USER_NAME+8
TERM_NUMBER:
0124 .LONG X^7 ; .LONG 7
0128 .LONG TERM_NUMBER+8
PATH_LIST:
0134 .SIGNED_WORD X^0 ; .SIGNED_WORD 0

At offset 0x0124, you'll find the '7' for the buffer length. The address of the start of the TERM_NUMBER buffer can be found at offset 0x0128. The string buffer itself starts at 0x012C. Due to the OCTAword alignment, the buffer is actually 8 bytes long not 7 bytes ! The next data structure starts at 0x0134. So all that needs to be done is change the '7' to '8', to at least provide a buffer of 8 characters for the TERM_NUMBER, so that TNAxxxxx will fit ! To find the longword '7' at offset 0x0124, you'll have to DUMP PHONE.EXE and look for '00000007' at offset 0x124 inside a block. For me, this is VBN 5. You can easily verify, that you've found the correct block, if there is a '0000000C' at offset 0x010C in the same block.

Feel free to give it a try, you will have to INSTALL REPLACE the patched PHONE.EXE...

The usual disclaimer: use at your own risk ;-)

Volker.

[Hein van den Heuvel]

Rainy Saturday afternoon...

>> And the term_number in this routine is only 7 bytes long, so this cannot be easily fixed by PATCH

The bliss compiler of course aligned the next variable, so there are actually 8 bytes available :-)

A patch would be restricted to 2(4) relatively easy recognizable words:
- the 7 in the descriptor
- the 7 in the getjpi item list.

Dump and search for " 00000007 00000000" and
for 031D0007 :-)

00000000 004C .LONG USER_NAME
0004 0050 .SIGNED_WORD X^4 ; .SIGNED_WORD 4
0303 0052 .SIGNED_WORD X^303 ; .SIGNED_WORD 771
00000000 0054 .LONG PARENT_PID
00000000 0058 .LONG X^0 ; .LONG 0
0007 005C .SIGNED_WORD X^7 ; .SIGNED_WORD 7
031D 005E .SIGNED_WORD X^31D ; .SIGNED_WORD 797
00000008 0060 .LONG TERM_NUMBER+8
00000000 0064 .LONG TERM_NUMBER

:

00000007 0124 .LONG X^7 ; .LONG 7
00000008 0128 .LONG TERM_NUMBER+8
PATH_LIST:
0000 0134 .SIGNED_WORD X^0 ; .SIGNED_WORD 0


Also, in module MISCCMDS the terminal length was actually increased from 7 to 9. Too bad they did not cover all at that time.

! V04-001 ROP0040 09-OCT-1984
! Extend field for terminal name from 7 to 9 in
! directory listing.
!

Hein.

[Volker Halle]

Early sunny sunday morning over here ;-)

There are actually 4 different places in PHONE, where the terminal name is being obtained using $GETJPI and a JPI$_TERMINAL item code:

- BASICCMDS using a buffer length of 7
- LINKSUBS using a buffer length of 7
- MISCCMDS using a buffer length of 9
- TERMINAL using a buffer length of 64 - WOW !

The first 2 occurences could easily be found and patched with PATCH.

I'll report this, when 8.4 fieldtest finally comes around...

Volker.

[Ian Miller.]

I've entered a note about this but it should be reported as a bug sometime.

[The Brit]

I have reported the bug, and a Case # has been assigned. If anyone is interested,

#4606766618

The prognosis is however, understandably poor. Given the (apparently) low interest in the utility accross the community, the priority of the fix is also very low.


Thanks to all who contributed, particularly Volker and Hein.

Dave.

[Robert Brooks_1]

The prognosis is however, understandably poor. Given the (apparently) low interest in the utility accross the community, the priority of the fix is also very low.


--

I'd keep pushing this until you get a fix.

Given that V8.4 has just (or is about to) go out for field test, and this problem is quite
nicely bounded and easily verified, I'd push to have this fix included in the V8.4 final kitting.

Even that proves to be more difficult than it should be, getting a fix backported to 8.3 and -1H1 should not take a long time.

Ask your HP contact when you will be getting a fix.

-- Rob

[Volker Halle]

Dave,

and I have raised PTR 75-123-2 against OpenVMS E8.4 fieldtest and described the source code statements that need to be fixed.

Volker.

[Volker Halle]

Dave,

I have received and tested a new PHONE image for OpenVMS E8.4 and the problem with device unit numbers > 9999 has been solved with this image. Let's hope that this fix will finally show up in V8.4

Volker.