SirLib update example: Difference between revisions
m (1 revision) |
m (mixed case for XCOMPARE) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
<!-- Page name: SirLib update example--> | <!-- Page name: SirLib update example--> | ||
Notice that sequenced versions of procedures do not apply to New, Erase | Notice that sequenced versions of procedures do not apply to New, Erase, | ||
or Resequence operations. | or Resequence operations. | ||
Also note that <var>Q</var> is the managed update equivalent of a Copy, just as <var>N</var> is the | Also note that <var>Q</var> is the managed update equivalent of a Copy, just as <var>N</var> is the equivalent of Create, and <var>K</var> is the equivalent of Delete. <var>XCompare</var> has no direct equivalent in the unmanaged command structure, though coupled with later reconfiguration using the output update procedure it is analogous to moving finished changes to a staging area. Resequencing is of course a special purpose function with no unmanaged corollary. | ||
equivalent of Create, and <var>K</var> is the equivalent of Delete. | |||
<var> | |||
coupled with later reconfiguration using the output update procedure it is analogous | |||
to moving finished changes to a staging area. | |||
Resequencing is of course a special purpose function with no unmanaged corollary. | |||
<p class=" | <p class="caption" style="width:575px">How a change progresses through SirLib</p> | ||
<p class="figure">[[File:SlibChangeProgressFig.png|575px]]</p> | |||
In the example above, procedure <code>TEMP</code> exists in file <code>PFILE1</code> (upper left). | In the example above, procedure <code>TEMP</code> exists in file <code>PFILE1</code> (upper left). | ||
| Line 20: | Line 16: | ||
A single line of new code is inserted in <code>TEMP</code> (the line | A single line of new code is inserted in <code>TEMP</code> (the line | ||
<code>PRINT STATE AND ZIP AT 40</code>). | <code>PRINT STATE AND ZIP AT 40</code>). | ||
Using <var> | Using <var>XCompare</var>, the update is generated to file <code>CHANGES</code>, and named <code>PFILE1.CHG1.TEMP</code>. | ||
<code>PFILE1.CHG1.TEMP</code>. | |||
A project leader defines the project name <code>CHG1</code> in <code>CONTROL.PFILE1</code>. | A project leader defines the project name <code>CHG1</code> in <code>CONTROL.PFILE1</code>. | ||
Latest revision as of 16:19, 28 October 2015
Notice that sequenced versions of procedures do not apply to New, Erase,
or Resequence operations.
Also note that Q is the managed update equivalent of a Copy, just as N is the equivalent of Create, and K is the equivalent of Delete. XCompare has no direct equivalent in the unmanaged command structure, though coupled with later reconfiguration using the output update procedure it is analogous to moving finished changes to a staging area. Resequencing is of course a special purpose function with no unmanaged corollary.
How a change progresses through SirLib
In the example above, procedure TEMP exists in file PFILE1 (upper left).
The programmer uses the Q command to copy TEMP into WORKFILE, getting
both a working and a SEQ version of the procedure.
A single line of new code is inserted in TEMP (the line
PRINT STATE AND ZIP AT 40).
Using XCompare, the update is generated to file CHANGES, and named PFILE1.CHG1.TEMP.
A project leader defines the project name CHG1 in CONTROL.PFILE1.
Finally, SirLib's Reconfiguration function, described in the Configuring files (applying updates) section, is used to create a Base version of the procedure, so the update
can be backed out if necessary, and the original procedure TEMP is deleted. The update procedure PFILE1.CHG1.TEMP is applied to BASE.TEMP to create the new
executable procedure TEMP.
The final state of PFILE1 is shown lower right.