|
NAME : HCPUSRBK
DESCRIPTION: SSI complex wide user attributes
DSECT : USRBK
FUNCTION : The USRBK contains the minimal information needed to
identify a user logged on somewhere in the SSI complex.
The USRBK essentially has two forms. Either embedded
within a VMDBK (for a user that is local on the
system with the VMDBK), or as a standalone block
for a user that is logged onto some other system in
the SSI complex.
LOCATED BY : USRBKs representing local users are embedded in the
user's ORIGIN VMDBK and you locate it just as you
would a VMDBK (VMDCYCLE, etc.). Clearly there is
an embedded USRBK in every VMDBK, ORIGIN or not,
and some non-ORIGIN fields do contain values (eg:
USRUSER is populated in all VMDBKs), however, the
one true embedded USRBK is in the ORIGIN VMDBK and
only its contents are maintained and considered to
be valid.
USRBKs representing non-local users are chained via
USRCHAIN off SYSUSRCH in SYSCM.
Both are in the userid hash table.
CREATED BY : USRBKs representing local users are instantiated when
an ORIGIN VMDBK is allocated. USRBKs representing a
non-local user are allocated by HCPUSR when it is
notified a user has logged onto a remote system.
DELETED BY : USRBKs representing local users are deleted when an
origin VMDBK is fret'ed (either the user has logged
off or been relocated off). USRBKs representing a
non-local user are deleted by HCPUSR when the
user logs off or has been migrated in.
REFERENCES : VMDBK
SERIALIZED : Deletion of the remote USRBKs is by MP defer.
A USRBK pointer is only valid until the next
loss of control.
COMPATIBILITY AND MIGRATION CONCERNS : If the format of this
control block changes in future releases be sure
to increment the version counter. Any changes
to the global portion must be done in an upwardly
compatible manner and added to the end (it's OK
to push the local section if need be).
RELOCATION CONSIDERATIONS : None. This block exists on each
system in the SSI complex and is not relocated
between systems.
COMMENTS : The USRBK is divided into two parts as it were.
The first part is data that is global (eg: should be
same on all systems) and will be included anytime
the block is broadcast (such as userid, the block
version, etc.). Clearly the block version may
not be the same on each system, but it must be
broadcast so each system knows what it's dealing
with. The system where the user is logged onto
determines the block's level. If it's a downlevel
system, the uplevel systems won't find anything
of value in the new fields (and should be checking
the version before looking). If it's an uplevel
system the downlevel systems won't know enough to
look at any new stuff. The second part is data
that will be local to the system the USRBK is on
(eg: chain pointer, etc.).
If the USRBK is embedded in the VMDBK the address
of the VMDBK may be divined by NILL against the
USRBK address with the USRtoVMD mask. Likewise a
routine can accept either a VMDBK or a USRBK as a
parameter and divine which it was passed by doing
a TMLL with USRorVMD (CC 0 means you have a VMDBK).
The above scheme assumes that a VMDBK always
starts on a page boundary and that a USRBK never
starts on a page boundary. A standalone block
can never start on a page boundary as it will
always have a free storage header preceding it.
An embedded USRBK could only start on a page
boundary if it was the first field in a VMDBK.
A CKMAINT in HCPUSR verifies it's not.
If you have a known USRBK pointer you can
determine whether it's a standlone USRBK (that is
to say represents a non-local user) or an embedded
USRBK (that is to say a local user) by doing a
TM USRLFLAG,USRVMDBK. If CC 3 is returned then,
as noted above, NILL with USRtoVMD gives you the
VMDBK address for the local user.
| |