Hi Peter,
There is no code in the 5250 protocol that means "signon" either, yet
there is an auto-signon feature in iSeries Access.
Actually there is. There are Telnet VARs and USERVARs that you can send
as part of the session setup to auto-sign on. For details, see RFC 2877
http://www.faqs.org/rfcs/rfc2877.html
In the TN5250 software you linked to (which James Rich, myself, and
several other people helped to develop) you can set up auto-signon using
keywords in the tn5250rc file
ssn {
host = as400.example.com
env.DEVNAME=DSP01
env.USER=klemscot
env.IBMSUBSPW=bigboy
env.IBMPROGRAM=QCMD
env.IBMIMENU=MAIN
env.IBMCURLIB=QGPL
}
Now when you invoke "tn5250 ssn" it'll connect to that host, set up a
device named DSP01, and sign on as userid=klemscot, password=bigboy,
pgm=QCMD, menu=MAIN, CURLIB=QGPL... replacing the need to enter
anything in the signon screen fields.
In fact, I often use this capability when I run into a software company
that needs access to my system. Rather than make them sign on, etc, I
e-mail them a little installation prgoram that installs TN5250 with all
the needed settings, they just double-click the icon and boom, they're
signed on.
Naturally, they're confused about how they signed on without typing
anything... which still amuses me, after all these years.
I believe there is a system request code that can be sent even when the
> session is input-inhibited, and option 90 from there could be used to
> signoff.
Yes. Unless they're already at SysReq screen (in which case, you can't
hit system request again). Or the administrator has disabled option 90
from that menu.
Plus, of course, signing off from the SysReq menu is probably just as
dangerous as closing the window without first signing off.
The real problem isn't with how people sign off... it's with the way
that the programs are written. Every interactive program should be
designed to look for the user disconnecting, and handle shutdown of the
code gracefully. It should be part of the programmer's testing regimen,
and should be part of QA's testing as well.
But, we're still trying to convince people to stop writing code for the
S/36 environment. Or for the (only slightly more modern) RPG III
programming language. System i programmers don't ever want to change or
learn anything new -- so we're stuck with what we have today.
midrange.com
