SirLib "getting started" steps: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (link repair)
m (misc cleanup)
 
(2 intermediate revisions by the same user not shown)
Line 8: Line 8:
<ol>
<ol>
<li>For versions of Model&nbsp;204 prior to 7.4, follow the instructions for installing
<li>For versions of Model&nbsp;204 prior to 7.4, follow the instructions for installing
the <var class="product">Sirius Mods</var> in the <i>Sirius Mods Installation Guide</i>.  </li>
the <var class="product">Sirius Mods</var> in the <var class="book">[[Media:SiriNew.pdf|Sirius Mods Installation Guide]]</var>.  </li>


<li>Follow the <var class="product">UL/SPF</var> installation instructions in [[RKTools installation]]. </li>
<li>Follow the <var class="product">RKTools</var> installation instructions in [[RKTools installation]]. </li>


<li>Add users to the <var class="product">SirLib</var> and <var class="product">SirPro</var> application subsystems.
<li>Add users to the <var class="product">SirLib</var> and <var class="product">SirPro</var> application subsystems.
<var>ADMIN SCLASS</var> users in both <var class="product">SirLib</var> and <var class="product">SirPro</var> acquire <var>STOP/START/TEST</var> privileges.
<var>ADMIN SCLASS</var> users in both <var class="product">SirLib</var> and <var class="product">SirPro</var> acquire <var>STOP/START/TEST</var> privileges.
In subsystem <var>SIRLIB</var>, <var>ADMIN SCLASS</var> users also have the ability to access the
In subsystem <code>SIRLIB</code>, <var>ADMIN SCLASS</var> users can access the <b>Administration</b> option which lets them define file administrators for <var class="product">SirLib</var> purposes, and lets them define or change <var class="product">SirLib</var>'s system default profile.
<b>Administration Option</b> which allows them to define file administrators for
<var class="product">SirLib</var> purposes, and allows them to define or change <var class="product">SirLib</var>'s system
default profile.
<p>
<p>
Subsystem <var>SIRPRO</var> should generally be left <var>PUBLIC</var> and <var>AUTOSTART</var>.</p>
Subsystem <code>SIRPRO</code> should generally be left <var>PUBLIC</var> and <var>AUTOSTART</var>.</p>
<p>
<p>
<var>SIRLIB</var> may be either <var>PUBLIC</var> or <var>PRIVATE</var>, depending upon how strictly you
<code>SIRLIB</code> may be either <var>PUBLIC</var> or <var>PRIVATE</var>, depending upon how strictly you
want to manage project definitions, reconfigurations, and access to reports.
want to manage project definitions, reconfigurations, and access to reports. <var>PRIVATE</var> is the default. </p></li>
<var>PRIVATE</var> is the default. </p></li>


<li>Add files to the <var>SIRLIB</var> subsystem definition.
<li>Add files to the <code>SIRLIB</code> subsystem definition.
<p>
<p>
For <var class="product">SirLib</var> to manage changes to procedures in a <var class="product">Model 204</var> file, the
For <var class="product">SirLib</var> to manage changes to procedures in a <var class="product">Model 204</var> file, the
file must be added to the subsystem definition via SUBSYSMGMT, with <code>X'BFFF'</code>
file must be added to the subsystem definition via SUBSYSMGMT, with <code>X'BFFF'</code> privileges in all subsystem user classes.
privileges in all subsystem user classes.
By making managed files public, and requiring that update access occur
By making managed files public, and requiring that update access occur
only through <var class="product">SirLib</var>, the administrator can guarantee a high level of
only through <var class="product">SirLib</var>, the administrator can guarantee a high level of integrity for the state of changes in the file.
integrity for the state of changes in the file.
When files are allocated to the subsystem, they should be allocated as <b><i>non-required</i></b>.</p></li>
When files are allocated to the apsy, they should be allocated as <b><i>non-required</i></b>.</p></li>


<li>For procedure files to be managed by <var class="product">SirLib</var>, change <var>[[OPENCTL parameter|OPENCTL]]</var> to <code>X'80'</code> and <var>PRIVDEF</var> to <code>X'0221'</code>.
<li>For procedure files to be managed by <var class="product">SirLib</var>, change <var>[[OPENCTL parameter|OPENCTL]]</var> to <code>X'80'</code> and <var>PRIVDEF</var> to <code>X'0221'</code>.
Line 44: Line 38:
<li>Create a <var class="product">SirLib</var> default system profile.
<li>Create a <var class="product">SirLib</var> default system profile.
<p>
<p>
<var class="product">SirLib</var> requires a single "administration" record to exist in its
<var class="product">SirLib</var> requires a single "administration" record to exist in its internal data file (<code>SIRLIBD</code>) for the system profile. </p>
internal data file (<code>SIRLIBD</code>) for the system profile.
<p>
To build the system profile record, choose <b>Administration</b> from the <var class="product">SirLib</var>
To build the system profile record: </p>
Main Menu without specifying a file, define the characteristics of your <var class="product">SirLib</var>
<ol type="a">
setup, and save the profile.
<li>Select <b>Administration</b> from the <var class="product">SirLib</var> main menu without specifying a file. </li>
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. </p></li>
<li>Define the characteristics of your <var class="product">SirLib</var>
setup. </li>
 
<li>Save the profile. </li>
</ol>
<p>
Use the F1 Help text or [[SirLib change control#Administering system and file profiles|Administering system and file profiles]] for advice on what value to set in each screen field. </p></li>


<li>Create a <var class="product">SirLib</var> Administration record for each managed file.
<li>Create a <var class="product">SirLib</var> Administration record for each managed file.
<p>
<p>
<var class="product">SirLib</var> requires an "administration" record to exist in <code>SIRLIBD</code>
<var class="product">SirLib</var> requires an "administration" record to exist in <code>SIRLIBD</code> for each file to be managed.
for each file to be managed.
Add the file-specific administration record by choosing <b>Administration</b> from the
Add the file-specific Administration record by choosing <b>Administration</b> from the
<var class="product">SirLib</var> main menu, then specifying a file name at the <b>FILE</b> prompt. </p>
<var class="product">SirLib</var> Main Menu, then specifying a file name at the <b>FILE</b> prompt.
<p>
Use the help text or the appropriate section from this wiki documentation for advice on
Use the F1 Help text or [[SirLib change control#Administering system and file profiles|Administering system and file profiles]] for advice on
what value to set in each screen field.
what value to set in each screen field.
Any field left blank on the file-specific administration screen means that that
Any field left blank on the file-specific administration screen means that that characteristic will be inherited from the system profile.</p>
characteristic will be inherited from the system profile.</p>
<p>
<p>
Users will not be able to perform managed update commands in <var class="product">SirPro</var> for a
Users will not be able to perform managed update commands in <var class="product">SirPro</var> for a
particular file until the <var class="product">SirLib</var> Administration record is created for the file.
particular file until the <var class="product">SirLib</var> administration record is created for the file.
<var class="product">SirPro</var> managed update commands are X, Q, K, N and Z.
<var class="product">SirPro</var> managed update commands are <var>X</var>, <var>Q</var>, <var>K</var>, <var>N</var>, and <var>Z</var>.
All other <var class="product">SirPro</var> commands (Edit, Browse, Rename, etc.) will operate
All other <var class="product">SirPro</var> commands (Edit, Browse, Rename, etc.) operate independent of <var class="product">SirLib</var> administration records.</p></li>
independent of <var class="product">SirLib</var> Administration records.</p></li>


<li>Define <var class="product">SirLib</var> security characteristics.
<li>Define <var class="product">SirLib</var> security characteristics.
Line 79: Line 77:
while they are learning the system. </p>
while they are learning the system. </p>
<p>
<p>
To define <var class="product">SirLib</var> internal security, select <b>Security</b> from the <varclass="product">SirLib</var>
To define <var class="product">SirLib</var> internal security, select <b>Security</b> from the <var class="product">SirLib</var>
Main Menu, not specifying a file at the <b>FILE</b> prompt.
Main Menu, not specifying a file at the <b>FILE</b> prompt.
The top line of the <b>Security</b> screen shows system default security settings, and
The top line of the <b>Security</b> screen shows system default security settings, and
Line 180: Line 178:
Finally, <var class="product">SirLib</var> users should note the following points.
Finally, <var class="product">SirLib</var> users should note the following points.
<ul>
<ul>
<li>Baseline Procedures
<li>Baseline procedures
<p>
<p>
There is <i>no need</i> to establish a baseline for managed procedures.
There is <i>no need</i> to establish a baseline for managed procedures.
<var class="product">SirLib</var> can be put into place to manage existing procedures
<var class="product">SirLib</var> can be put into place to manage existing procedures or to manage systems being built from scratch.
or to manage systems being built from scratch.
The baseline for any file is the point where you begin using <var class="product">SirLib</var>.
The baseline for any file is the point where you begin using <var class="product">SirLib</var>.
The baseline for any procedure is the state it is in the first time <var class="product">SirLib</var> applies
The baseline for any procedure is the state it is in the first time <var class="product">SirLib</var> applies a change.
a change.
The creation and maintenance of a baseline is automatic, and requires
The creation and maintenance of a baseline is automatic, and requires
no action on the part of developers or managers.</p></li>
no action on the part of developers or managers.</p></li>


<li>Procedure Prefixes
<li>Procedure prefixes
<p>
<p>
<var class="product">SirLib</var> requires exclusive use of three procedure prefixes.
<var class="product">SirLib</var> requires exclusive use of three procedure prefixes. <var class="product">SirLib</var> reserves the prefix <code>BASE.</code> for procedures in managed files, the prefix <code>SEQ.</code> for procedures in files where developers are working on changes, and the prefix <code>CONTROL.</code> for update procedures in the FixFile.</p>
<var class="product">SirLib</var> reserves the prefix <code>BASE.</code> for procedures in managed
files, the prefix <code>SEQ.</code> for procedures in files where developers
are working on changes, and the prefix <code>CONTROL.</code> for update
procedures in the FixFile.</p>
</ul>
</ul>



Latest revision as of 00:19, 30 January 2016


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:

    1. Select Administration from the SirLib main menu without specifying a file.
    2. Define the characteristics of your SirLib setup.
    3. Save the profile.

    Use the F1 Help text or Administering system and file profiles 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 F1 Help text or Administering system and file profiles 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.

  9. 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.

  10. 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.
  11. 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.

  12. 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.

  13. 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

  14. 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).

  15. 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