<<< Back Home >>>

DOWN 4R5E - University of Maryland Downdater


Go to Table of Contents


1. Introduction

The @DOWN processor is primarily a symbolic comparator. It is used to compare symbolic texts (usually, but not limited to, SDF format) after which it can produce a SIR correction deck capable of transforming one text into the other. @DOWN will accept program files, data files or program file elements as input; and it can compare the table of contents of program files.

DOWN can handle SDF records up to the maximum length of 2047 words. The previous upper limit of 131071 input lines has been eliminated.

There is full support for standard, LPF, and LEPF program files, although you will get a storage overflow error if you attempt a program file downdate between LPFs having more than about 11000 undeleted elements. To accommodate more, use SPEC7 to tune various buffer length and limits parameters. Alternatively, you may use M-option calls to perform downdates on two or more successive sequence number ranges of the file. See examples 10a & 10b in the <SPEC1,SPEC2> Examples section.

The processor is invaluable in large applications where many programmers may be interacting on the same base symbolics. It is also of great use when the user wishes or is required to maintain and update current symbolics with the standard system SIR mechanisms. Finally, the Downdater is also valuable in program testing and debugging through its ability to compare corresponding output streams.

In general, there are two main modes of Downdater operation, though, under option control, one may change the characteristics of the expected input or output considerably. The first mode may be called element or data file mode. This compares a single stream of symbolic input with a second stream to determine differences. Though the output is in SIR type correction images, its meaning is clear; a user needs no special training in order to decipher it. The second mode of downdate is called program file mode. In this case, two distinct program files are specified and the Downdater, again under option control, compares corresponding elements of both files. In the simplest and default case, each symbolic element of one program file will be compared with a corresponding element of the same name in the opposing program file.

Numerous options are available to allow the user greater flexibility in using @DOWN. One may compare the contents of one program file's table of contents (TOC) against another; produce a PCF or TCF (permanent or temporary correction file) program file, data file, or program file element; limit the downdate to a certain area of the input image; ignore multiple blanks; produce expanded PRINT$ listings; downdate non-standard SDF type files; and control output optimization parameters. In addition, the input character mode of each symbolic (whether Fieldata or ASCII) is effectively transparent; if mixed mode records occur, Fieldata is the chosen medium for comparison.

In summary, the @DOWN processor can prove an indispensable tool in many situations. Discerning differences between texts, maintaining programs (perhaps for distribution to other sites), or debugging by comparison of test run outputs against a correct base: these are only a few of its varied capabilities.


2. Processor Call
[Top][Contents]

@DOWN(piping),<OPTIONS> <SPEC1>,...,<SPEC7>


2.1. Piping
[Top][Contents]

Level 4 of DOWN adds a piping capability. It is possible to redirect DOWN's printed output into an alternate temporary or catalogued file. Possible calls are as follows (note how the piping field precedes the comma before options):

@DOWN(0),options SPEC1,SPEC2,...

-- redirect output to temporary file $DOWN$PIPE01, 02, etc.

@DOWN(1),options SPEC1,SPEC2,...

-- redirect output to catalogued file $DOWN$runid(+1).

@DOWN(+0),options SPEC1,SPEC2,...

-- same as (0), but list output to standard print as well.

@DOWN(+1),options SPEC1,SPEC2,...

-- same as (1), but list output to standard print.

The most recent temporary piping file will always have the @USE name $DOWN$PIPE$T attached. A 40 may be added to any piping field -- (40), (+41) -- to activate PIPE$'s internal CSF$ tracing.


2.2. Options
[Top][Contents]

A - Used in program file mode to force TOC comparison for ABSOLUTE elements. Differences between the information collected from each TOC concerning absolute elements will be summarized in the output. (See also D,O,R,S options & SPEC6 regarding TOC summaries.)

Note that unless the N option is used, a TOC downdate with the S option will also include a downdate of any symbolic elements with the same name in the two files being compared.

B - Compress out all occurrences of multiple blanks before records are compared. Assumed if Q option set. See also Q option.

C - Compress out all blanks before records are compared. See also Q option.

D - Used with the A,O,R,S options in program file mode to include the date and time of creation when comparing element TOC entries.

E - Force output for every pair of input sequences downdated. The minimum output is a *ELEMENT card or corresponding empty element in the output program file, depending on the mode of downdate.

F - Force a case insensitive comparison between two ASCII elements. (Case insensitivity is assumed if one or both elements is Fieldata.)

G - Omit the signon and signoff lines from the piping file if piping.

H - Display SPEC7 tuning parameters and the memory acquisition history for them. SPEC7 parameters are also displayed if any are modified.

HELP - Print HELP page with quick reference for options and SPECs. (Since there could be a legitimate @DOWN call using only these options, the HELP will be printed only if there is no SPEC1 coded.)

I - Inhibit pausing in demand (opposite of default). If used with N, omit ending image count lines.

J - Solicit a list of elements to be rejected from the downdating process when comparing two program files, perhaps to avoid excessive print. One or more element name[/version]s may be entered per image, separated by at least one space. End the solicitation with an @EOF. You may also @ADD,E a list of such elements.

K - Ignore leading blanks on images when comparing records.

L - Provides an expanded listing of the downdate. It gives deleted images and line numbers of all corrections printed corresponding to their respective files. If used with N, will simulate null output to allow the printing of comparison statistics with no other listings or output.

M - Perform a masked program file or TOC downdate using the element and version names in the SPEC1 file against those which match in the SPEC2 file. The element and version fields in SPEC2 may be used to define the respective option and transparent character -- they may appear in either order -- to be used on those fields in SPEC1. If the SPEC2 version items are not defined, they will assume the SPEC2 elt's. Examples: $L, R-/$, Y$/L. Default: L$/L$.

Options are: L=left-justified / R=right-justified / Y=any position. The transparent character may be any character other than L, R, or Y, including a space. If the transparent character is not a space but does not appear in the SPEC1 field, it is assumed to be a space for that field. A space may be forced by coding the option alone, as in "File2.L/Y"

Instead of (or in addition to) elt and version masking, an M-option call can be used to supply a range of sequence numbers specifying which elts in the SPEC1 file will be considered for comparison. This type of call could be used, for instance, when downdating two LPFs. The lower limit is given in SPEC1's elt cycle field, the upper limit in SPEC2's; but both numbers refer to the sequence numbers in the SPEC1 file. See examples 10a and 10b in the <SPEC1,SPEC2> Examples section.

N - Inhibit listing of downdate. If used with I, will also inhibit ending image count lines. If the N option is specified and there is no SPEC3 output field, no actual symbolic update is done, although TOC summaries are allowed (AORS options).

If N appears with L, will simulate output to a null file or element, allowing the printing of comparison statistics without creating any output. In this instance, no SPEC3 field is required.

O - Used in program file mode to force TOC comparison for OMNIBUS elements. (See A option.)

P - Create a program file output PCF or TCF (see T option). If the P option is specified, a program file must be given in <SPEC3>. It may be used in either element mode or program file mode downdates providing there is an element name logically available for any output element (see "The P Option" for further explanation). If one attempts to downdate two data files under the P option, an error will be noted since there is no logical name available to give to the output element.

Q - Used in conjunction with the B or C option to retain any blanks inside QUOTED strings; that is, strings delimited by the <QUOTE CHAR> or the default apostrophe. Assumes B option; see also U.

R - Used in program file mode to force TOC comparison for RELOCATABLE elements. (See A option.)

S - Used in program file mode to force TOC comparison for SYMBOLIC elements. (See A option.)

T - Used to downdate PCF elements, data files or program files to produce the appropriate TCF. (See P option.)

U - Used in conjunction with the B or C option to retain any blanks in UNQUOTED strings; that is, anywhere outside areas delimited by the <QUOTE CHAR> or the default apostrophe. Assumes B option; see also Q.

V - Used in conjunction with the L option to create batch listings (132 columns) from demand.

W - Used with L option to omit extra *** lines when listing deleted lines, prevent listing continuation images for lines that would overflow, and line up old and new lines without prefixes. Useful for demand.

X - Used to force the DOWN to ignore any element cycle information. This is provided as a last resort in an attempt to downdate non-standard SDF format files. (Note: DOWN will automatically recognize PRINT$, FORTRAN, and PCIOS files and process control information accordingly.)

Y - At normal termination, set T3 of the condition word to the number of pairs of elements or files that had differences. If comparing one element or file to another, the value will be 0 or 1. If comparing two program files, the value will be the number of elements with one or more correction images in the output stream, or the the number of non-empty elements generated in the output program file. If this number exceeds 4095 (07777), it will be left at 4095, although the correct value will be printed in the END line. Null entries caused by the E option will not be counted.

Z - Force a downdate of every element or PCF sequence encountered in either input stream. If the element or sequence has no counterpart in the opposing stream, it is downdated against a null element or sequence.


2.3. SPEC Fields
[Top][Contents]

2.3.1. <SPEC1> - Input 1
[Top][Contents]

Can be a data file, program file with or without version, or program file element. If no filename is given, TPF$ is assumed. <SPEC1> is the element or file to which the output corrections are to be applied, in order to change it into <SPEC2>.

For an M option call, the SPEC1 element and version fields may contain transparent characters to be masked when comparing. The elt cycle field may contain a number specifying the lower limit of a sequence number range from which to select elements for downdating.


2.3.2. <SPEC2> - Input 2
[Top][Contents]

May also be a data file, program file with or without version, or program file element. If no filename is given, TPF$ is assumed. If an element name is given in <SPEC1> and none is given in <SPEC2>, the name from <SPEC1> is assumed. If both <SPEC1> and <SPEC2> designate program files, a program file mode downdate is initiated. Program file elements may be downdated against text files.

For an M option call, the SPEC2 element and version fields may define the transparent character and option to apply to the respective SPEC1 field. The elt cycle field may contain a number specifying the upper limit of a sequence number range from which to select elts for downdating. Note that this sequence number range applies to the elts in the SPEC1 file.

If both <SPEC1> and <SPEC2> are omitted, no comparison will be done.

Several shorthand and alternate methods are provided for <SPEC1> and <SPEC2>:

If <SPEC2> has no element name, but does have a version name or an elt cycle field, the element name from <SPEC1> will be assumed. This allows a shorthand way of comparing two different versions or cycles of the same element. Similarly, if <SPEC2> has no filename but does have a qualifier or F-cycle field, the corresponding fields from <SPEC1> will be assumed. Note, however, that a "*File." notation in <SPEC2> will, according to INFOR rules, take on the current @QUAL, not the qualifier from <SPEC1>.


2.3.2.1. <SPEC1,SPEC2> - Examples
[Top][Contents]
     1. @DOWN PROGFILE.TESTRUN/OLD,./NEW
     2. @DOWN,LW PROGFILE.DECODE/PHASE2(-1),.(-0)
     3. @DOWN,L PROGFILE.EVALU8/PREVIOUS,TST./-
     4. @DOWN PROGFILE.PROGRAM3/VERSION4(+0),.(-0)
     5. @DOWN PROGFILE(-1).,(-0).
     6. @DOWN PROGFILE.ELT1,QUAL2*.
     7. @DOWN PROGFILE.ELT1,FILE2.(0034)
     8. @DOWN,NPM FILE1.ELT$$$,FILE2.,FILE3.
     9. @DOWN,LWM FILE1./R1,FILE2./$R
    10a. @DOWN,NPM FILE1.(1),FILE2.(5000)
    10b. @DOWN,NPM FILE1.(5001),FILE2.(9500)
    11. @DOWN,LW  FILE1.SCHED(-0001),.(-0000)
    12. @DOWN FILE1./4R3,FILE2./4R3A

Example 3 shows how to @DOWN from a non-blank to a blank version. If the <SPEC2> eltname is absent, a single dash in the version field will be treated as a blank. (If <SPEC2> needs to designate an element with an actual version name of '-', then it must be spelled out in full, including the element name.) This example also illustrates that <SPEC2> does not have to come from the same file as <SPEC1> when using this shorthand mode.

Example 4 shows how to @DOWN from the oldest cycle of an element to the latest without having to know their numbers.

Example 7 shows how to specify an element by its sequence number in the file, which can be found by @PRT,TL or utilities such as TOCED and SORTOC. Code the sequence number in the element cycle field by making it at least four digits, adding leading zeroes if necessary. This method can be used for comparing deleted elements as well as omnibus elements (deleted or undeleted) created via @COPY,IO.

Examples 8 and 9 show masked calls: elements with names 6 characters or shorter beginning with 'ELT' (8); elements with versions ending in 'R1' (9). See M option.

Examples 10a and 10b show how to use an M-option call to supply sequence number ranges in order to downdate two LPFs that have more elements than can be handled in a single call. The examples assume that FILE1 has 9500 elements.

Example 11 shows how to refer to the relative sequence number of a named element. Just as with the absolute sequence numbers in Example 7, these fields must be at least four characters. The numbers refer to all occurrences of the element in the file, deleted or undeleted, with (-0000) being the most recent, (-0001) being the next most recent, etc.; and (+000) being the oldest, (+001) being the next oldest.,etc.

Example 12 shows how to @DOWN program files by version. Elements from the SPEC1 file having the SPEC1 version are compared with elements from the SPEC2 file having the SPEC2 version. Either version may be blank; if both are, a normal program file downdate is done.


2.3.3. <SPEC3> - Output
[Top][Contents]

The output file field. If empty, it is assumed no output stream is desired. If it exists, it may be a data file, program file element or program file. If it is a program file, the P option must also be present to indicate default element names; otherwise an error will be noted.


2.3.4. <SPEC4> - Column Range
[Top][Contents]

Has the format:

<COL1>/<COLN>/<QUOTE CHAR>.<COL1>/<COLN>

All fields are optional. The redundancy is provided as an aid to the user, the <QUOTE CHAR> is forced to the write key field to allow input of special characters. If both filename-read-key and element-version-name combinations are given, the element-version-name parameters are used.

<COL1>/<COLN> -

is the 'WINDOW' option specification. It allows the user to downdate over specified columns of the input image. For example, to ignore possible card sequence numbers, one might provide '1/72'. The only restriction is that, if given, <COLN> must be greater than or equal to <COL1>.

<COLN> may also specify a subtype for which to ignore comment fields. Currently the only subtype for which this is supported is MSM. Example:

@DOWN A.,B.,,/MSM

<QUOTE CHAR> -

is provided for the BQ (or CQ) downdate. The default <QUOTE CHAR> is the apostrophe ('). This field is provided in the event that the BQ option is desired for some language which uses some other character to delimit literal character strings.


2.3.5. <SPEC5> - Peek/Lookahead
[Top][Contents]

Has the format:

<PEEK>/<LOOK AHEAD>/<CORR CHAR>.<PEEK>/<LOOK AHEAD>

As with <SPEC4> the redundancy is provided to aid the user.

<PEEK>/<LOOK AHEAD> -

are program optimization parameters and by their nature are somewhat arbitrary. They default to 12/400. These have been found to be reasonable values in the vast majority of cases. The <PEEK> factor is defined as the number of sequentially corresponding records necessary to confirm a match. The <LOOK AHEAD> factor is the maximum number of images sequentially searched in order to attempt to satisfy the <PEEK> factor. (See Optimizing Parameters And the Downdater Algorithm.)

<CORR CHAR> -

is the correction card prefix character which SIR allows to be redefined. Its default is the usual dash or minus sign (-). Like the <QUOTE CHAR>, it uses the write key of the spec field to allow the introduction of special characters.


2.3.6. <SPEC6> - TOC Downdating
[Top][Contents]

The Table of Contents downdating control field. Format:

TOC/SRAONXB12[-]D[-]Y[-]Z

All characters to the right of the slash are optional. This SPEC was created to reorganize and consolidate control of the TOC DOWN, rather than spreading it among multiple options. For compatibility, the S, R, A, O, D, and N parameters mean the same as their corresponding @DOWN options.

Note that although a potential of 15 characters are shown, the entire TOC parameter may not exceed 12 characters.

There are two basic types of TOC comparison:

1) Showing element/versions of the selected types (S,R,A,O) that exist in one file but not the other. This is the default when any of the AORS options are used with no other TOC options or parameters. It is prevented by the B parameter.

2) Showing elements that exist in both files but differ in one or more fields. This is activated by the B, D, Y, or Z parameters. A type 1 comparison is always performed along with a type 2 unless the B parameter is present.

The TOC parameters are:

SRAO - Have the same meaning as the @DOWN call options. If any are present, they will override the @DOWN options. If none is present in either the TOC SPEC or the @DOWN call, all will be assumed.

N - May be set here to prevent source element comparison listing. If N is set and there is no <SPEC3>, no source comparison will occur unless the @DOWN L and N options are used to force a null output.

X - Omit END line totals by type.

1 - List SPEC1 file summary only.

2 - List SPEC2 file summary only.

D - Compare elements by date and time.

F - Flag ("+") newer element if it exists in both files.

Y - Compare elements by subtype.

Z - Compare elements by size.

B - Show elements only if they exist in both files. Will assume D, Y, and Z unless they are specifically disabled. B may be followed by any combination of -D, -Y, or -Z to prevent comparison of their respective fields.

If B is not present, D, Y, or Z may be used to force comparison of those field(s) only.


2.3.7. <SPEC7> - Parameter Tuning
[Top][Contents]

SPEC7 provides a way of tuning parameters that were previously modifiable only by regenning. These parameters are now used dynamically at execution time to define limits and acquire storage. Although the default settings will handle the majority of cases, reducing one or more of the values would allow the DOWNing of LPFs having more than about 11000 elements. Format:

INT*SDFOBL(SDFOBN)/INDLEN.MAXIMG/SDFIBL(SDFIBN)

Default: 2T(2)/16384.2047/2T(8) -- but see SDFIBN

Minimum: 224(1)/512.20/224(2)

Where: 

INT = Initial timed display interval. See later section, "Progress Report During Long @DOWNs."

SDFOBL = SDFO buffer word length. Default: 2*1792. Minimum: 224.

SDFOBN = Number of SDFO buffers. Default: 2. Range: 1-2. SDFOBL and SDFOBN will be set to 0 if there is no SPEC3 output.

INDLEN = Paging index word length for each SDFI buffer. Default: 16384. Minimum: 256. INDLEN is unique in that if a new value is coded, that exact amount will be used; but if it followed by a minus ('-'), the number will become the new default, allowing it to be optimized upwards if possible. Example: @DOWN F1.,F2.,,,,,/3000-.

MAXIMG = Maximum input image word length. Default: 2047. Used for each SDFI packet and the main EDIT$ packet. For safety, will add 16 words of padding. Minimum: 20 (63 for EDIT$ packet). Maximum: 2047.

SDFIBL = SDFI buffer word length. Default: 2*1792. Minimum: 224.

SDFIBN = Number of SDFI buffers. Default: 4 for single elt/SDF file downdate, 8 for program file downdate. Minimum: 2.

The SPEC7 parameters are displayed if any are modified or if the H option is used. To display them if there are no changes or H option, put "L" in SPEC7.

Notes:

1. The number of SDFI buffers can be more than 2 because DOWN uses its own version of SDFI, with multiple buffering and paging, for faster access.

2. The values for SDFOBL and SDFIBL may be followed by "S" or "T" to denote sectors or tracks. If necessary they will always be rounded down to the nearest multiple of 224 words.

3. The default values for these parameters are still defined in DOWNDEF, with each name preceded by "DEF": DEFINDLEN, DEFMAXIMG, etc.

4. Although most parameters do not have an upper limit, setting one or more of them too high can cause a memory overflow.

5. Reducing these values can result in slower performance. The ones to look at first are MAXIMG, which could safely be reduced to 33 for most element comparisons; and SDFOBL and SDFOBN, since there is usually much less output than input when SPEC3 is coded. (If SPEC3 is not coded, no SDFO buffer space is acquired.) Any item set to less than its minimum will use the minimum.

6. For a DOWN between SDF files or smaller program files, the SDFI buffer and index sizes will be maximized to use all available memory. In the case of larger program files or TCF downdating (T option), enough memory must be left for node trees; so default values will be used.


3. Notes on Implementation and Usage
[Top][Contents]

3.1. Program File Mode
[Top][Contents]

As stated earlier, when <SPEC1> and <SPEC2> are both program files, program file mode is initiated. The user has some control over what is downdated and the subsequent output via the E and Z options. When neither of these is specified, only symbolic elements which have names common to both files are compared. Subsequent output will only occur if some difference is found between a compared pair of elements. The E option is provided to force a minimum "null output" even if both elements compared are identical. This "null output" may simply be in the form of a *ELEMENT card in the output stream or a null entry with a corresponding element name in the output P option program file (see The P Option). This may seem trivial at first glance, but it is often desired in the creation of PCF or TCF program files to be used by SSG. The Z option forces output for all entries entered in both program files. If an entry is encountered which has no counterpart in the opposing program file, under the Z option, it will be effectively downdated against a null element. With the Z option, one can create a PCF or TCF which will map all the symbolic elements of <SPEC1> into symbolic elements of <SPEC2>. Output, regardless of options, is always in sort order, i.e. the order of output sequences will always obey the natural Fieldata collating sequence.


3.2. Summary Options for TOC Downdating
[Top][Contents]

The summary options D, A, O, R, and S allow one to look for differences in the entries of program file TOCs. They are a natural extension of the tree handling mechanisms used to process and sort entries for program file downdates. They supply a nominal amount of information regarding the differences between program file TOCs. See also SPEC6 for more comprehensive TOC downdating control.


3.3. Listing Control
[Top][Contents]

The N, L, V, and W options provide the user with some degree of control over the listing of downdated output. The N option is provided to suppress output of the actual downdate. It does not, however, affect the printing of error messages or summary option information, which must be specifically requested. If the N option is specified and no <SPEC3> is given, no actual symbolic downdate is attempted unless the L option is also used to force a null output or a TOC comparison is being done. If no downdate or summary display is to occur, the execution is determined to be useless and an error is noted. If only summary information is desired, it is recommended that the N option with <SPEC3> or the L option be specified, thus inhibiting excessive output.

The L option is provided to give the user the maximum amount of information on a particular symbolic downdate. It supplies the differing images of both files along with their respective line numbers. The output is formatted to 76-132 characters depending on available demand columns or batch/breakpoint execution. If one is executing from demand and wishes a batch listing, the V option is supplied. If the L option is not specified the output is printed, unformatted, up to 132 characters and truncated after that. The W option can be used to line up old and new lines.


3.4. Output Pausing in Demand
[Top][Contents]

By default, output is paused every screen in nonbreakpointed demand mode unless the I option is set. The message displayed is:

-MORE-> XMIT=CONTINUE; N=NO PRINT; P=NO PAUSE; X,Q,@EOF=QUIT

or, for a program file downdate:

-MORE-> XMIT=CONTINUE; E[L]=NEXT ELT; N=NO PRT; P=NO PAUSE; X,Q,@EOF=QUIT

Possible replies:

XMIT or invalid reply - Continue.

E - Suspend print until next *ELT card.

ELL - Suspend print until *ELT beginning with 1-5 given letters. Print will resume when corresponding *ELT letters equal or exceed given letters.

N - Continue with no more printing. There may be one or two more lines printed, but then no more until the END and totals lines.

P - Continue with no more pausing.

X,Q,@EOF - Quit immediately. Any <SPEC3> output will not be created.


3.5. END Lines
[Top][Contents]

For the majority of executions, DOWN will display an end line for each SPEC field, showing the type of input (program file, data file, elt), the F-cycle, the elt sequence number or total number of elements compared, and the total number of images processed when comparing.

If a TOC DOWN is done, these will be preceded by an additional totals line for each SPEC, showing the total elements by type listed for that SPEC. These totals denote the elts in each SPEC that the TOC DOWN found different or missing from the other SPEC, based on the TOC DOWN comparison options.


3.6. PCF Downdate
[Top][Contents]

The PCF downdate is triggered by the presence of the T option. The output is in the form of a TCF, capable via SSG, of transforming the PCF of <SPEC1> into the PCF of <SPEC2>. There are no logical restrictions to the file types in <SPEC1> or <SPEC2> other than those previously stated. The P option is also valid and, if properly used, results in a TCF program file as output. If input is in the form of a PCF element or data file containing *ELEMENT sequences, it is treated as an element within a program file. With this mode of handling, the E and Z options have a meaning as described in PROGRAM FILE MODE. They produce the same effect as if the PCF input streams have actually been PCF program files.

The point should be made that the T option is provided to downdate PCFs, not TCFs. The distinction is this; TCFs may contain relative PCF correction images which are themselves uncorrectable. If @DOWN is in T option mode and encounters such an image, a format error is noted, the card is treated as a *ELEMENT card or an EOF delimiter and execution continues. In short, one may downdate TCFs in this manner. Close attention should be paid to any printed error messages, however, because erroneous output may follow.


3.7. The P Option
[Top][Contents]

In the general case, the P option is meant to be used in the program file mode. Thus, the name for each output element comes from the name of the elements being compared within opposing program files. The P option is not, however, limited to program file mode. The only restriction is that there must be some logical default name to be given to any potential output element. As a last resort, the element name is taken from the element of <SPEC1>, if it exists. If not, an error is noted and the program terminates. If the processor is not in program file mode but the T option is specified, and the input streams contain *ELEMENT cards, these cards name the output elements. A problem arises when there is a data file in <SPEC1> with no T option, or with a T option but no *ELEMENT cards in the data stream. In this case, there is no logical output element name to be used; thus, an error is noted. The P option is meant to create PCF or TCF program files for subsequent use by SSG.


3.8. The B/C/Q Options, Window SPEC, And Translation
[Top][Contents]

If compared records are of different modes, translation is automatically made. The direction of translation is always ASCII -> Fieldata. This choice was made for internal convenience, but it has yet to be shown that the inverse translation is any more meaningful.

It should be noted that all character manipulation, whether it be the elimination of multiple blanks via the B, C, or Q options; the invocation of window specification; or character translation, is done at the time of each required comparison. This may at first glance appear inefficient, but there are several reasons for this approach. First, it is felt that these mechanisms denote special purpose usage and, as such, will be used infrequently. This implementation preserves the basic I/O structure which makes the Downdater as efficient as it is and yet makes the actual input record forms transparent to the main line routines. Second, in the general application, the density of differences is far smaller than the size of the total file. This method is probably more efficient in such cases than recreating each file in modified form and downdating the result. Lastly, in many applications the Downdater is still I/O bound. Using more of the CPU during overlapped I/O does not appreciably degrade program performance.


3.9. Optimizing Parameters And the Downdater Algorithm
[Top][Contents]

As stated earlier, the <PEEK> factor and <LOOK AHEAD> factor are optimizing parameters. The Downdater is a sequentially oriented comparator and as such is not defined to provide the optimum set of correction cards. The optimum is defined as the minimum number of possible correction cards to change one file into another. Instead, the Downdater produces a set of correction cards sufficient to achieve the same end. It is the interaction of these parameters and the physical nature of the files being considered which determine the closeness of the product to that optimum set. In fact, the Downdater algorithm does a very good job at approximating the optimum in the vast majority of cases. It is relatively insensitive to changes in the optimizing parameters. There are, however, characteristics of input data which may tend to degrade the result and should be noted. For example, if one is downdating two files which have repetitive blocks of the same images, the <PEEK> factor should be set greater than the size of a repeated block. Analogously, if images within a file have a displacement greater than 400 records, the <LOOK AHEAD> should also be increased. These changes effectively optimize the output, but they also degrade the speed of the processor. Processor speed can be improved by lowering the optimization parameters but at a likely cost of generating larger correction decks.


3.10. Progress Report During Long @DOWNs
[Top][Contents]

While waiting for a lengthy downdate that is not printing, you can enter @@X C at the terminal to print a progress report. DOWN will print a line showing the current line counts of SPEC1, SPEC2, and, if any, SPEC3. In addition, if doing a program file downdate, the current element name being processed will be included as well as the current element number and total elts.

If the downdate is running in breakpointed demand, the progress messages will be sent to your screen using ER ERRPR$. If a batch program is doing a downdate, a progress line may be displayed by doing an II keyin of the runid, in which case the message will be displayed on the console using ER COM$. In the latter case the message may be truncated depending on the length.

A recurring progress line may be initiated by entering the keyin "@@X C,nn" where nn is a 1-3 digit interval in seconds from 1 to 300 (5 minutes). From this point on the progress line will be displayed every nn seconds. While it is in effect, you may still enter individual "@@X C"s; you may also change the interval by entering another "@@X C,nn", and you may terminate interval mode by entering "@@X C,0". A recurring progress line is indicated by a "*" preceding the line numbers as opposed to a "-".

DOWN will display 'INTERVAL:nnn' when the interval is changed. If an invalid entry is made for nn, DOWN will display 'INTERVAL:ERR' and leave the interval unchanged.

A recurring progress line may be set in the initial processor call by supplying the interval in the qualifier field of SPEC7. Example:

@DOWN,NP FILE1.,FILE2.,FILE3.,,,,10*.


3.11. Instruction/Cycle Counts
[Top][Contents]

By setting the condition word to 2000 (@SETC 2000), you can cause DOWN to print the counts of instructions and cycles used during the main processing loop. These are retrieved by the SGNL instruction.

The bit of T2 of the condition word used to control this is defined by the tag SGNLFLAG in element DOWNDEF.


3.12. Condition Word Bit 8
[Top][Contents]

DOWN follows the convention of setting condition word bit 8 if an error occurs (option conflict, file could not be assigned, element not found, etc.). Bit 8 means the immediately preceding task had an error; bit 7 means that at least one task in the run had an error.


Table of Contents

(Go to Top)

1. Introduction
2. Processor Call
2.1. Piping
2.2. Options
2.3. SPEC Fields
2.3.1. <SPEC1> - Input 1
2.3.2. <SPEC2> - Input 2
2.3.2.1. <SPEC1,SPEC2> - Examples
2.3.3. <SPEC3> - Output
2.3.4. <SPEC4> - Column Range
2.3.5. <SPEC5> - Peek/Lookahead
2.3.6. <SPEC6> - TOC Downdating
2.3.7. <SPEC7> - Parameter Tuning
3. Notes on Implementation and Usage
3.1. Program File Mode
3.2. Summary Options for TOC Downdating
3.3. Listing Control
3.4. Output Pausing in Demand
3.5. END Lines
3.6. PCF Downdate
3.7. The P Option
3.8. The B/C/Q Options, Window SPEC, And Translation
3.9. Optimizing Parameters And the Downdater Algorithm
3.10. Progress Report During Long @DOWNs
3.11. Instruction/Cycle Counts
3.12. Condition Word Bit 8