Some interactive programs, such as MCSs, temporarily assume the identity of users when performing actions on behalf of those users. To effectively behave with a particular user's identity, the interactive program might need to do more than assume a usercode. For example, if an interactive program performs actions on files, the interactive program might need to assume the FAMILY statement of the user in order to find the correct files. A program can achieve this effect indirectly by taking the following steps:
-
Temporarily assuming the usercode of the user by calling USERDATA function 3 (Validate Usercode/Password). To use this call without supplying a password, the process must have MCS status or tasking status.
To assume a usercode without specifying a password, the process must pass the usercode to USERDATA function 3 in standard form and set bits [1:2] of the qualification byte to 0. To assume a usercode when the password is also supplied, the process can pass the usercode/password combination to USERDATA function 3 in either display form or standard form.
To make it possible to interrogate the FAMILY attribute, the process must also set bit 5 of the ACTION parameter when making the USERDATA function 3 call. Bit 5 causes USERDATA to return a copy of the USERDATA entry in the data output parameter.
-
Retrieving the FAMILY value of the user by calling USERDATA function 1 (Examine User Entry), with the data input parameter set to the USERDATA entry previously returned, and the locator parameter set to USERDATALOCATOR (“FAMILY”). This call returns the FAMILY attribute of the usercode in the data output parameter.
-
Assigning the value from the data output parameter to the FAMILY attribute of MYSELF.
The following DCALGOL example demonstrates these steps.
$INSTALLATION 1
BEGIN
BOOLEAN BRSLT;
REAL RSLT;
ARRAY UDENTRY[0:255];
ARRAY UCSTANDARD[0:14];
EBCDIC ARRAY UCDISPLAY[0:2],
FAM[0:89];
REPLACE UCDISPLAY BY “JSMITH.”;
BRSLT:= DISPLAYTOSTANDARD (UCDISPLAY, UCSTANDARD);
UCSTANDARD[0].[33:2]:= 0; % Indicates no password is supplied
% Assume other usercode
RSLT:= USERDATA( 3 % Function 3:
% Validate Usercode/Password
& 1[5:1] % Copy USERDATA entry to UDENTRY
& 1[6:1], % Use standard form
MYSELF,
7, % Assume privileges of the new usercode
UDENTRY, % Returns copy of USERDATA entry
UCSTANDARD);
IF BOOLEAN(RSLT) THEN
DISPLAY(“USERDATA ERROR:” CAT STRING(RSLT.[07:07],*));
% Interrogate FAMILY of usercode
RSLT:= USERDATA( 1, % Function 1:
% Examine User-Provided Entry
, % No task variable
USERDATALOCATOR(“FAMILY”), % Fetch FAMILY attribute
FAM, % Return FAMILY value in this array
UDENTRY); % Search this USERDATA entry
IF BOOLEAN(RSLT) THEN
DISPLAY(“USERDATA ERROR:” CAT STRING(RSLT.[07:07],*));
% Assume new FAMILY value
REPLACE MYSELF.FAMILY BY FAM;
END.For the preceding example to work, the object code file must be marked with tasking status.
The $INSTALLATION 1 option in the example is necessary in order to give the DCALGOL compiler access to the DISPLAYTOSTANDARD function.
To retrieve the values of usercode attributes other than FAMILY, you could add further Function 1 calls, with different values specified for the third parameter. For example, to interrogate the IDENTITY usercode attribute, you could set the third parameter to USERDATALOCATOR (“IDENTITY”).
