Off-the-wall TCPware/Multinet Question - VMS

This is a discussion on Off-the-wall TCPware/Multinet Question - VMS ; Y'all need a good laugh? I've been musing over the various problems we've had of late and was wondering if there's any way to combine the various elements of TCPware, Multinet and "UCX" to get the best of all of ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Off-the-wall TCPware/Multinet Question

  1. Off-the-wall TCPware/Multinet Question

    Y'all need a good laugh?

    I've been musing over the various problems we've had of late and was
    wondering if there's any way to combine the various elements of TCPware,
    Multinet and "UCX" to get the best of all of them.

    UCX's scalable kernel seems best suited to the environment at work where
    poorly-designed application software beats the living daylights out of
    the network. With Multinet, every packet sent is a PHY_IO and thus
    generates an interrupt. This pushes CPU Utl. and interrupt time through
    the roof.

    In both UCX and TCPware, TELNET processes are created by the Job
    Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    logins become possible immediately after Multinet is started, even
    before the startup process has finished (applications may not be ready
    for logins, user disks may not be MOUNTed yet, ...).

    Multinet's printing seems the easiest to manage and understand. By
    contrast, the very UN*X-ly UCX$PRINTCAP.DAT (TCPIP$PRINTCAP.DAT) method
    is as bad - or worse - than UN*X.

    Ideally, I'd like to see the TCP/IP realm of OpenVMS outsourced to
    Process Software.

    Realistically, I'd just like to know if there's any way to bring it all
    together.

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

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

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

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

    Coming soon:
    Unofficial OpenVMS Marketing Home Page

  2. Re: Off-the-wall TCPware/Multinet Question

    David J Dachtera wrote:


    > In both UCX and TCPware, TELNET processes are created by the Job
    > Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    > has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    > Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    > logins become possible immediately after Multinet is started, even
    > before the startup process has finished (applications may not be ready
    > for logins, user disks may not be MOUNTed yet, ...).



    There may be a solution for this one. After UCX startup, you could add
    $ SET LOGIN /INTERACTIVE=1
    $ SET LOGIN /INTERACTIVE=0
    This will at least allow users with OPER privilege to login from this
    point on, while keeping standard users away from the system until the
    startup driver allows logins as usual.

    Hope this helps,
    --
    ------------ speaking only for myself ------------
    Hans Bachner E-Mail: Hans.Bachner@hp.com
    HP Services / Consulting & Integration
    Hewlett-Packard Ges.m.b.H. Linz / Austria

  3. Re: Off-the-wall TCPware/Multinet Question

    In article , Hans Bachner writes:
    >David J Dachtera wrote:
    >
    >> In both UCX and TCPware, TELNET processes are created by the Job
    >> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    >> has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    >> Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    >> logins become possible immediately after Multinet is started, even
    >> before the startup process has finished (applications may not be ready
    >> for logins, user disks may not be MOUNTed yet, ...).

    >
    >
    >There may be a solution for this one. After UCX startup, you could add
    >$ SET LOGIN /INTERACTIVE=1
    >$ SET LOGIN /INTERACTIVE=0
    >This will at least allow users with OPER privilege to login from this
    >point on, while keeping standard users away from the system until the
    >startup driver allows logins as usual.


    And I thought DJD meant it the other way.
    No login for Multinet TELNET until SET LOGIN is done (eg. in SYSTARTUP_VMS)
    and not as early as now (when maybe even disks are still unmounted)...

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  4. Re: Off-the-wall TCPware/Multinet Question

    Peter 'EPLAN' LANGSTOEGER wrote:
    >
    > In article , Hans Bachner writes:
    > >David J Dachtera wrote:
    > >
    > >> In both UCX and TCPware, TELNET processes are created by the Job
    > >> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    > >> has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    > >> Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    > >> logins become possible immediately after Multinet is started, even
    > >> before the startup process has finished (applications may not be ready
    > >> for logins, user disks may not be MOUNTed yet, ...).

    > >
    > >
    > >There may be a solution for this one. After UCX startup, you could add
    > >$ SET LOGIN /INTERACTIVE=1
    > >$ SET LOGIN /INTERACTIVE=0
    > >This will at least allow users with OPER privilege to login from this
    > >point on, while keeping standard users away from the system until the
    > >startup driver allows logins as usual.

    >
    > And I thought DJD meant it the other way.
    > No login for Multinet TELNET until SET LOGIN is done (eg. in SYSTARTUP_VMS)
    > and not as early as now (when maybe even disks are still unmounted)...


    Quite.

    Little known stuff: Until a SET LOGINS/INTER=n is done, the Job
    Controller will not create interactive processes.

    So doing as he suggests gives UCX the "Multinet Blues".

    What I need is for Multinet to acquire the TCPware/UCX talent of handing
    that off to JBC instead of MULTINET_SERVER doing the $CREPRCs.

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

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

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

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

    Coming soon:
    Unofficial OpenVMS Marketing Home Page

+ Reply to Thread