SirLib "getting started" steps

Following are the steps the SirLib administrator should follow before SirLib and SirPro are made available to programming teams.

1. For versions of Model 204 prior to 7.4, follow the instructions for installing the Sirius Mods in the Sirius Mods Installation Guide.
2. Follow the RKTools installation instructions in RKTools installation.
3. Add users to the SirLib and SirPro application subsystems. ADMIN SCLASS users in both SirLib and SirPro acquire STOP/START/TEST privileges. In subsystem SIRLIB, ADMIN SCLASS users can access the Administration option which lets them define file administrators for SirLib purposes, and lets them define or change SirLib's system default profile.

   Subsystem SIRPRO should generally be left PUBLIC and AUTOSTART.

   SIRLIB may be either PUBLIC or PRIVATE, depending upon how strictly you want to manage project definitions, reconfigurations, and access to reports. PRIVATE is the default.

4. Add files to the SIRLIB subsystem definition.

   For SirLib to manage changes to procedures in a Model 204 file, the file must be added to the subsystem definition via SUBSYSMGMT, with X'BFFF' privileges in all subsystem user classes. By making managed files public, and requiring that update access occur only through SirLib, the administrator can guarantee a high level of integrity for the state of changes in the file. When files are allocated to the subsystem, they should be allocated as non-required.

5. For procedure files to be managed by SirLib, change OPENCTL to X'80' and PRIVDEF to X'0221'.

   This allows read access to managed procedures, and allows SirPro to be used without the need for passwords. At the same time it protects procedures from update outside the change management system.

6. Create a SirLib default system profile.

   SirLib requires a single "administration" record to exist in its internal data file (SIRLIBD) for the system profile. To build the system profile record, choose Administration from the SirLib Main Menu without specifying a file, define the characteristics of your SirLib setup, and save the profile. Use the help text or the appropriate section from the SirLib group of wiki pages for advice on what value to set in each screen field.

7. Create a SirLib Administration record for each managed file.

   SirLib requires an "administration" record to exist in SIRLIBD for each file to be managed. Add the file-specific Administration record by choosing Administration from the SirLib Main Menu, then specifying a file name at the FILE prompt. Use the help text or the appropriate section from this wiki documentation for advice on what value to set in each screen field. Any field left blank on the file-specific administration screen means that that characteristic will be inherited from the system profile.

   Users will not be able to perform managed update commands in SirPro for a particular file until the SirLib Administration record is created for the file. SirPro managed update commands are X, Q, K, N, and Z. All other SirPro commands (Edit, Browse, Rename, etc.) operate independent of SirLib Administration records.

8. Define SirLib security characteristics.

   SirLib Security is ignored if Secure is set to N on the System Administration record (which you built two steps previously). The security scheme is put back into effect when Secure is switched back to Y in Option 3. Setting Secure to N is a good way to let users navigate freely around SirLib while they are learning the system.

   To define SirLib internal security, select Security from the SirLib Main Menu, not specifying a file at the FILE prompt. The top line of the Security screen shows system default security settings, and subsequent lines show settings for each file that has an Administration record. You protect a SirLib function on a system-wide basis by placing any character in the system default row (the top row of the screen). So, for instance, you could protect every SirLib function except Reports, by placing a Y in the top row for each column except the last one.

   In the file-specific rows of this screen, a blank column allows the file to inherit the system default setting for that SirLib function, a Y means protect the function regardless of system default setting, and an N means do not protect the function regardless of system default setting. This scheme allows you to define a system default security scheme, and then let all files inherit the same scheme.

   When a function is protected for a file, individual user IDs must be given permission to access that function on a file by file basis. To give users this access, select Security from the SirLib Main Menu, specifying the procedure file at the FILE prompt. The Security screen will again appear, but this time the top row represents the settings for the file-specific functions, and each subsequent row allows the entry of a user ID.

   On the file specific security screen, you cannot alter the top row (use the system default screen to change file protection). Enter user IDs in the rows that follow, and place Y in the columns for the protected functions you want that user to be able to access.

   Again, if you start out using SirLib with Secure set to N in the system default Administration record, all internal security is bypassed. You can still build your security scheme, but users are not restricted by it.

A number of other changes can be made if you wish to make the SirLib/SirPro controlled environment more convenient for programmers. The following changes/recommendations allow programmers to work in Group procedure file context, supporting "development" and "production" versions of an application subsystem in the same region.

9. Allocate a development procedure file for each production procedure file. If you have production procedure files PRCFILE1, PRCFILE2, and PRCFILE3, you might allocate DEVFILE1, DEVFILE2, and DEVFILE3. Under SirLib, programmers can never make changes directly in an original procedure file, so the intention of these "DEV" files is to have all changes for PRCFILE1 occur in DEVFILE1, PRCFILE2 in DEVFILE2, etc.
10. Create a Group for each production procedure file. The groups should have the same name as the production procedure files. So, continuing the previous example, you would create groups PRCFILE1, PRCFILE2, and PRCFILE3. GROUP PRCFILE1 is defined as follows:

    CREATE PERM GROUP PRCFILE1 FROM DEVFILE1, PRCFILE1 PARAMETER PRCFILE=*, PRIVDEF=x'0221' END

    The order of group member definition is critical, as Model 204 looks for procedures in the order the files are listed.

11. Define a development apsy for each production apsy.

    Use SUBSYSMGMT to copy your production subsystems to development subsystem definitions. So if you have ACCTS, PERSON, and INVENT, you might copy each of them to DEVACCTS, DEVPERSON, and DEVINVENT. The only change you need to make to the definitions is to change the procedure file to a group.

12. Rationalize your INCLUDE statements.

    Depending upon how you modularize your SOUL code, you may have constructs like:

    IN FILE ?&PRCFILE INCLUDE COMMON.ROUTINES

    These statements fail in group procedure file context unless they are changed to:

    IN ?&PRCFILE INCLUDE COMMON.ROUTINES

13. Build utility application subsystems for procedure file DUMP, RESTORE, and FILEMANAGE.

    If you've followed the instructions above, your procedure files will now be "public" (OPENCTL X'80'), with very restrictive access privileges. Because the files are PUBLIC, you will never be prompted for a password, so you cannot get access sufficient to perform DUMP, RESTORE, or other file maintenance.

    The solution is to create application subsystems that provide the required access, and perform the maintenance for you. These subsystems are simple to write, and if you want, Rocket Software will send you the code for theirs, which are DUMPSTER (dump all procedure files), RECOVER (restore a specific file from a DUMPSTER dump), and FIMANAGE (customized at each use to perform a specific file maintenance activity).

14. Take a backup of everything you've done.

Finally, SirLib users should note the following points.

• Baseline procedures

  There is no need to establish a baseline for managed procedures. SirLib can be put into place to manage existing procedures or to manage systems being built from scratch. The baseline for any file is the point where you begin using SirLib. The baseline for any procedure is the state it is in the first time SirLib applies a change. The creation and maintenance of a baseline is automatic, and requires no action on the part of developers or managers.

• Procedure prefixes

  SirLib requires exclusive use of three procedure prefixes. SirLib reserves the prefix BASE. for procedures in managed files, the prefix SEQ. for procedures in files where developers are working on changes, and the prefix CONTROL. for update procedures in the FixFile.

See also

• SirLib
• SirLib implementation
• SirLib programmer's reference
• SirLib update example
• SirLib change control
• SirLib security
• SirLib reports
• SirLib configuration options
• SirLib problem resolution
• SIRLIBD record structure
• SirLib "getting started" steps
• SirLib date processing