OPA0 messages - VMS

This is a discussion on OPA0 messages - VMS ; I have a console cable attached from TTA0 on a DS10L to OPA0 on an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been set to NOTYPEAHEAD and on an operator console I keeping getting messages Message from user AUDIT$SERVER ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: OPA0 messages

  1. OPA0 messages

    I have a console cable attached from TTA0 on a DS10L to OPA0 on
    an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been
    set to NOTYPEAHEAD

    and on an operator console I keeping getting messages
    Message from user AUDIT$SERVER on ITANIC
    Security alarm (SECURITY) and security audit (SECURITY) on ITANIC, system
    id: 20
    58
    Auditable event: Local interactive login failure
    Event time: 7-AUG-2007 08:51:08.86
    PID: 2222F2E6
    Process name: _OPA0:
    Username:
    Process owner: [SYSTEM]
    Terminal name: _OPA0:
    Image name: $5$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
    Posix UID: -2
    Posix GID: -2 (%XFFFFFFFE)
    Status: %LOGIN-F-CMDINPUT, error reading command input

    Is there no way to leave cable connected without getting such messages?

    --
    PL/I for OpenVMS
    www.kednos.com

  2. Re: OPA0 messages



    There is a terminal characteristic... something like nointeractive


    "Tom Linden" wrote in message
    newsp.two5xh1mhv4qyg@murphus.linden...
    >I have a console cable attached from TTA0 on a DS10L to OPA0 on
    > an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been
    > set to NOTYPEAHEAD
    >
    > and on an operator console I keeping getting messages
    > Message from user AUDIT$SERVER on ITANIC
    > Security alarm (SECURITY) and security audit (SECURITY) on ITANIC, system
    > id: 20
    > 58
    > Auditable event: Local interactive login failure
    > Event time: 7-AUG-2007 08:51:08.86
    > PID: 2222F2E6
    > Process name: _OPA0:
    > Username:
    > Process owner: [SYSTEM]
    > Terminal name: _OPA0:
    > Image name: $5$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
    > Posix UID: -2
    > Posix GID: -2 (%XFFFFFFFE)
    > Status: %LOGIN-F-CMDINPUT, error reading command input
    >
    > Is there no way to leave cable connected without getting such messages?
    >
    > --
    > PL/I for OpenVMS
    > www.kednos.com




  3. Re: OPA0 messages

    FredK wrote:
    > There is a terminal characteristic... something like nointeractive


    I tried many of those characteristics, and have yet to find a totally
    fool proof way to get a terminal port to remain inactive, while being
    usable when you SET HOST/DTE to it.

    You can set it to /MODEM if the cable doesn't carry modem signals. This
    will quiesce the port. But when you need to use it, you need to allocate
    it, set term/nomodem, then set host/dte to it. Not exactly very
    fast/user friendly, especially in an emergency.

  4. Re: OPA0 messages

    In article , "Tom Linden" writes:
    > I have a console cable attached from TTA0 on a DS10L to OPA0 on
    > an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been
    > set to NOTYPEAHEAD


    [snip OPCOM message indicating a failed login attempt on OPA)]

    The /NOTYPEAHEAD setting on TTA0 will prevent console output
    from OPA0: from triggering login processing on TTA0: That is, of
    course, a good thing.

    But you're getting login processing on OPA0:

    That means two things:

    1. You're getting unsolicited input on OPA0:
    2. You have /TYPEAHEAD set on OPA0:

    You can cure the symptoms by turning off /TYPEAHEAD on OPA0:
    Unfortunately, that also breaks your console login capability in
    case the system has problems and needs intervention.

    So what you really need to figure out is why OPA0: is getting input.

    In decreasing order of estimated plausibility:

    1. You are using something like SET HOST /DTE TTA0 to monitor the
    OPA0: console. Unfortunately, SET HOST /DTE sends a carriage return
    upstream.

    I can't remember if I ever found a way to defeat that unfortunate
    behavior.

    2. You have /BROADCAST turned on on TTA0: and your broadcasts on
    TTA0: are being received on OPA0:

    Turn off /BROADCAST on TTA0:

    3. The receive wire on OPA0: is open at the TTA0: end. You are
    getting cross-talk between the pairs and seeing a garbled version
    of your OPA0: OPCOM output as OPA0: input.

    [I've seen this happen. 100-200 feet of cable that is open on the far
    end is almost as good as a loopback connector]

    Either connect that lead at TTA0 or snip it at OPA0

    4. You're getting flow control events reported from TTA0: to OPA0:
    where they are getting taken as unsolicited input.

    This is a long shot. Check flow control settings on both ends and
    make sure in particular that you don't get a ctrl-G reported back
    for unsolicited, dropped input on TTA0:


    You might also get relief by turning on /SECURE_SERVER
    and /NOAUTOBAUD on OPA0:. That should suppress login processing
    unless a spurious BREAK is received.

  5. Re: OPA0 messages

    In article , "FredK" writes:
    >
    >
    > There is a terminal characteristic... something like nointeractive


    /INTERACTIVE is the negation of /PASSALL

    /INTERACTIVE and /PASSALL are obsolete. I don't recall that they
    had any effect on the auto-activation of LOGINOUT.EXE in response
    to unsolicited input, but I suppose it's possible that there is
    such an interfaction.

    /PASSALL had the unfortunate side effect of disabling in-band flow
    control which is why it was made obsolete in favor of the less
    intrusive /PASTHRU setting.

  6. Re: OPA0 messages

    On Tue, 07 Aug 2007 10:02:34 -0700, wrote:

    > In article , "Tom Linden"
    > writes:
    >> I have a console cable attached from TTA0 on a DS10L to OPA0 on
    >> an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been
    >> set to NOTYPEAHEAD

    >
    > [snip OPCOM message indicating a failed login attempt on OPA)]
    >
    > The /NOTYPEAHEAD setting on TTA0 will prevent console output
    > from OPA0: from triggering login processing on TTA0: That is, of
    > course, a good thing.
    >
    > But you're getting login processing on OPA0:
    >
    > That means two things:
    >
    > 1. You're getting unsolicited input on OPA0:
    > 2. You have /TYPEAHEAD set on OPA0:
    >
    > You can cure the symptoms by turning off /TYPEAHEAD on OPA0:
    > Unfortunately, that also breaks your console login capability in
    > case the system has problems and needs intervention.
    >
    > So what you really need to figure out is why OPA0: is getting input.
    >
    > In decreasing order of estimated plausibility:
    >
    > 1. You are using something like SET HOST /DTE TTA0 to monitor the
    > OPA0: console. Unfortunately, SET HOST /DTE sends a carriage return
    > upstream.
    >
    > I can't remember if I ever found a way to defeat that unfortunate
    > behavior.
    >
    > 2. You have /BROADCAST turned on on TTA0: and your broadcasts on
    > TTA0: are being received on OPA0:
    >
    > Turn off /BROADCAST on TTA0:
    >
    > 3. The receive wire on OPA0: is open at the TTA0: end. You are
    > getting cross-talk between the pairs and seeing a garbled version
    > of your OPA0: OPCOM output as OPA0: input.


    No.
    >
    > [I've seen this happen. 100-200 feet of cable that is open on the far
    > end is almost as good as a loopback connector]
    >
    > Either connect that lead at TTA0 or snip it at OPA0
    >
    > 4. You're getting flow control events reported from TTA0: to OPA0:
    > where they are getting taken as unsolicited input.
    >
    > This is a long shot. Check flow control settings on both ends and
    > make sure in particular that you don't get a ctrl-G reported back
    > for unsolicited, dropped input on TTA0:
    >
    >
    > You might also get relief by turning on /SECURE_SERVER
    > and /NOAUTOBAUD on OPA0:. That should suppress login processing
    > unless a spurious BREAK is received.


    I tried NOINTERACTIVE following Fred's suggestion, but that did not
    suppress it. Have now tried NOBROADCAST, and we'll see.



    --
    PL/I for OpenVMS
    www.kednos.com

  7. Re: OPA0 messages

    In article , "Tom Linden" writes:
    > I tried NOINTERACTIVE following Fred's suggestion, but that did not
    > suppress it. Have now tried NOBROADCAST, and we'll see.


    As I've mentioned previously, /NOINTERACTIVE is synonymous with
    /PASSALL and is deprecated/obsolete.

    If you haven't already, you should probably turn /INTERACTIVE back
    on.

  8. Re: OPA0 messages

    In article , "Tom Linden" writes:
    > I tried NOINTERACTIVE following Fred's suggestion, but that did not
    > suppress it. Have now tried NOBROADCAST, and we'll see.


    I forgot one more obvious terminal setting. If the application
    you are using to read from TTA0: doesn't already do so, you will want to
    set TTA0: to /NOECHO.

    [Failure scenario: OPCOM message goes out OPA0 to TTA0
    Application reads text from TTA0:
    By default, TTA0 echos OPCOM message to OPA0:
    OPA0 sees unsolicited input and starts login sequence]

    As a diagnostic measure on the OPA0: end you could also try

    $ SET HOST /DTE OPA0

    ^\ to exit

    This may allow you to see or hear what kind of input is showing up on your
    OPA0:, possibly in response to output generated there.

  9. Re: OPA0 messages


    The expert told me earlier today... but I was in the middle of something and
    asked him to send it to me in mail (which he hasn't done yet). One of the
    attributes was SECURE SERVER but I need the rest of the magic handshake
    (including which side gets which).

    If certain people here were not so hostile, he would post himself. But he
    has essentially decided he doesn't need the grief.



    wrote in message
    news:g2zExVujADkN@eisner.encompasserve.org...
    > In article , "FredK"
    > writes:
    >>
    >>
    >> There is a terminal characteristic... something like nointeractive

    >
    > /INTERACTIVE is the negation of /PASSALL
    >
    > /INTERACTIVE and /PASSALL are obsolete. I don't recall that they
    > had any effect on the auto-activation of LOGINOUT.EXE in response
    > to unsolicited input, but I suppose it's possible that there is
    > such an interfaction.
    >
    > /PASSALL had the unfortunate side effect of disabling in-band flow
    > control which is why it was made obsolete in favor of the less
    > intrusive /PASTHRU setting.




  10. Re: OPA0 messages

    What would have been nice, and much simpler would have been a /NOLOGIN
    qualifier to SET TERM.

    This would have made it obvious that no matter what data arrives on that
    port, a login process would not be started and the port would remain
    inactive. Yet, it would still allow an application to assign a port to
    it and use the remaining characteristics properly (including type ahead
    buffer which is necessary when dealing with high speed serial lines).


    BTW, also remember that /AUTOBAUD will result in a character
    being sent out the terminal port upon the terminal driver having
    received a identifiable character (normally a carriage return) which
    then allows the terminal driver to set the proper speed on the port.

    Normally, upon completion of this, the terminal driver then starts the
    login process.

  11. Re: OPA0 messages

    See HELP SET TERM /SECURE

    It tells you to set /NOAUTO and /SECURE - at which point only a BREAK will
    cause a login attempt.



    "JF Mezei" wrote in message
    news:3dcff$46b915ea$cef8887a$21754@TEKSAVVY.COM...
    > What would have been nice, and much simpler would have been a /NOLOGIN
    > qualifier to SET TERM.
    >
    > This would have made it obvious that no matter what data arrives on that
    > port, a login process would not be started and the port would remain
    > inactive. Yet, it would still allow an application to assign a port to it
    > and use the remaining characteristics properly (including type ahead
    > buffer which is necessary when dealing with high speed serial lines).
    >
    >
    > BTW, also remember that /AUTOBAUD will result in a character being
    > sent out the terminal port upon the terminal driver having received a
    > identifiable character (normally a carriage return) which then allows the
    > terminal driver to set the proper speed on the port.
    >
    > Normally, upon completion of this, the terminal driver then starts the
    > login process.




  12. Re: OPA0 messages

    On Aug 7, 12:11 pm, "Tom Linden" wrote:
    > I have a console cable attached from TTA0 on a DS10L to OPA0 on
    > an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3.


    Has OpenVMS 8.3 been qualified on an HP zx2000 workstation?


  13. Re: OPA0 messages


    "sapienzaf" wrote in message
    news:1186535801.459656.266800@57g2000hsv.googlegro ups.com...
    > On Aug 7, 12:11 pm, "Tom Linden" wrote:
    >> I have a console cable attached from TTA0 on a DS10L to OPA0 on
    >> an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3.

    >
    > Has OpenVMS 8.3 been qualified on an HP zx2000 workstation?
    >


    No, and it never will be. Nonetheless it does work. While I haven't booted
    mine in a while, I expect it will continue to boot VMS just fine for the
    forseeable future provided I use devices that VMS supports on it.

    Unlike Alpha, where VMS "baked in" knowledge of each platform to the OS - on
    Integrity we discover the system and it's capabilities using standard
    methods such as ACPI to tell us what is on the system.




  14. Re: OPA0 messages

    Tom Linden wrote:
    >
    > On Tue, 07 Aug 2007 10:02:34 -0700, wrote:
    >
    > > In article , "Tom Linden"
    > > writes:
    > >> I have a console cable attached from TTA0 on a DS10L to OPA0 on
    > >> an HP zx2000 (900MHz/1.5MB) running OpenVMS V8.3. TTA0 has been
    > >> set to NOTYPEAHEAD

    > >
    > > [snip OPCOM message indicating a failed login attempt on OPA)]
    > >
    > > The /NOTYPEAHEAD setting on TTA0 will prevent console output
    > > from OPA0: from triggering login processing on TTA0: That is, of
    > > course, a good thing.
    > >
    > > But you're getting login processing on OPA0:
    > >
    > > That means two things:
    > >
    > > 1. You're getting unsolicited input on OPA0:
    > > 2. You have /TYPEAHEAD set on OPA0:
    > >
    > > You can cure the symptoms by turning off /TYPEAHEAD on OPA0:
    > > Unfortunately, that also breaks your console login capability in
    > > case the system has problems and needs intervention.
    > >
    > > So what you really need to figure out is why OPA0: is getting input.
    > >
    > > In decreasing order of estimated plausibility:
    > >
    > > 1. You are using something like SET HOST /DTE TTA0 to monitor the
    > > OPA0: console. Unfortunately, SET HOST /DTE sends a carriage return
    > > upstream.
    > >
    > > I can't remember if I ever found a way to defeat that unfortunate
    > > behavior.
    > >
    > > 2. You have /BROADCAST turned on on TTA0: and your broadcasts on
    > > TTA0: are being received on OPA0:
    > >
    > > Turn off /BROADCAST on TTA0:
    > >
    > > 3. The receive wire on OPA0: is open at the TTA0: end. You are
    > > getting cross-talk between the pairs and seeing a garbled version
    > > of your OPA0: OPCOM output as OPA0: input.

    >
    > No.
    > >
    > > [I've seen this happen. 100-200 feet of cable that is open on the far
    > > end is almost as good as a loopback connector]
    > >
    > > Either connect that lead at TTA0 or snip it at OPA0
    > >
    > > 4. You're getting flow control events reported from TTA0: to OPA0:
    > > where they are getting taken as unsolicited input.
    > >
    > > This is a long shot. Check flow control settings on both ends and
    > > make sure in particular that you don't get a ctrl-G reported back
    > > for unsolicited, dropped input on TTA0:
    > >
    > >
    > > You might also get relief by turning on /SECURE_SERVER
    > > and /NOAUTOBAUD on OPA0:. That should suppress login processing
    > > unless a spurious BREAK is received.

    >
    > I tried NOINTERACTIVE following Fred's suggestion, but that did not
    > suppress it. Have now tried NOBROADCAST, and we'll see.


    Someone else mentioned having TTA0 set for NOECHO so OPCOM messages, etc. don't
    bounce back and appear as unsolicited input.

    The machine doesn't read our mind; so, we have to find the right combination of
    settings to accomplish what we want.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  15. Re: OPA0 messages

    On Tue, 07 Aug 2007 11:39:23 -0700, wrote:

    > In article , "Tom Linden"
    > writes:
    >> I tried NOINTERACTIVE following Fred's suggestion, but that did not
    >> suppress it. Have now tried NOBROADCAST, and we'll see.

    >
    > As I've mentioned previously, /NOINTERACTIVE is synonymous with
    > /PASSALL and is deprecated/obsolete.
    >
    > If you haven't already, you should probably turn /INTERACTIVE back
    > on.

    NOINTERACTIVE and NOBRADCAST didn't help


    --
    PL/I for OpenVMS
    www.kednos.com

  16. Re: OPA0 messages

    JF Mezei wrote:
    > What would have been nice, and much simpler would have been a /NOLOGIN
    > qualifier to SET TERM.
    >
    > This would have made it obvious that no matter what data arrives on that
    > port, a login process would not be started and the port would remain
    > inactive. Yet, it would still allow an application to assign a port to
    > it and use the remaining characteristics properly (including type ahead
    > buffer which is necessary when dealing with high speed serial lines).
    >
    >
    > BTW, also remember that /AUTOBAUD will result in a character
    > being sent out the terminal port upon the terminal driver having
    > received a identifiable character (normally a carriage return) which
    > then allows the terminal driver to set the proper speed on the port.
    >
    > Normally, upon completion of this, the terminal driver then starts the
    > login process.


    Generally, when you have a terminal port that you don't want to log in,
    you either have to allocate it to a process or set it /notypeahead.

    Since the process might die, get deleted, or might not have started yet,
    here's what I do.

    1) During system startup (before logins are enabled):

    $ set terminal TTA0:/notypeahead/permanent

    2) Start up the control program. (This can be immediately, or on demand,
    i.e. by using set terminal/dte or Kermit or whatever. Doesn't matter
    if it is days or weeks after step 1, or only milliseconds later.)

    $ allocate TTA0:
    $ set terminal TTA0:/typeahead
    $ ! Note absence of /permanent!
    $ set host/dte TTA0:
    $ ! or Kermit or run an application

    The "allocate" and the "set terminal/typeahead" can be done with DCL
    interactively or in a command file, or can be done in a program using
    $ALLOC and $QIO with an IO$_SETMODE. (Don't use IO$_SETCHAR, that's the
    equivalent of "set term/permanent"!)

    3) When done, or the process dies, or you log off, or you deallocate the
    terminal, the permanent characteristics are automatically restored, so
    it reverts to /notypeahead.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  17. Re: OPA0 messages

    On Tue, 07 Aug 2007 20:45:08 -0700, John Santos wrote:

    > JF Mezei wrote:
    >> What would have been nice, and much simpler would have been a /NOLOGIN
    >> qualifier to SET TERM.
    >> This would have made it obvious that no matter what data arrives on
    >> that port, a login process would not be started and the port would
    >> remain inactive. Yet, it would still allow an application to assign a
    >> port to it and use the remaining characteristics properly (including
    >> type ahead buffer which is necessary when dealing with high speed
    >> serial lines).
    >> BTW, also remember that /AUTOBAUD will result in a character
    >> being sent out the terminal port upon the terminal driver having
    >> received a identifiable character (normally a carriage return) which
    >> then allows the terminal driver to set the proper speed on the port.
    >> Normally, upon completion of this, the terminal driver then starts the
    >> login process.

    >
    > Generally, when you have a terminal port that you don't want to log in,
    > you either have to allocate it to a process or set it /notypeahead.


    I had it set that way.
    >
    > Since the process might die, get deleted, or might not have started yet,
    > here's what I do.
    >
    > 1) During system startup (before logins are enabled):
    >
    > $ set terminal TTA0:/notypeahead/permanent
    >
    > 2) Start up the control program. (This can be immediately, or on demand,
    > i.e. by using set terminal/dte or Kermit or whatever. Doesn't matter
    > if it is days or weeks after step 1, or only milliseconds later.)
    >
    > $ allocate TTA0:
    > $ set terminal TTA0:/typeahead
    > $ ! Note absence of /permanent!
    > $ set host/dte TTA0:
    > $ ! or Kermit or run an application
    >
    > The "allocate" and the "set terminal/typeahead" can be done with DCL
    > interactively or in a command file, or can be done in a program using
    > $ALLOC and $QIO with an IO$_SETMODE. (Don't use IO$_SETCHAR, that's
    > the
    > equivalent of "set term/permanent"!)
    >
    > 3) When done, or the process dies, or you log off, or you deallocate the
    > terminal, the permanent characteristics are automatically restored,
    > so
    > it reverts to /notypeahead.
    >




    --
    PL/I for OpenVMS
    www.kednos.com

  18. Re: OPA0 messages


    "Tom Linden" wrote in message
    newsp.twp0vohnhv4qyg@murphus.linden...
    > On Tue, 07 Aug 2007 11:39:23 -0700, wrote:
    >
    >> In article , "Tom Linden"
    >> writes:
    >>> I tried NOINTERACTIVE following Fred's suggestion, but that did not
    >>> suppress it. Have now tried NOBROADCAST, and we'll see.

    >>
    >> As I've mentioned previously, /NOINTERACTIVE is synonymous with
    >> /PASSALL and is deprecated/obsolete.
    >>
    >> If you haven't already, you should probably turn /INTERACTIVE back
    >> on.

    > NOINTERACTIVE and NOBRADCAST didn't help
    >


    OK. From the expert:

    1) On system doing set host

    $ allocate ttax

    $ set term/perm/type/nobroadcast/alt ttax



    2) On system logging into

    $ set term/perm/noauto/secure opa0







  19. Re: OPA0 messages

    On Wed, 08 Aug 2007 06:22:43 -0700, FredK wrote:

    >
    > "Tom Linden" wrote in message
    > newsp.twp0vohnhv4qyg@murphus.linden...
    >> On Tue, 07 Aug 2007 11:39:23 -0700, wrote:
    >>
    >>> In article , "Tom Linden"
    >>> writes:
    >>>> I tried NOINTERACTIVE following Fred's suggestion, but that did not
    >>>> suppress it. Have now tried NOBROADCAST, and we'll see.
    >>>
    >>> As I've mentioned previously, /NOINTERACTIVE is synonymous with
    >>> /PASSALL and is deprecated/obsolete.
    >>>
    >>> If you haven't already, you should probably turn /INTERACTIVE back
    >>> on.

    >> NOINTERACTIVE and NOBRADCAST didn't help
    >>

    >
    > OK. From the expert:
    >
    > 1) On system doing set host
    >
    > $ allocate ttax
    >
    > $ set term/perm/type/nobroadcast/alt ttax
    >

    Does this still work if the above is opa0 instead of tta0?
    >
    >
    > 2) On system logging into
    >
    > $ set term/perm/noauto/secure opa0
    >
    >


    --
    PL/I for OpenVMS
    www.kednos.com

  20. Re: OPA0 messages

    It should. Since the line is allocated, and broadcasts are blocked - there
    should not be an issue unless you halt/crash the system and need OPA0 ;-)



    "Tom Linden" wrote in message
    newsp.twqv2nrnhv4qyg@murphus.linden...
    > On Wed, 08 Aug 2007 06:22:43 -0700, FredK wrote:
    >
    >>
    >> "Tom Linden" wrote in message
    >> newsp.twp0vohnhv4qyg@murphus.linden...
    >>> On Tue, 07 Aug 2007 11:39:23 -0700, wrote:
    >>>
    >>>> In article , "Tom Linden"
    >>>> writes:
    >>>>> I tried NOINTERACTIVE following Fred's suggestion, but that did not
    >>>>> suppress it. Have now tried NOBROADCAST, and we'll see.
    >>>>
    >>>> As I've mentioned previously, /NOINTERACTIVE is synonymous with
    >>>> /PASSALL and is deprecated/obsolete.
    >>>>
    >>>> If you haven't already, you should probably turn /INTERACTIVE back
    >>>> on.
    >>> NOINTERACTIVE and NOBRADCAST didn't help
    >>>

    >>
    >> OK. From the expert:
    >>
    >> 1) On system doing set host
    >>
    >> $ allocate ttax
    >>
    >> $ set term/perm/type/nobroadcast/alt ttax
    >>

    > Does this still work if the above is opa0 instead of tta0?
    >>
    >>
    >> 2) On system logging into
    >>
    >> $ set term/perm/noauto/secure opa0
    >>
    >>

    >
    > --
    > PL/I for OpenVMS
    > www.kednos.com




+ Reply to Thread
Page 1 of 2 1 2 LastLast