🚀 go-pugleaf

The definition of LU-6.2 is found in GC30-3084, "SNA Transaction
Programmer's Reference Manual for LU Type 6.2" (the TPRM), SC31-6808,
"SNA LU-6.2 Reference: Peer Protocols" (the LU-FAP), and GA27-3136,
"SNA Formats".

The TPRM describes (in concrete terms) the abstract "protocol boundary"
that must be provided by anything which claims to implement 6.2, the
LU-FAP describes in detail how the various LU-6.2 functions are mapped
into SNA message Formats And Protocols (hence "FAP"), and SNA Formats
is a reference manual for all headers, message formats, and sense codes.

"Security" is an odd entity, in that it is managed from outside of the
LU (e.g., by something like RACF), yet the LU or some agent acting on
behalf of the LU has to be involved in policing security.  The most
obvious case is the passing of a user-ID and password on the FMH-5
(ATTACH) header.

The TPRM doesn't mention password management aside from a couple of
obscure operator commands that can be used to force signed-on users off
the system.  The reason is that password management is an application
function, so is technically outside of the LU.  However, the LU-FAP
documents a "system" transaction program (application) that is to be
used for managing passwords.  This application would use the standard
LU-6.2 interface (allocate, send-data, et al.), plus would presumably
have some sort of interface to the "external" security manager (e.g.,
RACF) so that, when asked nicely, it could effect a password change.

I'm not very familiar with the VTAM macros, so I don't know what they
provide (except to know that they have to provide the functions that
are mandated in the TPRM).  "Sign-on" is a recently-introduced feature
used to reduce the frequency that passwords have to flow over the wire
in the ATTACH headers.  Assuming that sign-on is supported, one can
send in a special "sign-on" transaction that provides your user-ID and
password; then, on subsequent ATTACHes, the password can be omitted
since the user is "already signed-on".  Signing-on is supposed to be
taken care of automagically by the LU, with the transaction programs
unaware of what is going on "under the covers" -- hence, the lack of
any explaination in the TPRM.  You merely specify "SECURITY=SAME" on
your ALLOCATEs, and leave the rest up to the implementation.  Or
something like that...

There are a handful of "architected" system transaction programs (STPs)
whose behavior is defined by the LU-FAP or by APPN Networking.  All of
these have "illegal" names that start with a x'06' (I believe) followed
by a few digits.  Examples are Change Number of Sessions (CNOS), Resync,
and Sign-On.

      John Pershing
      IBM Research, Yorktown Heights, NY