Odd character in NTY unit numbers - VMS

This is a discussion on Odd character in NTY unit numbers - VMS ; We have found an odd character (%X4) in NTY unit numbers when going from 3 to 4 digits, e.g. NTY999: to NTY1000: $ term = f$getjpi("","terminal") $ show symbol term TERM = "NTY1000.:" That 'dot' between the last zero and ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Odd character in NTY unit numbers

  1. Odd character in NTY unit numbers

    We have found an odd character (%X4) in NTY unit numbers when going
    from 3 to 4 digits, e.g. NTY999: to NTY1000:

    $ term = f$getjpi("","terminal")
    $ show symbol term
    TERM = "NTY1000.:"

    That 'dot' between the last zero and the colon is a hex 4. The
    environment is VMS V7.3-2 fully patched and Multinet V5.1 fully
    patched.

    We tried this on a VMS V8.3 system with Multinet V5.2a, both fully
    patched, and it does not occur there.

    We can work around this by doing something like this:

    $ badchar[0,8] = %X4
    $ term = f$getjpi("","termina') - badchar

    However, a lot of users have something like a SET DISPLAY in their
    respective LOGIN.COM files plus use the terminal name in other
    procedures. It would be difficult and painful to try and track all of
    these down to add this workaround.

    I checked the readme files on Process Software's download site but
    nothing obvious showed up as addressing extraneous characters in
    larger unit numbers.

    We do have the option of upgrading from Multinet V5.1 to V5.2a if that
    will sove the problem. We do not have the option of upgrading VMS.

    Have any of you see this before? If so, what did you do to fix it?

  2. Re: Odd character in NTY unit numbers

    On Apr 22, 10:34 am, VMS is Virus Free wrote:
    > We have found an odd character (%X4) in NTY unit numbers when going
    > from 3 to 4 digits, e.g. NTY999: to NTY1000:
    >
    > $ term = f$getjpi("","terminal")
    > $ show symbol term
    > TERM = "NTY1000.:"
    >
    > That 'dot' between the last zero and the colon is a hex 4. The
    > environment is VMS V7.3-2 fully patched and Multinet V5.1 fully
    > patched.
    >
    > We tried this on a VMS V8.3 system with Multinet V5.2a, both fully
    > patched, and it does not occur there.
    >
    > We can work around this by doing something like this:
    >
    > $ badchar[0,8] = %X4
    > $ term = f$getjpi("","termina') - badchar
    >
    > However, a lot of users have something like a SET DISPLAY in their
    > respective LOGIN.COM files plus use the terminal name in other
    > procedures. It would be difficult and painful to try and track all of
    > these down to add this workaround.
    >
    > I checked the readme files on Process Software's download site but
    > nothing obvious showed up as addressing extraneous characters in
    > larger unit numbers.
    >
    > We do have the option of upgrading from Multinet V5.1 to V5.2a if that
    > will sove the problem. We do not have the option of upgrading VMS.


    I have a fully patched 7.3-2 system with MultiNet v5.2A (fully
    patched) and the problem exists there too. I've logged a critical bug
    with Process Software and am awaiting a response from them.

    The problem is uglier than just parsing out the NTY device - it also
    marks the terminal as "disconnected" and won't accept a broadcast
    reply.

    .../Ed

  3. RE: Odd character in NTY unit numbers

    HP was eventually able to reproduce this problem with TCP/IP services
    and determined the cause to be an error in VMS732_LOGIN-V0100.

    -----Original Message-----
    From: ewilts@ewilts.org [mailto:ewilts@ewilts.org]
    Sent: Friday, May 09, 2008 2:45 PM
    To: info-multinet@process.com
    Subject: Re: Odd character in NTY unit numbers

    On Apr 22, 10:34 am, VMS is Virus Free wrote:
    > We have found an odd character (%X4) in NTY unit numbers when going
    > from 3 to 4 digits, e.g. NTY999: to NTY1000:
    >
    > $ term = f$getjpi("","terminal")
    > $ show symbol term
    > TERM = "NTY1000.:"
    >
    > That 'dot' between the last zero and the colon is a hex 4. The
    > environment is VMS V7.3-2 fully patched and Multinet V5.1 fully
    > patched.
    >
    > We tried this on a VMS V8.3 system with Multinet V5.2a, both fully
    > patched, and it does not occur there.
    >
    > We can work around this by doing something like this:
    >
    > $ badchar[0,8] = %X4
    > $ term = f$getjpi("","termina') - badchar
    >
    > However, a lot of users have something like a SET DISPLAY in their
    > respective LOGIN.COM files plus use the terminal name in other
    > procedures. It would be difficult and painful to try and track all of
    > these down to add this workaround.
    >
    > I checked the readme files on Process Software's download site but
    > nothing obvious showed up as addressing extraneous characters in
    > larger unit numbers.
    >
    > We do have the option of upgrading from Multinet V5.1 to V5.2a if that
    > will sove the problem. We do not have the option of upgrading VMS.


    I have a fully patched 7.3-2 system with MultiNet v5.2A (fully
    patched) and the problem exists there too. I've logged a critical bug
    with Process Software and am awaiting a response from them.

    The problem is uglier than just parsing out the NTY device - it also
    marks the terminal as "disconnected" and won't accept a broadcast
    reply.

    .../Ed

+ Reply to Thread