SWAP
----

SWAP makes one user look like another.  It requires SYSPRV and CMKRNL to
run.  It is handy for a privileged user to do some work in another user's
account, and then return to their own account.  It changes username and
account, UIC, privileges, default device and directory, and process name,
but does not alter quotas as yet.  It is invoked as a foreign command
with the username as the parameter.  If this is null, it homes-in on a
predefined account.  SWAPBUILD.COM builds this program.


						Chris Chaundy
						Melbourne State College
						c/- Computer Centre
						University of Melbourne
						Parkville, Victoria. 3052
						Australia

V4.0 Update
-----------
						James G. Downward
						KMS Fusion, Inc.
						P.O. Box 1567
						Ann Arbor, Mich 48106
						(313)-769-8500

V4.0 blew SWAP out of the water.  However, I find it so useful for manageing
my system and helping out users, that I decided I just could not live without
it.  So, here is a V4.x compatible version of SWAP.

Not as clean as it could be, but it works, probably better than before. This
time arround SWAP also assigns both SYS$DISK, SYS$LOGIN and SYS$LOGIN_DISK
since V4.0 seems to want it. This means you can SWAP to an account and DECalc
will find the right HOOxxx file and if you use MAIL, you read their MAIL,
not yours! 

SWAP users a new UAFDEF.FOR.  Most offsets seem correct, but please note that the
string offsets which had to be adapted to start at (2:) are suspicious.  Either
UAFDEF.FOR is wrong, or the V4.0 conversion account conversion utility placed
the fields in the wrong place by 1 (or $UAFDEF.MAR is in error).   Or possibly
the command procedure used to auto-create the $UAFDEF.MAR is wrong in a way I
do not understand. Note some fields in UAFDEF.FOR seem right even though they
come after the fields in question. 

To be realy nice, SWAP should do the place logical assignments in the proper
tables in the correct modes (ie /EXEC etc.). However, that is too much trouble
to worry about now.  Just getting it running on V4.0 was enough of a bother. 

Please also note, the wierdness which had to be done in order to get the
OPEN/READ statement to read in a UAF record.  I realy don't know what V4.0
Fortran is doing.  V4.1 fixed one of the bugs but I am no longer sure if that
is the only problem. The FDL file (SYSUAF.FDL) says the records are 1412 bytes
long, but I kept getting back a Record-too-short-for-User's-Buffer error until
I put in the ERRSET and ERR= transfer. 

Good Luck.