|
The CFS test routine (USRMOD module) will be executed following each mask entry in order to check the input. In this way, certain CFS functions can be made available to a restricted set of users. The check on whether or not a CFS function is valid for a user, is partially controlled by tables. The tables to be modified by the system administrator can be found in the data section of the USRMOD test routine. The assembler source code of USRMOD (supplied in CFS.S.LMSLIB) can be modified by the CFS system administrator.
Description of the test tables
A test table in USRMOD exists for each mask input field:
Selection mask
Filename-Select field TAB01
User-Id field TAB02
.........
Variable Action field TAB0C
File list/CFS Editor mask
CFS commands TAB10
Action Codes TAB11.
All user data input into a CFS mask field will be checked against the entries in the respective table. If a match is detected, the userid table (see below) will decide whether or not the entry is allowed for this particular user or not (Authority Reject).
The test tables are constructed as follows:
The table header contains a default indicator which determines the course of action in the event of the actual input not being contained in the table (entry is either accepted or rejected). After the header, the table may contain any number of elements which will be compared against the attempted input.
Table element structure
DC AL1(len) Total length of the following table element.
DC C'ind' Indicator
C'_' The following string is a valid input.
C'-' The following string is not a valid input, and results in an Authority-Reject.
C'R' A user-specific code for processing this entry will be executed. The four byte address of the subroutine to process the entry must follow C'R'.
DC AL4(Special routine) Only if ind = C'R': Address of a subroutine within USRMOD
which will be activated in the event of the input specified
below being encountered.
DC AL4(Userid Tab) Optional address of an alternative userid table for the current
entry (Userid table function: see below).
DC C'string' Input string.
An asterisk, '*' , will be interpreted as a wildcard character, meaning that that position in string may contain any character. For example, C'OC*' means that the user may enter OC0, OC1, ..., OC9.
Userid Tables
In addition to test tables for the user input, there are also userid tables. A userid table contains a group of userids. If the data entered by the user in a mask field corresponds with an entry in one of the above test tables, the userid table will determine whether that entry is allowed for the current userid, or not (--> Authority-Reject). At the beginning of each userid table is a default indicator. This determines what should happen if CFS is called from a userid that does not exist in the table (accept or reject the entry).
In addition to the userids in the standard userid table, any number of other userid groups can be defined in so-called alternative userid tables. In theory, each input data sample in a test table can have a userid table associated with it.
Activating the USRMOD testing
For performance reasons, the USRMOD test routine is not activated by default. To activate USRMOD, an 'X' should be entered in column 49 of the 4th PAM block of the CFS load module.
Another way of activating USRMOD, and also of modifying a large number of other CFS installation parameters, is by amending the assembler source program CFSMAIN in CFS.S.LMSLIB. The remark asterisks in front of the MVI/MVC statements need only be removed. The modified CFSMAIN is then assembled using the /DO CFS.S.LMSLIB(ASSEMB) procedure, and then linked using the /DO CFS.S.LMSLIB(CFSLNK) procedure to produce a new program phase.
Summary
Using the USRMOD test routine, the system administrator can define a number of data input possibilities. For each of these entries, a group of userids can be defined, for which the input is allowed, or rejected (Authority-Reject).
Since all user input can be passed through the USRMOD test routine before being interpreted and executed by CFS, it can also be amended from within USRMOD.
Data security is achieved under CFS via the measures described below.
Opening a Connection: When BS2000 requests a Logon Password, (PLEASE ENTER PASSWORD), this password will not be stored in the command memory of the Connection.
When entering a LOGON command together with a password following OCn and 'PLEASE LOGON' , the password will be overwritten with C'SSS' in the command memory.
Individual command memory entries, such as PASSWORD commands, can be explicitly deleted by the user. This is achieved when scrolling back through the memory by pressing the K3 key.
Connections: LOG files, created with a LOG file command under CFS, are, by default, not shareable. If the LOG function is invoked from a subtask, or from another userid on another host, the LOG file will always be created under the home userid, i.e. that userid from which CFS was initially loaded.
LOCK: Lock the screen during temporary user absence.
LOCK [passw] The screen from which CFS was loaded will be locked until the user enters the previously-defined password in a blanked field. This allows a user to leave CFS loaded while being sure that no unauthorised person could use CFS.
If passw is not specified in the LOCK command, then the last password to have been defined via SPL, or via LOCK [passw] will be valid.
SPL [passw] Set Password for Lock.
A password to be used for a later LOCK command is set. If passw in omitted from the SPL command, it will be requested in a blanked field.
Data security measures using USRMOD/CFSMAIN
CFS provides the system administrator with various options to control, to monitor, and in certain cases, to restrict the behaviour of the user under CFS.
An example of controlling user input is provided by the USRMOD test routine. Any installation-specific rules can be enforced by including them in the source code of the USRMOD test routine. USRMOD must be re-assembled, and stored in CFSLIB. In addition, an indicator needs to be set in the CFS phase (see the CFSMAIN source program in CFS.S.LMSLIB) to cause CFS to call the USRMOD routine.
Modify PAM files only after entering a password
If the user is working with CFS under a userid other than TSOS, and wishes to modify (Modify command) a PAM file, a password must first be entered. This is done in a blanked field, maintained internally by CFS, and controlled by the system administrator. This CFS-internal password needs to be entered in the USRMOD source code at the relevant point. Following two unsuccessful attempts to enter the password, the function is rejected (Authority-Reject). To activate the R100 password request routine, remove all '*2*' remark statements from TAB10 of USRMOD. The R100 routine can then be amended, such that a password will be expected to match particular names entered in a table.
Prevent file selection with FSTAT $userid. in the FILENAME-SELECT field
If the user is working under a userid other than TSOS, and attempts to select files by entering FSTAT $userid or FSTAT :x:$userid in the FILENAME-SELECT field, CFS will reject this request. To activate the R300 routine to check the Filename-Select entry for FSTAT followed by a '$' character, '*3*' remarks should be removed from all statements in TAB01 of USRMOD.
Prevent file selection from certain foreign userids from the USER-ID field
If the user is working under a userid other than TSOS, and attempts to select files by entering a "prohibited" userid in the USER-ID field (defined in the R400TAB table), CFS will reject this request. To cause the R400 routine to check the USER-ID entries, the '*4*' remarks should be removed from all statements in TAB02 of USRMOD.
Virtual terminal names for Connections based on the physical station names
By default, CFS constructs the virtual station name for a Connection as follows:
CFS n xxxx.
n is the Connection number, specified in the OC command (0 <= n <= 9). xxxx is the TSN from which CFS was loaded. This virtual terminal name bears no direct relationship to the physical station linked to the subtask (i.e. the physical station from which CFS was loaded).
To establish a clearer relationship between subtasks opened under CFS and the respective physical terminal, a subroutine (R200) in the USRMOD module has been provided.
It is assumed that a terminal name will always have, at some point in the 8 character name, one or two fixed characters. These are redundant, and do not serve to differentiate between terminals. They are normally used as a prefix to identify device types. The portion after this prefix is usually a sequential number which identifies the station uniquely.
Assume that the names of all terminals are as follows: DSSxxxxx. xxxxx is the sequential part of the designation which identifies the station uniquely.
The R200 routine in the USRMOD module will create the virtual terminal names to be used in subtasks according to the following rules: the original station name DSSxxxxx will be amended to #nSxxxxx, i.e. the first two characters of the prefix from the original name, 'DS', will be replaced by '#n', whereby n is the Connection number.
The R200 routine will also replace a station name specified explicitly by the the user in the OC command with a name created from the above rules. The user thus cannot specify a virtual terminal name for a CFS subtask. This enforced naming convention has the further advantage that CFS may be loaded again from Connection n. However, a nested Connection n may not be opened from this CFS Level 1 with OCn, since the same station name would be created.
This station name substitution normally only takes place under Connections to $DIALOG. The user can specify a station name generated in the KDCFILE for UTM Connections as normal. Substitution of terminal names can also be enforced for Connections to UTM, $CONSOLE and DCAM applications by removing a remark asterisk from the USRMOD subroutine.
Restricting subtasks under CFS, described below, is not dependent on the USRMOD test routine.
Restricting the maximum number of subtasks
By modifying the CFS phase (see also the CFSMAIN source code in CFS.S.LMSLIB), the maximum number of subtasks that can be opened under CFS may easily be restricted.
The maximum number of open Connections may be set by entering a value n (0 <= n <= 9) in the 6th PAM page, column 48, of the CFS phase. TSOS is not restricted in this way.
n can also be specified as an initialisation parameter in the CFSMAIN module.
Example: By entering a value of 2, a maximum of 2 Connections may be opened simultaneously. For example, 1 and 2, or 3 and 9. The number of open Connections is limited, not the actual Connection number.
Rejection of Nested Connections
A nested Connection is one opened by CFS, which itself is running as a subtask under a Connection.
Modifying the CFS phase at the 6th PAM page, column 40 to C'N' will ensure nested Connections cannot be opened.
Exit from a Connection only at Input Request
To prevent Connections causing data stagnation problems, it can be ensured that users only terminate Connections when no further asynchronous messages are expected. This is achieved by allowing the user to terminate a Connection only at an input request. Column 67 of the 6th PAM page of the CFS phase should be amended to C'X'.
Monitor Open Connection Requests with a Terminal File
The system administrator can create a central file, $TSOS.CFSTERM, with Fcbtype=Sam and Recform=V. The contents of this file can be used to determine from which userids or terminals Connections may be established, to which applications, on which host computers, and to which userids.
CFSTERM may contain 3 different types of check records.
- Regular Check Records
- Default Records
- Common Records
Regular Check Records are constructed as follows:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1U2U2U2U2U3U3...
When creating a TERMFILE, a record like this can be entered as the first record. This will serve as a scale line, and will help in editing the file. It will be ignored by CFS.
The individual fields are constructed as follows:
UUUUUUUU Userid. This field will be compared with the userid under which CFS was loaded. If this field contains blanks, then the userid from which CFS was loaded is irrelevant (i.e. the "comparison result" will always be positive). A wildcard '*' can be entered in any position. This will cause that position to be ignored for comparison purposes.
X then U...U Selection indicator.
x = Space Positive selection. The comparison result will be positive if U...U matches the userid, or if U...U contains blanks or '********' .
x = '-' Negative selection. The comparison result will be positive if U...U does not match the userid under which CFS was loaded.
BB Special indicator for U...U
BB = 'P ' U...U contains the name of the communication processor to which the terminal is connected, and not the CFS userid. U...U and S...S (see below) thus identifies the terminal in the network uniquely.
The P indicator is useful if identically-named terminals exist on a LAN that are distinguished only by their processor name.
SSSSSSSS Terminal name. The value contained in this field will be compared with the name of the terminal from which CFS was loaded.
X ,then S...S Selection indicator.
x = Space Positive selection. The comparison result will be positive if S...S matches the terminal name, or if S...S contains blanks or '********'.
x = '-' Negative selection. The comparison result will be positive if S...S does not match the name of the terminal from which CFS was loaded.
C Connection Number. This field is compared with the connection number specified in the OC command (i.e. 1 for OC1, etc.).
If this field contains a blank, any Connection Number may be specified in the command.
X then C Selection indicator.
x = Space If the number specified in the OC command matches the value in the 'C' field, the following conditions will be checked.
x = '-' If the number specified in the OC command does not match the value specified in the 'C' field, the conditions in the same record will be checked.
x = '<' If the number specified in the OC command is less than the value specified in the C field, the following conditions will be checked. In particular, if a '-' character follows the 'C' field value, then no Connections numbered lower than this value in the 'C' field will be allowed. Examples can be found on page A2-.
x = '>' If the number specified in the OC command is greater than the value specified in the C field, the following conditions will be checked. In particular, if a '-' character follows the 'C' field value, then no Connections numbered higher than this value in the 'C' field will be allowed. Examples can be found on page A2-.
PPPPPPPP Partner. This field will be compared with the partner name of the subtask in the OC command.
'$DIALOG' is the default value if the respective parameter is missing from the OC command. Other partner names could be, for example, $CONSOLE or UTM/SAP partner names.
X then P...P Selection indicator.
x = Space The partner name specified in the OC comand must match the value in the P...P field.
x = '-' Negative selection: If the PPPPPPPP field contains blanks, specifying '-' will prohibit any Connections from being opened.
x = 'C' Conditional: If the partner name matches that in the P...P field, then the following conditions in the same record will be checked.
x = 'N' Negative conditional: If the partner name does not match that specified in the P...P field, then the following conditions in the same record will be checked.
TTTTTTTT Virtual terminal name. This field will be compared with the subtask terminal name generated by CFS, or the name specified by the user.
If the respective parameters are ommitted from the OC command, then the default value is CFSntttt (n = Connection number, tttt = TSN of the main task).
X then T...T Selection indicator.
x = Space The terminal name specified in the OC command must match the terminal name in the T...T field.
x = '-' Negative selection: If the TTTTTTTT field contains blanks, specifying '-' will prohibit any Connections from being opened.
x = 'C' Conditional: If the virtual terminal name matches that in the T...T field, then the following conditions will be checked.
x = 'N' Negative conditional: If the virtual name does not match that in the T...T field, then the following conditions will be checked.
HHHHHHHH Host name. The value in this field will be compared to the name of the host computer to which the subtask was opened. The character string '$SAME ' can be used as a dummy variable for the host computer from which the main CFS task was loaded.
X then H...H Selection indicator.
x = Space The host name specified in the OC command must correspond to that contained in the H...H field.
x = '-' Negative selection: If the HHHHHHHH field contains blanks, specifying '-' will prohibit any Connections from being opened (Connections to any host are not allowed).
x = 'C' Conditional: If the host name matches that in the H...H field, then the following conditions will be checked.
x = 'N' Negative conditional: If the host name does not match that in the H...H field, then the following conditions will be checked.
U1U1U1U1 Userid of the subtask. The value in this field will be compared to the userid of the subtask to be opened (only for Connections to $DIALOG).
The character string '$SAME ' can be used as a dummy variable for the host computer from which the main CFS task was loaded. When opening a Connection to $CONSOLE, or to a UTM/SAP application, the U1...U1 field will not be evaluated.
X then U1...U1 Selection indicator.
x = Space The userid under which the CFS Connection should be opened must match the value in the U1...U1 field.
x = '-' The userid under which the CFS Connection is to be opened must not be that contained in the U1...U1 field.
U2U2U2U2 Second subtask userid.
Up to 25 userids may be entered in a check record. The selection indicator in front of U1...U1 is valid for all userids.
Notes: An individual CFS Termfile record is necessary for each condition to be checked. A combination of multiple conditions within one record is not possible.
Connections to $DIALOG which fail on a negative selection check will only be rejected after the respective LOGON command.
Default Records
If no Regular Check record exists for the current environment, then the Default records, if they exist, will be evaluated. Default records begin at the XUUUUUUUU field with the header '$DEFLT '.
Only the XC to XUn...Un fields of Default records will be evaluated. Any number of Default records can appear in a Termfile. They will always be evaluated in sequence. If the currently requested Connection fails to satisfy a condition, the Connection request will be cancelled.
Common Records
If Regular Check records exist in the Termfile for the current environment, these will first be checked in sequence. If Common records appear in the Termfile, these will be checked afterwards. Common records will not be evaluated in a Default situation.. Common records begin at the XUUUUUUUU field with the header '$COM '.
Only the XC to XUn...Un fields of Common records will be evaluated. Any number of Common records can appear in the Termfile.
Test Sequence
The userid and station name under which CFS is loaded, as well as the Connection number specified in the OC command (all of which describe the "environment") will be checked against the XUUUUUUUU, XSSSSSSSS and XC field contents of all test records in the Termfile.
If any selection indicator for the fields P...P, T...T or H...H is set to 'C' (= Conditional), then that field will also be included in the comparison. The following fields in the Termfile test records, (XP...P to XUn...Un) will determine if opening the Connection is permitted or not. If not, CFS will generate a DC command, and the Connection will be terminated. Under $DIALOG, this will first occur after the full logon command (including password) has been entered and executed.
Multiple check records may exist in the Termfile for a single environment (userid, station name and Connection number), as well as for a partially qualified environment. In this case, all the respective records will be checked in sequence. Only if no record produces a negative result will the Connection be opened.
The records contained in the Termfile do not have to appear in any particular order, with one exception - see the last of the examples on the following pages.
Only one negative selection indicator, '-', may be specified in the XP...P to XU1...U1 fields per test record. More than one negative condition in a record will be ignored during the check.
Examples:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
TSOS $DEFLT >3-
If CFS is loaded from a userid other than TSOS, no Connections with a number greater than 3 can be opened (all partner names for Connections > 3 are not allowed: XPPPPPPPP = '- '). If CFS was loaded from TSOS, Connections from 0 to 9 may be opened without restriction to any partner.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1 TEST -$DIALOG
No Connections to $DIALOG are allowed under the userid TEST.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1U2U2U2U2
DSS4711 CVAR1 $SAME ABC
DSS4711 CVAR2 $SAME XYZ
If CFS was loaded from the station DSS4711, and if a Connection was opened to $DIALOG on host VAR1 (C in front of VAR1: positive conditional), then only the users own userid, or userid ABC may be specified in the logon command. For Connections to VAR2, the only userid other than own is XYZ. The list of additional userids can be extended to 25. Each entry is 8 bytes long.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
D4711
D4712
D4713
D4714
$DEFLT -$CONSOLE
Opening a Connection to $CONSOLE is only permitted from stations D4711 to D4714.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
C$CONSOLE CFSCON*
$DEFLT -$CONSOLE
If a Connection is opened to $CONSOLE (C in front of $CONSOLE: positive conditional), then a terminal name must be specified in the OC command in the form CFSCONx, where x can be any character.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1 -TSOS CFS***** -
If CFS is loaded from any userid other than TSOS, subtasks can be opened without restriction. If CFS is loaded again from one of these subtasks, and an OC command issued for any application, then the request will be cancelled if the standard station name generated by CFS (CFSnxxxx) is used.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1 $DEFLT >3- $DEFLT -$CONSOLE $DEFLT $SAME $DEFLT $SAME TEST TSOS <7 TSOS >6- ABCD $SAME ABCD >6- A******* $SAME $SAME A******* >6- XXX $SAME $SAME XYZ XXX >6-
The following are valid for all userids apart from TSOS, ABCD, those that begin with A, and XXX:
- Only Connections 0 to 3 are allowed. No Connections to $CONSOLE are allowed.
- Only Connections to the users' own host are allowed.
- Dialog tasks are only allowed under the users' own userid, or under the TEST userid.
- Connections 7 to 9 are not allowed under TSOS.
- The same is valid for userid ABCD, except that only Connections to its own host are allowed.
- For any other userid beginning with 'A', Connections 7 to 9 are not allowed. Additionally, subtasks are only allowed under the same userid, and to the same host.
- The same is true for userid XXX, except that subtasks are also allowed under the userid XYZ.
Note:
The sequence of the Termfile records is only of importance to the check result if records such as 'A*******' follow a fully qualified record such as 'ABCD____' . The same is true for the S...S field.
The above example can be shortened if Common records ($COM) are used:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1 $DEFLT >3- $DEFLT -$CONSOLE $DEFLT $SAME $DEFLT $SAME TEST ABCD $SAME A******* $SAME $SAME XXX $SAME $SAME XYZ $COM >6-
Further Termfile examples can be found in CFS.S.LMSLIB.
Notes on creating and maintaining a CFS Termfile
- To create a Termfile for the first time, select the element TERMF0 from the CFS.S.LMSLIB library as follows: SEL TERMF0,CFS.S.LMSLIB,CFSTERM . The scale record in the CFSTERM file thus created is useful for aligning the fields of the check records.
- The Termfile must be shareable, so that it is accessible by CFS from all userids.
- Since the Termfile can contain sensitive data such as userids, station names and so on, this information should not be visible as plain text. To preserve security, CFS will only process encrypted data.
To encrypt the data, the current Termfile must first be unlocked by the CFS administrator under TSOS with the following command: /VERIFY CFSTERM,REPAIR=ABS. Then enter: /EXEC (CONCH,$TSOS.CFSLIB). When requested for the input file, enter the name of the Termfile with the unencrypted data. When requested for the output file, enter the name of the current, previously unlocked production Termfile. The successful encryption will then be acknowleged.
- The encryption process is reversible, also using the CONCH module. The input file in this case is the encrypted Termfile, and the output file is the file that is to contain the plain text.
- For data security reasons, the CFS administrator should catalog the Termfile as ACCESS=READ. Additionally, a READ password can be set for the Termfile in CFSMAIN. Before each access to the Termfile, this password will be issued by CFS, and following a successful Open command, immediately released. The original CAT command must be issued by the system administrator: /CAT CFSTERM,STATE=U,RDPASS=....
- The execution of the OC checks described in this section is explicitly linked to the existence of the Termfile. No modifications should be made to USRMOD, nor should any flags or indicators be set in the CFSMAIN module. It should be ensured that the Termfile is referenced with the correct file name. This file name can be checked as follows: load CFS, then break to the system mode at the second mask by pressing the K2 key. The Termfile name can be displayed by entering the following IDA command: /D L'1000'.(T=x,L=30,P=681).
Monitoring CFS program calls with a User file
The system administrator can create a central file, $TSOS.CFSUSER (FCBTYPE=SAM,RECFORM= V). This file can be used to determine from which terminals, and under which userids an /EXEC $CFS command may be issued. The CFSUSER file may contain any number of check records.
The records have the following structure:
XUUUUUUUUBBXSSSSSSSS
(This record may appear as the first record when creating a user file to help in field orientation. It is only for editing purposes, and will be ignored by CFS).
Description of the individual fields:
UUUUUUUU Userid. The contents of this field will be compared with the userid from which CFS was called. If U...U contains spaces, the userid from which CFS was called is irrelevant. In this case, only the next field, S...S (station name) is relevant for the CFS check.
At each position within the U...U field, an asterisk can be entered as a wildcard character. It will result in that column not being evaluated.
X then U...U Selection indicator.
x = Space Positive selection. Loading CFS is allowed if the userid under which the user logged on matches that in the U...U field, or if U...U contains spaces or '********' .
x = '-' Negative selection. The call to load CFS will be rejected if the userid under which the user logged on matches that in the U...U field, or if U...U contains spaces or '********' .
x = 'C' Conditional: If the userid under which the user logged on matches that in the U...U field, then the station name specified in S...S will be compared with the actual station from which CFS was called.
x = 'N' Negative conditional: If the userid under which the user logged on does not match that in the U...U field, then the station name specified in S...S will be compared with the actual station from which CFS was called.
BB Blanks.
SSSSSSSS Station name. The contents of this field will be compared with the name of the station from which CFS was loaded.
All of the selection statements described above for U...U are valid for the selection indicator X in front of S...S .
If S...S contains spaces, the station from which CFS was loaded is irrelevant. In this case, only the userid field is checked.
At each position within the S...S field, an asterisk can be entered as a wildcard character. It will result in that column not being evaluated.
X then S...S Selection indicator.
x = Space Positive selection. Loading CFS is allowed if the station name from which the user logged on matches that in the S...S field, or if S...S contains spaces or '********'
x = '-' Negative selection. The call to load CFS will be rejected if the station name from which the user logged on matches that in the S...S field, or if S...S contains spaces or '********' .
x = 'C' Conditional: If the station name from which the user logged on matches that in the S...S field, then the userid specified in U...U will be compared with the actual userid under which the user logged on.
x = 'N' Negative conditional: If the station name from which the user logged on does not match that in the S...S field, then the userid specified in U...U will be compared with the actual userid under which the user logged on.
A default record can appear after the normal check records. This record can be used to determine whether usage of CFS is permitted or not if neither the userid nor the station name appears in a regular check record.
The default record has the following format: DEFAULT=Y | N
DEFAULT=Y will result in the usage of CFS being allowed if the CFS Userfile contains no records matching the userid or station name of the user.
DEFAULT=N will result in CFS not being executable if the CFS Userfile contains no records matching the userid or station name of the user.
Standard: DEFAULT=Y
Examples:
XUUUUUUUUBBXSSSSSSSS CTSOS DSS4111 CTSOS DSS4112 CTSOS DSS4113 CTSOS -
Under the TSOS userid, CFS may only be called from stations DSS4711 to DSS4713. No other userids have station name restrictions.
XUUUUUUUUBBXSSSSSSSS -A10*****
No userid beginning with A10 may load CFS. There are no restrictions on any other userids.
XUUUUUUUUBBXSSSSSSSS
DSS91***
DEFAULT=N
Usage of CFS is restricted to stations whose names begin with DSS91.
Note:
The record sequence in the user file is relevant to the check result. See example 1 above.
Further examples of Userfiles can be found in CFS.S.LMSLIB.
Notes on creating and maintaining a CFS Userfile
- To create a Userfile for the first time, select the element USERFIL1 from CFS.S.LMSLIB with CFS as follows: SEL USERFIL1,CFS.S.LMSLIB,CFSUSER . The scale record in the CFSUSER file thus created is useful for aligning the fields of the check records.
- The user file must be shareable so that CFS can access it from all userids.
- The Termfile can contain sesitive data, such as userids, station names and so on. This information should not be visible to all as plain text; it needs to be encrypted. CFS will only process encrypted data.
- The encryption process is performed in the same way as for the Termfile, by using the CONCH module. For a full description, see the section entitled "Notes on creating and maintaining a CFS Termfile" on page A2-.
- To improve data security, the Userfile should be cataloged as ACCESS= READ by the CFS administrator. In addition, a READ password can be created for the Userfile in CFSMAIN (see the USERFPSW in the data section at the end of CFSMAIN). Before each access to the Userfile, this password will be issued by CFS, and following a successful Open command, immediately released. The original CAT command must be issued by the system administrator: /CAT CFSUSER,STATE=U,RDPASS=....
- The execution of the checks described in this section is explicitly linked to the existence of the Userfile. No modifications should be made to USRMOD, nor should any flags or indicators be set in the CFSMAIN module. It should be ensured that the Userfile is referenced with the correct file name. This file name can be checked in the data section of the CFSMAIN module (USERFILE field).
CFS provides a function whereby all CFS calls are logged to a file, together with date, time, TSN, userid, account number and mode (Dialog or Enter). When CFS is terminated, an additional log record comprising the TSN, as well as the total CFS usage time (in minutes).
The logging function is activated during the installation of CFS by changing the name of the log file from '*DUMMY' to a valid file name. This can be achieved by making a modification in column 201 of the 4th PAM block in CFS. For further information, see the source of the CFSMAIN program in CFS.S.LMSLIB.
In addition to calling CFS, the following user activities can be logged:
- Opening a Connection with an OC command
- File Transfer requests with an FT command/Action Code, or ONXFT Variable Action
- File Modification with the CFS Editor.
- Connection Handler error messages can also be logged for diagnostic purposes.
For a description of the various logging functions, see the CFSMAIN source program in CFS.S.LMSLIB .
CFS.PDFILE for Print/FT/RDAC CommandsA PDFILE can be created by the CFS administrator which will assign specific remote printers, print commands, file transfer or RDAC profiles to a specific mnemonic code (PDmn). It can be used by any CFS user
The CFS.PDFILE is a normal SAM file, created with EDT, containing 3 different types of records:
- Comment Records can appear anywhere, and begin in column 1 with an asterisk ('*').
- Header Records begin in column 1 with '$'. The following can appear as from column 2:
a) a number of parameters for the /PRINT command (ISP format).
b) a 'PRINT-FILE' string, followed by a blank and then parameters for a PRINT-FILE command (SDF format).
c) an 'FT' string, follwed by a blank and then parameters for a CFS FT (File Transfer) command. For a description of the FT parameters, see the CFS User Manual, Chapter 7 (FT Command), and Chapter 12 "File Transfer with FT-BS2000/RDAC".
Example: FT ,,,HOST1,USERID2,ACCNB2,C'PASS',,,,,TO,YES.
d) an 'RDAC' string, followed by a blank and then parameters for a CFS RDAC command (File Transfer/Print with RDAC). For a description of the parameters, see the CFS Users Manual, Chapter 7 (RDAC Command), and Chapter 12 "File Transfer with FT-BS2000/RDAC.
Example: RDAC ,,,PRINTER2,,,,,TO,SPACE=E,HEADER=YES.
The prerequisite in cases a) and b) is that the file name is the first command parameter, and that a file will be created independently by CFS at the time of printing. An asterisk can be used as a dummy variable in the print parameters for the name of a remote printer generated in PDN.
In cases c) and d) the file1, file2, and passw parameters will be transfered with the first three commas. The file1 parameter will be replaced at execution time by the name of the file marked with the PD Action Code. For file2, the same name will be used as file1.
A header record can be up to 2048 bytes long. However, if the file is to be processed with EDT, the maximum record length must be restricted to 256 bytes.
If the string '********' appears in a header record as a dummy variable for a device name (e.g. DEV=********), CFS will read the folllowing mnemonic device records (see below), until a record with the mnemonic mn (corresponding to the Action Code PDmn) is found. The printer defined in this record (in columns 3 to 10) will be inserted in the DEV or other operand in place of the asterisks.
The special character '#' represents the mnemonic code specified in the PD Action Code. If a '#' appears in a header record, then the mnemonic code specified in the PD Action Code will be replaced at that point in the print command parameter. Thus, for a header record containing a '#' symbol, no mnemonic device records are necessary (see below).
One or more mnemonic assignment records (PDmn) follow header records of the type a) to d) .
- Mnemonic assignment records begin in column 1 with any character other than '*' or '#'. The fields have the following format (see also the example on the next page):
Columns 1-2 Mnemonic mn of the PDmn Action Code (mn: alphanumeric, left justified). The mnemonic code may not end with the letters B, E, or S.
Columns 3-10 DCAM device name of the remote printer/name of the host system for FT.
When the respective mnemonic code is addressed for the first time, a real device name will be requested from the user which will be substituted in place of the ???????? virtual device name. This name will remain valid for the duration of the CFS session, unless it is amended by an APD device command.
Columns 11-80 Free text (description of the printer, location, etc.) or blank.
The full list of these printer descriptions can be displayed on the screen with the PD? Action Code.
If the dummy variable character, '*' , is not specified for the device name in a header record (e.g. CONTROL=PHYS,FORM=STD,LOOP=C8,CHARS=(82E,82R) ), then the device name is required in the next mnemonic device record. In this case, only the mnemonic code is important. With this code, the relationship is between the print command and the parameters in the preceding header record.
Assignment algorithm Mnemonic code <--> Print/FT/RDAC command created by CFS:
Action Code PDmn: The description mn is sought in columns 1 and 2 in the PDFILE .
If a record matching the description is found, the preceding header record ($...) will be examined to determine the command to be executed.
Every instance of an '*' character in the print parameters of the header record will be replaced by the device name, so long as the device name is not ???????? (virtual device name, see above). The print command so constructed is missing only the file name, which will be supplied by CFS before executing the command.
If no record with the specified mnemonic code is found, then the first header record containing a '#' will be sought. If such a header record is found, then the code specified in the PD Action Code will be successively substituted for each of the 1 or 2 '#' symbols. The following should be noted: if a single digit mnemonic code is specified in the PD Action Code (e.g. PD5), and if a two digit code is expected in the header record (##), then the PD mnemonic code will be expanded internally to two digits (PD05).
If neither of the two cases described above occurs, then the error message "Header/Station Record missing in PDFILE" will be displayed on the screen.
By entering the Action Code PD or PD?, the user can display a list of all defined mnemonic codes and their respective print commands, or devices.
The name of the PDFILE and the userid can be amended by the CFS administrator in the CFS patch area (see CFSMAIN source program).
A central CFS.PDFILE must be shareable. Each user can also create their own PDFILE, and assign it with a FILE command as follows: /FILE pdfile,LINK=PDFILE.
Example for a PDFILE:
$CONTROL=PHYS,FORM=SX1,LOOP=C8,CHARS=(82E,82R)
Z1 Central laser printer; Form 1 (see computer centre spec.)
$DEV=********,FORM=H810
A0PRN1 Desktop laser Room 418, Format: 8 LPI, Font: 10 CPI
..............
H0PRN8 Room 502, Format: 8 LPI, Font: 10 CPI
$PRINT-FILE ALT-USER=*NONE,DEVICE-NAME=********,START-OUTPUT=STD
A2PRN1 Desktop laser Room 418, Format: 8 LPI, Font: 12 CPI
B2PRN2 Room 422, Format: 8 LPI, Font: 12 CPI
..............
X ???????? Virtual device name for mnemonic code X.
$FT ,,,********,USERID0,ACCOUNT0,C'pass',/DO succ-proc,/DO fail-proc,*BS2000,TO,YES
F0HOST0 File Transfer to HOST0, User-Id USERID0
F1HOST1 File-Transfer to HOST1, User-Id USERID0
$RDAC ,,,********,,,,,TO,YES,SPACE=E,HEADER=HDR1
R0PRINT10 RDAC printer 10
R1PRINT11 RDAC printer 11
..<3 - 10><11----------------------------------------------------------------------2048>
| | |
| | ÀÄÄÄ Freeform text. This will be displayed
| | for all defined printers when
| | entering the Action Codes PD / PD? .
| |
| ÀÄ Device Name of the printer/host computer.
|
ÀÄÄ 2 digit mnemonic code: Description of the printer and particular formats.
Installing CFS is achieved by transferring the contents of an ARCHIVE tape to any userid, e.g. $CFS. The following statements are necessary:
/EXEC $ARCHIVE
F NA=($TT08.,RENAME=$CFS.)
I FROM=(CFSxxx),DEVICE=xxxx,L=SYSOUT,REP=ALL
END
The files CFS, CFSLIB and CFSHELP should be cataloged as shareable.
The standard values of the CFS commands and options are set in the CFS version distributed on tape as described in Chapter 18, "Amending Parameters".
Standard settings that vary from these default values can be maintained by the users with the help of Startup files. Startup files contain commands which are automatically executed after CFS is started. Each user can thus create an individual parameter profile.
Changing the global default values for all users can be acieved by making changes in the CFSMAIN program. The source code for this Assembler program is included in the CFS delivery, and is stored in CFS.S.LMSLIB as a module named CFSMAIN. This module can be used to effect these parameter changes, as well as data security measures.
Examples:
- Activating the USRMOD test module. This module is called after each user input, and can validate or even modify that input.
- Requiring an Acknowlegement Request before overwriting existing files when performing certain operations, e.g. Select, Copy, Add, Erase.
- Maximum number of open Connections.
- Symbol to be used for the command memory in Connections (Standard: '-').
- Standard User Options for file selection.
- Names of CFS-internal files. For example, the name of the logging file in which all CFS statements executed by the user can be logged.
- Names of the standard software product OML's that are supported by CFS. For example:
OMLPERCON, LMSLIB, FMSLIB, FMS.LNKLIB, SYSOML.FLAM, EDTLIB, TOM.TI.LNKLIB.
The CFSMAIN source code contains the necessary code to perform all the currently valid modifications, together with a short description.
Amending an option is usually achieved by simply removing the remark asterisks from the required section of the code, thus activating the relevant MVI/MVC command.
The modified CFSMAIN program should be assembled with the ASSEMB procedure from the CFS.S.LMSLIB library. The macro libraries specified in this procedure should first be checked, and if necessary, amended. The &PLAM parameter of the ASSEMB procedure is set to ON by default, which means that CFSLIB exists as a PLAM library.
CFS needs to be relinked before the modifications become operable. Two procedures, CFSLNK and CFSLNK1 are provided in CFS.S.LMSLIB. Normally, CFSLNK should be used. CFSLNK1 should only be used when modules such as MODR or USRMOD, which will be called from CFSLIB after loading, are to be bound within CFS. A modification also needs to be made to CFSMAIN.
If CFS is being upgraded, the steps outlined above can be omitted if the followings steps are taken:
Make a copy of the original CFSLIB and CFS.S.LMSLIB files to prevent them from being overwritten when reading in the new CFS version, e.g.:
/COPY CFSLIB,CFSLIB.OLD
/COPY CFS.S.LMSLIB,CFS.S.LMSLIB.OLD.
The CFSMAIN, USRMOD, MODR and any other user-specific modules should then be copied from the old CFSLIB to the new CFSLIB. CFS should then be relinked (DO CFS.S.LMSLIB(CFSLNK/CFSLNK1) ).
The CFS parameter addresses will be compatible with future versions of CFS. The CFSMAIN module can thus be bound with a new version of CFS. The current CFSMAIN module will, however, usually contain additional amendment options that are not available in the old version. Because of this, it is recommended that the two source programs are compared (EDT Compare), and the existing modifications transfered to the new source program. Any new amendments can be activated at the same time, if required.
The following is valid for the names of the CFS-internal files that are usually called $TSOS.CFSxxxx : the userid from which CFS was loaded will be determined from the ECERDLOD link name. If this userid is not $TSOS, then the standard TSOS userid will be replaced with that from which CFS was loaded. This userid replacement will not be carried out if the userid of an internal file name already has been changed to one other than TSOS (see the respective MVC commands in the initialisation section of CFSMAIN).
The system administrator can release different versions of CFS simultaneously. The names of the system files CFS, CFSLIB, CFSHELP and, if necessary the Job variable CFS.MESSAGE should be recataloged with a version suffix .nnn or .Vnnn (e.g. CFS.945, CFSLIB.945, CFSHELP.945). The file names thus created must not be declared explicitly in CFSMAIN; they will correlated with the correct version number automatically, similarly to the process described above.
If CFS is to be loaded from PC's with 9750 terminal emulation, it may be necessary to set task switch 2 before loading the program. This could be achieved automatically via CFSMAIN.
CFS BulletinA Job variable with a length of 240 bytes is available to the system administrator to provide a bulletin to all CFS users. This text (e.g. "New version of CFS has been installed. The improvements to this new version can be displayed by entering ?all in the FILENAME-SELECT field, and then marking the 1st item displayed.") will be displayed once in the bottom half of the selection mask each time CFS is loaded. This bulletin will be suppressed the second and following times the selection mask is displayed. The name of this bulletin Job variable is CFS.MESSAGE, and must be cataloged under the same userid as that from which CFS was loaded. The Job variable must also be shareable. When it has served its purpose, the Job variable can then be cataloged as non-shareable, or erased completely.
User-specific FSTAT routine for quicker catalog read access
The system administrator has the option of integrating a specific FSTAT routine into CFS to speed up catalog access. The address of the parameter list for an FSTAT macro call of the type FSTAT file, area,length,LONG,MF=L is contained in Register 1 as an input parameter for this routine. According to this parameter list, the catalog entry for the required file is to be prepared with the required length, and in the required area. Preparing this catalog entry can also be achieved by reading the catalog directly with a P2 routine, or by executing an FSTAT macro (FSTAT MF=(E,(1)).
Calling Conventions:
R1 Parameter list address
R13 Address of a 72 byte Save Area
R14 CFS Return address
R15 Start address of the user module
The Register security in the user module should follow the standard conventions:
STM 14,12,12(13) (Start)
...
LM 14,12,12(13) (Return)
Return codes:
When exiting the routine, a return code in Register 15 is passed back to CFS.
R15 = 0: Catalog entry for the required file has been prepared successfully.
R15 > 0: Catalog entry cannot be prepared.
In this case, R15 can contain the DMS error code.
Including the user-specific FSTAT routine is achieved by removing the remark asterisks in front of the CFSMAIN MVC statements that transfer the V addresses of the routine to the global CFS data area. If CFS is then bound using the DO procedure CFS.S.LMSLIB (CFSMAIN), the user routine will be integrated into CFS via an Autolink, or explicitly with an Include statement (INCLUDE FSTAT [,library]).
Note: If activated, the FSTAT routine will always be used when reading the catalog entries for the files to be selected. This is also the case if CFS is loaded from non-privileged userids.
CFS Program phase.
CFS.S.LMSLIB PLAM format LMS library containing CFS source programs, procedures and examples. The library contents are described in detail below.
CFS.README This file contains notes regarding using CFS as a subsystem.
CFSHELP Text for the CFS Help function.
CFSHELP-E English version of the Help text. To activate it, it must be renamed as CFSHELP.
CFSLIB Dynamic load library for CFS (PLAM format).
SYSSSD.CFS.095 CFS Sub system declaration for BS2000 V9.5.
SYSSSD.CFS.100 CFS Sub system declaration for BS2000 V9.5/V10.0.
SYSSSD.CFS.110 CFS Sub system declaration for BS2000 V11.0.
Contents of CFS.S.LMSLIB
J/ASSEMB Assembler procedure for the source programs stored in the library, CFSMAIN, USRMOD, TEST, PREMOTE etc. The macro library names are compatible with BS2000 Version 9.5.
J/ASSEMB10 As above, except that the macro library names are compatible with BS2000 Version 10.0.
J/CFS.DO.CONV.CFSLIB
Procedure to convert the CFSLIB to an OML (LMR format).
J/CFS.DO.MIX.SDF
Procedure to insert the included syntax file, CFS.SYNTAX, into the central SDF syntax file. This procedure only requires the SDF-I program. The BS2000 commands CFS and NP will be implemented following the successful execution of the program, and can be used following the next system start. A functional description of the commands can be found in the DO procedure CFS.DO.START.
J/CFS.DO.PRINT DO procedure for printing laser-ready CFS hard copies. A CFS.ND-/HPFILE file is necessary for this procedure. The system administrator must adapt the PROC statements to the HP-/NDFILE, as well as to the relevant character set. Notes on how to do this are contained within the procedure.
J/CFS.DO.START
This procedure is necessary if the CFS SDF command is implemented in the BS2000 system (see also the files CFS.DO.SDF and CFS.SYNTAX). This DO procedure will be called to start the program after entering the CFS command.
J/CFSLNK CFS link procedure. This procedure is used to link the CFSMAIN and CFSUP modules to create an executable CFS phase.
J/CFSLNK1 CFS link procedure. Additional modules such as MODR and USRMOD that would be loaded dynamically via LINK will also be included when producing the phase.
J/CFSLNK2 Procedure to produce a CFS prelink module. For further information, see Chapter 17 ("CFS as Subprogram") of the CFS User Manual.
J/GENHELP Procedure to create a user-specific help file, CFSHELP.USER. Users can display the text from this file by entering ?USER.
J/JESLNK Procedure to produce a JES prelink module from the user-specific preliminary JESMAIN module, and the JES main module. This procedure should be called after each amendment to JESMAIN.
J/PUBSP9.2 Make the PUBSP function available under BS2000 V9.2 (C30/C40).
J/REP Procedure to insert the CPU reps in the current MODR module.
J/TAS9.2 Make the TAS function available under BS2000 V9.2 (C30/C40).
M/... Macros needed when assembling the included source programs such as CFSMAIN etc.
S/CEXIT0A Connection Exit source program for checking the user entries. See the relevant source code documentation regarding the call parameters.
S/CFSHELP.HELPTABS
Copy data for generating a CFSHELP.USER file. The data is intended as an example, and can be freely enhanced or replaced.
S/CFSHELP.USER.MENUE
Data for generating a user-specific CFSHELP help file. The data is intended as an example, and can be freely enhanced or replaced. The previous data element describes the construction of a menu, with pointers to the respective text sections.
S/CFSMAIN Source code of the initialisation module for CFS. The possible changes to the standard CFS settings are documented within the source code itself. For further information, see A2-.
S/CONV Source code for user-specific Variable Actions. This program will produce the ONXCONV Variable Action. User-specific Variable Actions must be enclosed in brackets (e.g. ONX(CONV) ). Further information on user exits can be found in Chapter 17 of the CFS User Manual.
S/FREE Source code for user-specific User Options. This program will produce the FREE User Option. User-specific User Options must be enclosed in brackets. Further information on user exits can be found in Chapter 17 of the CFS User Manual.
S/IFUQ Source code for the identically-named CFS procedure language run module (*RUN IFUQ .... ). The module functions are described in the source code.
S/JESMAIN Source code for the initialisation module of the JES function. The possible changes to the standard JES settings are documented within the source code itself. Further information can be found at the back of the JES User Manual.
S/PREMOTE Source code for user-specific Action Codes. This program produces the PDxx Action Code. User-specific Action Codes must be declared in an internal table. For further information, see the CFSMAIN program. A functional description of PREMOTE can be found on page A2-. Further information on user exits can be found in Chapter 17 of the CFS User Manual.
S/SETLEN Source code of the identically-named CFS procedure language run module (*RUN SETLEN .... ). The module functions are described in the source code.
S/SVAR Source code of the identically-named CFS procedure language run module (*RUN SVAR .... ). The module functions are described in the source code.
S/TEST Example of a main program that calls CFS as a subprogram, and makes use of certain functions. Further information can be found in Chapter 17 of the CFS User Manual ("CFS as a Subprogram").
S/USRMOD Source code of the module for activating data security and authorisation checks for individual CFS functions. A full description of the process can be found on page A2-.
VSNSP Source code for a user-specific CFS command. This program produces the VSNSP command. User-specific commands must be given in brackets (e.g. (VSNSP) ). Further information can be found in Chapter 17 of the CFS User Manual.
X/CFS.HPFILE Character set for printing CFS hardcopies to a 3352 laser printer (HP printer).
X/CFS.MENUE Example of a menu file. For further information, see the "Menu File Format" section in Chapter 10 of the CFS User Manual ("Menu System").
X/CFS.MENUE.FORMAT.x
Example of a template file for the Connection menu system. For further information, see the "User-specific Control of the Menu Masks" section in Chapter 10 of the CFS User Manual ("Menu System for Connections").
X/CFS.NDFILE Character set for printing CFS hardcopies to a 3350 laser printer (ND printer).
X/CFS.PDFILE Example of a PDFILE. For further information, see A2-, or the description of the S/PREMOTE element above.
X/CFS.SYNTAX Syntax file created with SDF-A for the BS2000 commands CFS and NP. The name of the DO procedure to start CFS, $CFS.CFS.DO.START, is contained within this syntax file. The userid of the procedure may need to be changed.
X/CFS.SYSTEM.SYMBOLS
File for the symbolic display of particular system tables such as TCB and XVT using the SHOW command under TAS (Task Services).
X/CFS.USERLIB.BEISPIEL
PLAM library with some interesting application examples of CFS procedures.
X/CFS.USERACT File for defining user-specific Action Codes (%xyz). For further information, see Chapter 6 of the CFS User Manual (Action Codes).
X/CFSTERM.. Examples of Termfiles. Termfiles can be used to check whether or not a user is permitted to open particular Connections. For further information, see page A2-.
X/CFSUSER.. Examples of Userfiles. These files can be used to prevent particular userids or terminals from using CFS. For further information see page A2-.
X/CFS.SYSSSD.. CFS sub system declarations for the various BS2000 versions.