Updating the Security Database Changes to the SECURITY utility may require a few modifications
From "VS Workshop",  Access to Wang, February 1992
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Back in November 1990, I wrote about creating a Wang SECURITY data base. The text described using a listing from the SECURITY listing to create a data base that allowed easy inquiry into access rights, user ID and name, start procedure, Modifiable data area, maximum number of workstations, and other data about individuals. Unfortunately, the approach taken to providing this information was based on the report format used by operating systems prior to 7.20, where each user was shown on a single line of the report. In more recent versions of SECURITY, there are five lines of information for each user - in effect, five different record types in the file - and the process would not work as explained.

A similar inquiry approach was described the following month, with the listing from GENEDIT as the source. In this case, the report consisted of two different record formats and Wang's CONDENSE utility was used to create a single record type for reporting.

This month I'll describe how to combine these ideas to recreate the security data base using the current listing format as the input data.

Changes to the SECURITY listing

The Wang SECURITY utility's listing has had a similar format from the early days of the VS. Beginning with the 7.20 operating system, additional items have been added that correspond with the enhanced security options available from Wang (and others), including control at the user level for items on the Command Processor, the date of last logon, the date and time for password expiration, and individual items on the Operator Console menu.

Other fields in the listing are similar to prior versions, but are located in different places. The first line contains most of the identifying information, such as user ID, name, file access flags, Security Administrator flag, number of logons, and the Modifiable Data area (working memory; sometimes referred to as "Segment 2" area). Additional information on the individual's start procedure and date of last logon is available in the second line. The remaining three report lines summarize the options available to the user on the Operator's Console and the Command Processor and are of interest only to those who have Wang's enhanced security package or any of the commercial programs that allow these items to be controlled.

The CONDENSE process

CONDENSE accepts CONTROL files that define record types, the names and locations of related data and CONTROL files to be created, and merges like records together. The output buffer can be selectively cleared or written from, allowing exact control over the timing of record creation.

The CONDENSE process consists of the following steps:

• CONTROL files must be created for each record type before the CONDENSE parameter file can be created. Take care to avoid duplicate field names throughout these files.

• A CONDENSE parameter file is created, using each of the CONTROL files for the record area and entering selection fields that determine the record type. Individual fields in the CONTROL files may be selected or ignored, and the output buffer can be written or cleared before or after the operation, allowing the output buffer to carry duplicate information until a record change.

• CONDENSE is run, producing a file with a single record type and the associated CONTROL file for that record. The fields in the condensed file are added from each of the associated record CONTROL files in alphabetical order.

Creating the new security data base

Since most users are interested only in the information in the first two record types, the example below is limited to these lines. Additional information should be easily deciphered by those interested in it; drop me a line for a complete listing if you are unable to do so.

The format for the two record types - and, hence, the two input CONTROL files - is shown in Figure 1. The field positions are predicated on their locations within the print file, including the two printer control characters at the beginning of each line. Figure 2 shows the record selection that identifies each of the record types.

The input file begins as a listing from SECURITY, but CONDENSE cannot handle the variable-length records of a print file. For this reason it is necessary to convert the listing to a consecutive file. I perform this conversion using CREATE. The consecutive file will retain the character positions of the original print file, but fixed-length records will clear the CONDENSE input buffer consistently.

Once the condensed file and related CONTROL file are created, REPORT and INQUIRY can be used to find out how security is implemented on a user basis. Example queries include file access checks, listings of users by start procedure, identification of System Security Administrators and those with Operator mode, and a count of the number of users on the system with more than one logon ID.

Working with CONDENSE

While some of the bugs in earlier versions have been fixed, CONDENSE is not without faults. Some suggestions I have for working around these problems include:

• Always scratch the output CONTROL file from prior runs of CONDENSE if you have made changes to the parameter file or the associated record-level CONTROL files. If the file already exists there will be a number of bogus "duplicate field" error messages.

• When using CREATE to convert the listing file to a consecutive, fixed-length file, be sure to pad the entire record area with spaces prior to each read from the listing file. Like CONDENSE, the CREATE utility does not clear its input buffer prior to a write and prior contents may still be there, causing invalid information to be written.

• Before using the CONTROL file created by CONDENSE with DATENTRY, enter the CONTROL utility and save the file. The file created by CONDENSE contains minor flaws in the header information that DATENTRY cannot handle.

• Since CONDENSE takes fields in alpha order, it may be advisable to name the record-level CONTROL fields so that a sort by name would yield the desired physical order of the file.

• It is frequently easier to start over when defining a CONDENSE parameter file rather than try to fix errors after modifying an existing file. Be sure to print screens as you go in case you need them for this purpose.

The security information gained by this process is well worth the trouble of navigating CONDENSE. I urge all of you with an interest in the security process to consider this approach to better information.

Figure 1: Field Locations for Security Data CONTROL Files

Record type 1: General information

Field name	Type	Location	Length
User ID	Character	4	3
User name	Character	18	24
System Administrator flag	Character	44	1
File access flags (A-Z)	Character	48	26
Operator flag (Y/N)	Character	81	1
Diagnostics flag (Y/N)	Character	84	1
Maximum number of logons	Numeric	88	3
Modifiable Data Area	Numeric	99	4

Record type 2: Start procedure; last logon

Field name	Type	Location	Length
Procedure file	Character	20	8
Procedure library	Character	33	8
Procedure volume	Character	46	6
Date of last logon (format MM/DD/YY)	Character	58	8