SirLib problem resolution

This page reviews corrective actions for a variety of common error conditions.

SirLib can't access file

Make sure that each file managed by SirLib is allocated via SUBSYSMGMT to the SIRLIB application subsystem, or that an update password exists for the file.

Cutover failed

Cutover is a complex function involving five steps:

Apply updates.
Delete update procedures.
Delete project names.
Delete Base procedures.
ReStamp procedures.

Only the first and last options may be bypassed. Each of the five options is executed in the above order. If a step fails, it can be identified by the error message and by the absence of updates to the date/time fields associated with it when control returns to the Cutover screen.

The first step applies update procedures to the target managed file. This process is exactly the activity performed from the Reconfiguration screen, and it may be bypassed if you just ran a Reconfiguration. If the first step is executed (recommended always) and fails, then the destination procedure file does not have all existing changes applied to it.

This change application process does not apply changes that are commented-out in the control procedure, and it cannot know if all update procedures that are supposed to be in the FixFile are indeed there. Most of the error messages occurring at this step will indicate that some user or application subsystem is locking a procedure that SirLib wants to update.

Each of the remaining four steps is an updating transaction requiring update privileges to the update procedure file or the target procedure file.

Troubleshooting

In case of cutover failure, check first that these files are allocated to the Online region and to the SIRLIB subsystem, and that privilege settings are high enough to allow the updating of permanent procedures.

If cutover continues to fail:

Turn on all messages in the SIRLIB subsystem definition, or run SirLib in TEST DEBUG mode.
Call the specific problem in to your SirLib Administrator or to Rocket Technical Support.

Cutover may be run as many times as necessary to accomplish the file clean up.

Missing base procedure

If a Base procedure of a file once existed and has since been deleted, SirLib sees there is no Base, copies the existing executable procedure into a Base version, and then attempts to apply changes to it.

You get an error saying that changes (from the first update procedure most likely) do not apply to the procedure. The error message specifies the sequence number where the problem occurred. You are able to edit both the procedure and the update procedure and see that the new code in the update procedure being applied already exists in the Base procedure.

A Base version of a procedure is created the first time a change to the procedure is detected during a reconfiguration. If a Base procedure is not present when a reconfiguration is attempted, SirLib assumes this is the first time managed updates have been applied to the procedure, and a new BASE. procedure is created.

The Base procedure is more important to a managed system than the actual executable procedure. Base procedures with update procedures applied are used to rebuild the executable procedures to any previous configuration.

If a Base procedure is accidentally deleted while there are still changes that need to be applied to that procedure, the Base procedure must be restored for those changes to apply. Each Base procedure must be in the same file as the executable procedure that it matches.

Missing SEQ procedure

Sequenced versions of procedures are generated during execution of the Q command. The SEQ. version created must remain unchanged while the unsequenced (working) copy is being updated. If the SEQ. version is altered, the update procedure resulting from the XCOMPARE does not apply correctly to the Base procedure, and the entire reconfiguration fails.

If an SEQ. procedure is deleted or is suspected of being altered, you must generate a new SEQ. version as follows:

Verify that no unmanaged changes have occurred against the procedure since the working version was generated.
If managed changes have occurred against the procedure since the original sequenced version was generated:
1. Comment them out in the CONTROL procedure using the Apply changes option from the SirLib main menu.
2. Regenerate a new SEQ version that includes those changes, by executing a Q command.
Regenerate the sequenced and unsequenced procedures from the original using the Q command, sending the unsequenced version to a temp file, which can be deleted.

Deleted update procedure

Update procedures can be regenerated as many times as required, as long as the original sequenced and unsequenced versions of the procedure still exist.

Reconfiguration failed

Usually Reconfiguration failures are due to an application subsystem or a subsystem user holding the target file open. Reconfiguration requires exclusive access to the target file.

SirLib does not check that a specific subsystem is locking a file, as it makes no assumptions about how many subsystems might be running out of that file. Therefore, SirLib always presents this error upon its inability to delete or rename some procedure. Reconfiguration can be restarted when the locking user or subsystem releases the file.

If an invalid update procedure is built and reconfiguration fails, a message is displayed indicating the following:

The update procedure at fault
The sequence number where the mismatch occurred

Reconfiguration also fails in the case where two or more programmers attempt to change the same line number from working and SEQ procedures generated at the same time. In SirLib this is known as a collision.

Collisions

Update collisions occur during Reconfiguration if two update procedures attempt to change the same line or section of a procedure, and both refer to the same physical location in the procedure by the same sequence number(s). This can occur when more than one programmer generates sequenced and unsequenced copies of the same procedure in a time interval that doesn't allow the second programmer's copy to include changes from the first programmer's update procedure.

For more information about how sequence numbering works, see the Q (SEQUENCE) command discussion.

In the case of collisions, the first change gets applied by SirLib, and the second change contains commands that try to find sequence numbers that are now altered by the first change.

When SirLib applies update procedures to Base procedures, it sorts all changes for a procedure into sequence and version number order. If SirLib finds within a section of code two changes that both want to be the same version, it warns the user and stops processing.

There are many ways to handle collisions, and the best is usually determined by the programmers. here is a simple approach:

Delete all but the most complex of the conflicting update procedures.
Incorporate the other changes into the working version of the procedure that was used to generate the one update procedure kept.
Regenerate that update procedure.

In some cases, the working and SEQ version of the most complex update procedure will have been deleted. In this case, it is best to regenerate the conflicting update procedure using an SEQ procedure that contains the other change(s).

To avoid difficult resolution of collisions, never delete working and SEQ procedures until you verify that the changes apply and integrate with all other changes.

Production fixes

Sometimes it is necessary to make a quick change to a production procedure which has already been updated in development. In SirLib, developers should never copy production procedures back to development in order to make these fixes.

In the production environment, identify which changes have been applied to the procedure that requires the fix. This can be done by browsing the procedure to see the change stamps, or if procedure stamping is turned off for the target procedure, by running a status report for the file to identify the last Reconfigure date and time, and the projects which were then applied.
In the development environment, ReConfigure the file to its current production state. Execute a Q command to generate SEQ and working versions of the procedure. Make the production fix, generate an update procedure, and distribute the new update procedure to production, applying the update procedure there using ReConfigure.
In the development environment, ReConfigure the file to include the new fix and all other new development update procedures. Handle collisions as indicated earlier in this page. Notify all developers working on the fixed procedure to regenerate their SEQ and working procedures to include the production fix.