Model 204
USE OF AND ACCESS
TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS
OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN
DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.
Loading
the Model 204 Nucleus Above the Line
By James Damon
The Online load module, or the Model 204 nucleus, is loaded by the operating
system as a result of the JCL EXEC statement:
//M204V610 EXEC PGM=ONLINE,...
|
|
If you have linked
in RSQL, the total size of the nucleus is approximately 3 megabytes. With
EVCP the size is approximately 2 megabytes. Prior to V6R1.0, the Model 204
nucleus was loaded below the 16-megabyte line, as required. Although below
the line storage is generally severely limited, usually this is not a problem.
Most customers have at most 8 to 10 megabytes and can accommodate the Model
204 nucleus which can consume 25-35% of that storage. However, some software
packages that run in conjunction with Model 204 may require large amounts
of below the line virtual storage, which may not be available.
In V6R1.0, you can
optionally load most of the nucleus above the line. This can free 2 to 3
megabytes of below the line virtual storage and provide substantial virtual
storage relief in this limited area, which might be important for your site.
Implementing
Split Load Modules
A small part of the
four Model 204 load modules must still be loaded below the line during execution.
This requires producing a split load module and, that in turn, leads to
the IBM requirement of storing the load modules in a partitioned dataset
extended (PDSE). If you select the SPLIT option, then the Model 204 nucleus
will be divided into two program objects: one that must be loaded below
the line and the other which may be loaded above the line. The below the
line program object consists of nine control sections that deal with BSAM
I/O, VTAM, LU6.2 and others. The size of the below the line program object
is about 130K. Your Online address space will resemble Figure 1.
Figure
1. Model 204 address space with nucleus above-the line
These PDSEs, which
this optional feature requires, have a number of advantages:
Figure 2.
PDSELIB job with binder control statements
//LNKONL EXEC PGM=IEWL,REGION=8M,
// PARM='LIST,LET,MAP,NCAL,SIZE=(700K,200K)',COND=(4,LT)
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,120,,CONTIG)
//OLDLOAD DD DSN=YOUR.PDS.LOADLIB,DISP=SHR
//SYSLMOD DD DSN=YOUR.AUTH.PDSE.LOADLIB,DISP=SHR
//SYSLIN DD *
PAGE KOMM$,SBNU$
INCLUDE OLDLOAD(ONLINE)
MODE AMODE(31),RMODE(SPLIT)
SETCODE AC(1)
ENTRY MAINTASK
NAME ONLINE(R)
|
|
The OLDLOAD DD, referenced
in the Figure 2 control statements, refers to a regular PDS dataset, YOUR.PDS.LOADLIB,
where all Model 204 load modules are initially stored by the M204LINK job.
Those load modules are then copied by the binder program into YOUR.AUTH.PDSE.LOADLIB
using this PDSELIB job. This step splits the load module into the two program
objects mentioned earlier.
Applying
Zaps and Early Warnings
All maintenance applied
to Model 204 load modules must be applied against the regular PDS. To accommodate
a restriction in the IBM update utility, AMASPZAP or superzap, which cannot
process PDSEs, follow the AMASPZAP application, by running the Model 204
PDSELIB job again to copy the now updated load modules from the regular
PDS to the PDSE.
In
Conclusion
If you need additional virtual storage below the line for whatever reason,
saving the Model 204 Online load module in a PDSE and running from that
load library may provide the virtual storage you require.
A Trio of New Tools Utilities:
DSVERIFY
By Tym Stegner
This
article is the first in a series that introduces three new tools utilities,
which CCA developed to resolve customer problems and to make testing more
efficient. The development of the DSVERIFY tools utility addresses the
problem of validating key table values when you would like to check their
accuracy.
We developed the
DSVERIFY tools utility based on the real-world implementation of the techniques
discussed in the June 2006 System 1032
CCAPRINT article. Modifications to the original design plan evolved that
made DSVERIFY faster and more efficient.
The DSVERIFY tools
utility is a diagnostic tool that does not fix your key problems, however,
it can be run in nonexclusive mode and the report it generates is concise.
You do not have to dump and rekey the dataset, lock it from use by others,
or examine and compare several reports.
Review
of Key Table Verification Tips
Thorough key table verification relies on the diagnostic events listed
in Table 1, which correspond to the design tips introduced in June 2006.
Table
1. Key table verification tips
| Objective:
To ensure… |
Tip # |
Commands
implemented |
| Low-level key
validity |
1 |
Diagnose VALUES
command output |
| Accurate data
population in key table |
2 |
Compare VALUES
output with data output |
| High-level key
validity |
3 |
Value comparison
via FIND |
Creating
the DSVERIFY Tools Utility
DSVERIFY generates a series of VMS COM files--each one validates the key
table for a particular keyed attribute in the dataset. A master command
file sequentially executes all the validation command files for the dataset.
If you want to validate an individual key, its command file can be executed
singly.
The processing flow
for a key validation command file is as follows:
-Start S1032, open the dataset, find ALL records
-Perform VALUES on attribute to <attr-name>.VMODE file (Tip#1)
-DUMP data values to <attr-name>.DUMP using an RD (Tip#2a)
-Exit S1032
-Sort .DUMP & .VMODE files
-Summarize .DUMP file into <attr-name>.SUM (Tip#2b)
-Sort .SUM file to <attr-name>.SUM
-If attribute is numeric suppress leading zeros in the .SUM file
-DIFFERENCES the .SUM and .VMODE files into <attr-name>.ERR file
(Tip#2c)
-Restart S1032, Re-open dataset and set environmental variables
-Execute ZCHECK_HLK process to FIND EQ attribute values from the
.SUM file, any error messages are appended to the .ERR file (Tip#3)
-Exit S1032
|
|
How
and Why DSVERIFY Works
As described in Table 1, there are three objectives to key validation.
Tip #1 takes advantage of the VALUES command which performs an integrity
check of the low-level key table structure when ever it is run.
The value/count listing
of the VALUES command becomes part of the input data for Tip #2, as it
forms the list of what System 1032 has stored in the key tables. Tip #2
compares the counted values from a data dump to the VALUES listing to
ensure the key tables contain all the data that is present in the dataset
itself. To do this, a data listing is made, then sorted and summarized
down to a similar format to the VALUES listing, so the two files can be
compared using the VMS differences command. Discrepancies are reported
in the output of the VMS differences command report, and—in the most
likely scenario--indicate that there is data in the dataset which is not
present in the key tables.
The summary file
from the data comparison is also the input file for Tip #3, where the
validity of the high-level key tables is checked. Performing a FIND command
on each value present in the data listing ensures an accurate path through
the key tables to the low-level key blocks. If any discrepancies are found,
the report is appended to the error report generated by the VMS differences
command.
Improving
the Original DSVERIFY Design
In the June 2006 article, Validating Key Table Values, I listed
the validation tips that must take place (the objectives) along with some
techniques that might be used to validate key tables in a dataset. Soon
after that article was written, a customer called who needed to test a
series of datasets. To assist our analysis I began to develop the DSVERIFY
tools utility implementing the tips I proposed. As you would expect, the
design underwent modification.
In the original article,
I proposed using the PRINT command to generate the attribute data listing.
The PRINT command by default uses the same formatting used by the VALUES
command. However, especially for larger datasets, the DUMP command is
about three times faster than the PRINT command.
All sorting is done
at the VMS level, because the VMS Sort utility sorts a flat file without
the need to specify any sort keys.
In the June 2006
article, a DCL program aggregated the data listing to a summary listing,
similar to the output of the VALUES command. Originally, I used a different
format for the summarized data than was used by the VALUES listing. This
worked well until a comparison step was applied to large datasets with
unique values in the key tables. This produced a very long summary listing,
which in turn took ages to execute in the DCL aggregation and comparison
scripts.
To speed up these
steps (by an order of magnitude), I rewrote the aggregator using a 3GL
programming language. The comparison step was made more efficient by changing
the format of the summary file to match that of the VALUES listing, and
then using the VMS differences command on the two files.
The previous steps
validated the data in the low-level tables, so I could use the summary
listing file to perform a high-level check by parsing each value and count
from the summary listing, and using it in a FIND command on that attribute.
As long as the summary count and the FIND output match, the high-level
key tables are OK. In the original design for this step, I suggested using
a SEARCH component. However, the SEARCH operation is already being done
by the summarized data listing, so that step was redundant and I removed
it.
Summary
If you would like to check the validity of your key tables after a failed
update, you can use the DSVERIFY tools utility, which generates a series
of VMS command files that serve to validate the keys in a dataset to match
the data within the dataset. You can request and receive the DSVERIFY
tool utility from System 1032 Customer Support.
Coming
Attractions
The next article in this series will look at one of two additional new
tools utilities, ADDGEN or CHGGEN, which you can use to generate ADD or
FIND/CHANGE commands from an existing dataset that add or change records
in that dataset for testing purposes.
