CA IDMS Reference 19.0

PDF
English

RELOAD

The RELOAD utility reloads a database using input created by the UNLOAD utility statement.
idmscu19
The RELOAD utility reloads a database using input created by the UNLOAD utility statement.
All areas in an SQL segment that are being used by a RELOAD must be either OFFLINE to any CV or in RETRIEVAL mode if the areas are not being UPDATED by the RELOAD.
You cannot use RELOAD to reload an SQL database that contains keys longer than 256 bytes. Instead, use the REORG utility to reorganize a large key database.
This article describes the following information:
2
2
Authorization
To reload data into a segment, you need the privilege DBAWRITE on all areas associated with the segment.
Syntax

 
►►─── RELOAD ─┬──────────────────────┬────────────────────────────────────────►
              ├─ STEP ─┬─ step-name ─┘
              └─ FROM ─┘

 ►─┬──────────────────────────────┬───────────────────────────────────────────►
   └─ NOTIFY notify-record-count ─┘

 ►─────┬─────────────────┬────────────────┬─────────────────────┬─────────────►◄
       └── as SORTEXIT ──┘                └── REUSE workfiles ──┘
 
Parameter
  • STEP
    Specifies that only one step of the reload operation should be executed.
    If you do not specify STEP, all steps in the reload process are performed as a single operation.
  • step-name
    Specifies the name of the step to execute.
    The name must be one of the following:
    • SORT1
    • IDMSDBL2
    • SORT2
    • IDMSDBLX
    • SORT3
    • IDMSDBL3
    • SORT4
    • IDMSDBL4
  • FROM
    Specifies that RELOAD processing should begin at a specified step and complete all remaining steps.
    If you specify FROM, all remaining steps are treated together as a single operation.
  • step-name
    Specifies the name of the step to execute.
    The name must be one of the following:
    • SORT1
    • IDMSDBL2
    • SORT2
    • IDMSDBLX
    • SORT3
    • IDMSDBL3
    • SORT4
    • IDMSDBL4
    For more information and an explanation about when you can restart steps IDMSDBL2, IDMSDBL3, or IDMSDBL4, see Usage.
  • NOTIFY
    Indicates a message is sent to the system console after a specified number of records have been processed in the current step.
  • notify-record-count
    Specifies the number of records to process before sending a message.
    By default or if 0 is specified, no message is sent to the system console except the standard message sent at the end of each step indicating the number of records processed during the step.
    Notify messages are only displayed by steps IDMSDBL2, IDMSDBL3, and IDMSDBL4 when a NOTIFY-RECORD-COUNT is specified.
  • as SORTEXIT
    Causes each DBL
    x
     step in the utility to return its input data directly from the preceding sort instead of having the sort write the data to a workfile. This option eliminates one workfile for each sort and saves the I/O it takes to write, then read, the workfile.
  • REUSE workfiles
    Causes each step in the utility to reuse an existing workfile, if possible, when writing its output data, instead of writing to a new one for each step. This reduces the number of workfiles that need to be allocated.
Usage
How to submit the RELOAD utility
You submit the RELOAD utility only through the batch command facility. You must run the batch command facility in local mode.
When to use RELOAD
Use the RELOAD utility to reload a database that has been unloaded by UNLOAD.
When reloading an SQL-defined database, the database files must be formatted using the FILE option of the FORMAT utility statement so that AREA and TABLE stamps are properly reloaded.
When not to use RELOAD
Do not use the RELOAD utility to load a new non-SQL-defined database; use the FASTLOAD utility.
Do not use the RELOAD utility to load a new SQL-defined database; use the LOAD utility.
Run RELOAD all at once or in steps
The reloading process has eight steps, which you can run one at a time or all together. Each step generates output for use by the next step. Four of the steps are sorts to prepare data for use by the following step.
You can run each step separately, in which case you can use your own sorting program. Alternatively, you can direct the RELOAD utility to do the sorting for you. If you run the steps as a single process, the RELOAD utility will do the sorting for you automatically.
When to run RELOAD in steps
The most common reason to run the RELOAD utility in steps is to cut the work into pieces, each piece requiring less time to run than the whole process.
You could also decide to run the RELOAD utility in steps in order to use your own sorting programs between the steps, or you can run the sort steps on a different machine than the one holding the database.
Mixed Page Groups
RELOAD cannot process mixed page groups and will issue an error message if mixed page groups are encountered. You must use multiple invocations of the utility to process different page groups.
RELOAD and ASF databases
If the RELOAD utility is to be run against an ASF data or definition area, see Using ASF.
Restarting IDMSDBL2, IDMSDBL3, or IDMSDBL4
If a problem arises while running IDMSDBL2 or IDMSDBL3,
do not
 simply fix the cause of the problem and rerun the step. In addition to fixing the cause of the problem, you must do one of the following:
  • Reinitialize the database and begin again at the IDMSDBL2 step
  • If you backed up the database before running the step, you can run the step again, using the backup.
These steps change the database, and if a problem arises, you need to undo the changes before running a step over again.
If a non-data related problem occurs while running IDMSDBL4, you can restart the job without restoring. If the input file (SYS011) still exists, unlock the area and run the RELOAD utility from IDMSDBL4. Any updates previously performed by the run of IDMSDBL4 that abended will be overlayed by the updates in the restarted IDMSDBL4.
For more information and help in deciding whether to run the RELOAD utility all at once or in steps, see Administrating CA IDMS Database.
Data from UNLOAD is in SYS001, SYS002, SYS003, and RELDCTL
The information that the RELOAD utility needs is in the SYS001, SYS002, SYS003, and RELDCTL files. UNLOAD recognized these files as SYSPCH, SYS002, SYS003, and RELDCTL, respectively.
  • The SYS001 file contains sort parameters.
    If the RELOAD utility is started at a SORT step, in any mode, SYS001 should point to the sort parameters generated in a previous step.
  • The SYS002 file contains the following:
    • Unloaded data from UNLOAD processing
    • Data to be loaded
    • Set membership information for each record
  • The SYS003 file contains both system and user-owned index data from UNLOAD processing. If running in STEP mode, index data is not input until the SORT2 step.
  • The RELDCTL file contains:
    • Set descriptor information
    • A control record containing subschema, segment, and DMCL information
    • Control information created during UNLOAD processing and used by RELOAD processing. If running in STEP mode, this file
      must be input to every step
      .
SORTEXIT and FROM/STEP
When using the FROM and STEP options with the SORTEXIT option, each pair of SORT
n
 and DBL
x
 steps are considered to be one step. If either half of the SORT
n
/DBL
x
 is specified on a FROM or STEP option, processing will start with the SORT
n
 step and the DBL
x
 step will also be executed. For example:
  • FROM IDMSDBL3 will start with step SORT3 and will continue to the end.
  • STEP SORT3 will run steps SORT3 and IDMSDBL3.
SORTEXIT/REUSE WORKFILE restart considerations
Since SORTEXIT combines each SORT
n
 step with the DBL
x
 step that follows it, if a failure occurs in the DBL
x
 step, a restart (if a restart is possible) must begin with the sort step and the input to the step will be resorted. Non-SORTEXIT mode will take longer to run but can be restarted after the sort in this case. Therefore, if restart time is more critical than normal runtime do not run the utility as a sortexit.
If the REUSE WORKFILE option is used with SORTEXIT, some input workfiles will be used as output files in the same step. Therefore, if these two options are used together and a failure occurs, the utility must be restarted from the beginning.
Workfile considerations for restarting a failed RELOAD
If the RELOAD command fails, depending on the reason for failure, restart the command at the failing step using the "FROM step-name" syntax. You can restart a step only if the input files to that step are intact and valid.
To prepare for a possible restart when running a one-step RELOAD, the intermediate work files should have a disposition that preserves the data set in the event of an abend, for example, "DISP=(NEW,CATLG,CATLG)."
To restart RELOAD at a particular step, the input files to that step must have a disposition to specify that the files already exist, for example, "DISP=OLD."
To determine which files were input to a given step see the "Intermediate Work File" tables under "JCL Considerations." Partially created output files should be deleted before you restart the job, and the original disposition should be used in the restart job, for example, "DISP=(NEW,CATLG,CATLG)."
The SYSPCH file contains sort parameter information for sort steps. It is an output file to IDMSDBL
n
 steps but is not read unless restarting or running in step mode. So during a normal run the SYSPCH file should be treated as a normal output file, for example, "DISP=(NEW,CATLG,CATLG)." However, restarting is not as straightforward. If the previous job failed in an IDMSDBL
x
 step, the SYSPCH file was an output file and should be deleted before restarting. But if the failure occurred in a SORT
x
 step, the contents of the SYSPCH file should contain the same values that were input to the SORT
x
 step. In this case the SYSPCH file should be preserved and defined as a SYS001 input file to the restart step.
When the SORTEXIT option is used, the SORT
x
 and IDMSDBLx steps are combined. If a failure occurs in this mode, the SYSPCH file should normally be preserved and used as a SYS001 input file to the restart. However, there is a small window at the end of a IDMSDBL
x
 step where the SYSPCH file is opened for output and new SORT parameters are written. If the job fails at this point, the entire SORT
x
/IDMSDBL
x
 step must be restarted, but the SYSPCH file will not be valid as a SYS001 input file. In this case, the sort parameters must be recreated by hand or the job must be restarted at an earlier IDMSDBL
x
 step if possible. One way to avoid this situation is to run in step mode when running SORTEXIT mode.
The RELDCTL data set is always an input file to the first step of a RELOAD whether being restarted or not.
REUSE WORKFILE considerations
Some tape volume management systems consider the reuse of a tape volume for second time output processing an error even in the same job and will not allow you to make this mistake. It results in rerunning the job over again without the REUSE option. You can sometimes avoid this by specifying a zero retention period for the tape output volume.
Intermediate work files
The following tables indicate which work files are created and read by the different utility steps depending on the use of the SORTEXIT and REUSE WORKFILE options.
Step
Input
Output
RELOAD: NOT sortexit mode and NOT reusing workfile
SORT1
SYS002
SYS004
IDMSDBL2
SYS004
SYS005 SYS006
SORT2
SYS003 SYS006
SYS007
IDMSDBLX
SYS007
SYS008
SORT3
SYS005 SYS008
SYS009
IDMSDBL3
SYS009
SYS010
SORT4
SYS010
SYS011
IDMSDBL4
SYS011
 
RELOAD: NOT sortexit mode and REUSING workfiles.
SORT1
SYS002
SYS004
IDMSDBL2
SYS004
SYS005 SYS006
SORT2
SYS003 SYS006
SYS004
IDMSDBLX
SYS004
SYS006
SORT3
SYS005 SYS006
SYS004
IDMSDBL3
SYS004
SYS005
SORT4
SYS005
SYS004
IDMSDBL4
SYS004
 
RELOAD: SORTEXIT mode and NOT reusing workfiles.
SORT1/IDMSDBL2
SYS002
SYS005 SYS006
SORT2/IDMSDBLX
SYS003 SYS006
SYS008
SORT3/IDMSDBL3
SYS005 SYS008
SYS010
SORT4/IDMSDBL4
SYS010
 
RELOAD: SORTEXIT mode and REUSING workfiles.
SORT1/IDMSDBL2
SYS002
SYS005 SYS006
SORT2/IDMSDBLX
SYS003 SYS006
SYS006
SORT3/IDMSDBL3
SYS005 SYS006
SYS005
SORT4/IDMSDBL4
SYS005
 
How RELOAD works
The RELOAD utility consists of the following steps, which you can run separately or as a single operation. Each step uses the output from an earlier step and generates output for use by the next step.
Step
Description
Input
Output
Size
SORT1
Sorts the contents of SYS002.
  • SYS001 contains sort parameters from UNLOAD SYSPCH file
  • SYS002 contains the record information from UNLOAD
SYS004 contains the sorted record information
SYS004 record length = SYS002 record length from UNLOAD
IDMSDBL2
  • Populates the database by means of an area sweepbut does not connect any sets.
  • Prints statistics on the records written to the database.
Note:
 Overflow statistics may be fewer than expected. To improve performance during a reload, IDMSDBL2 uses the dbkey of the previously stored record as a 'direct' dbkey if the next record to be stored has the same new target page. This reduces the number of overflow conditions.
  • SYS004 from SORT1
  • RELDCTL file from UNLOAD utility
  • SYS005 contains member descriptors for chained sets
  • SYS006 contains member descriptors for user owned index sets
  • SYSPCH contains sort parameters
  • SYSLST contains statistics report
  • SYS005 record length = 32 bytes
  • SYS006 record length = 32 bytes
SORT2
Sorts the contents of SYS003 and SYS006.
  • SYS001 contains sort parameters from IDMSDBL2 SYSPCH*
  • SYS003 contains index information from UNLOAD
  • SYS006 contains member descriptors for user owned index sets from IDMSDBL2
SYS007 contains the sorted contents of SYS003 and SYS006
SYS007 record length = larger of RELOAD's SYS006 or UNLOAD's SYS003
IDMSDBLX
Establishes pointers for each index in which each record participates but does not build the indexes in the database.
  • SYS007 contains sorted index information from SORT2
  • RELDCTL file from UNLOAD utility
SYS008 contains reformatted index information
SYS008 record length = same as SYS007
SORT3
Sorts the contents of SYS005 and SYS008.
  • SYS001 contains sort parameters from IDMSDBL2 SYSPCH*
  • SYS005 from IDMSDBL2
  • SYS008 from IDMSDBLX
SYS009 contains sorted index set descriptors
SYS009 record length = larger of RELOAD's SYS008 or IDMSDBL2's SYS005
IDMSDBL3
  • Establishes pointers for each chained set in which each record participates (builds the record prefix) but does not write the prefixes to the database.
  • Builds indexes in the database.
  • SYS009 from SORT3
  • RELDCTL file from UNLOAD utility
  • SYS010 contains prefix pointer information
  • SYSPCH contains sort parameters
  • SYSLST contains a statistics report
SYS010 record length = 32 bytes
SORT4
Sorts the contents of SYS010.
  • SYS001 contains sort parameters from IDMSDBL3 SYSPCH*
  • SYS010 from IDMSDBL3
SYS011 contains sorted prefix pointer information
SYS011 record length = same as SYS010 from prior step
IDMSDBL4
Inserts the record prefixes by performing a serial sweep of the database.
  • SYS011 from SORT4
  • RELDCTL file from UNLOAD utility
SYSLST contains messages on the results of the reload operation
-
 
* The sort parameters noted in the previous table are read from SYS001, only when you run the sort steps individually. If you run all steps together or all steps from an intermediate restart (using FROM), the sort parameters are passed in-storage. If you restart from an abnormal termination, point the SYS001 file to the SYSPCH file of the last completed step.
Sort output after each step
If you run the RELOAD utility a step at a time, you must use the sort parameters in the SYSPCH file to sort the contents of the intermediate work files.
Sort the intermediate work files as follows:
Sort name
File to sort
Sort order
Sort on
Begins at
SORT1
SYS002
Descending
20 bytes
Byte 5
SORT2
SYS003 and SYS006
Ascending
24 bytes
Byte 5
SORT3
SYS005 and SYS008
Ascending
24 bytes
Byte 5
SORT4
SYS010
Ascending
16 bytes
Byte 5
The generated sort parameters are insufficient for stand-alone sort programs under z/VSE. If you want to use your own sort program, you must add 'WORK=' parameters to specify more than one file whose contents are to be sorted.
DBLUEREX User Exit
RELOAD modules IDMSDBL2, IDMSDBL3, and IDMSDBL4 have the ability to call a user exit named DBLUEREX when processing errors are encountered. This exit will be called if an unexpected error status is returned from a call to CA IDMS for all three modules. The exit is also called by IDMSDBL3 if an error is encountered while processing the intermediate file containing records to rebuild the database's chain sets.
The DBLUEREX module must be linked with each IDMSDBLx module from which the user wishes it to be invoked. The modules must be coded so that they are able to run with AMODE=31 and RMODE=ANY so that they will match the modes of the IDMSDBL? modules. The following statements should be used to link DBLUEREX with the desired module(s).

INCLUDE LIB1(DBLUEREX)
INCLUDE LIB2(IDMSDBL?)
ENTRY #DDNHD
where the ? represents 2, 3, or 4 depending on the module to which the exit is being linked.
Upon entry to DBLUEREX, Register 1 will point to a list of three full words with the following contents. The last full word in the list will have its high-order bit turned on to signal the end of the parameter list.
Offset
Description
x'00'
Address of an eight byte field containing the name of the module making the call.
x'04'
Address of the error status field in the run-unit's subschema control for calls from IDMSDBL2, IDMSDBL4, and IDMSDBL3 if a database error is encountered. This parameter will contain zeros if called by IDMSDBL3 when an error is encountered while processing the intermediate file containing records defining the database's chain sets.
x'08'
Address of the current input record being processed by the calling module.
JCL Considerations
When you submit a RELOAD statement through the batch command facility, the JCL to execute the facility must include statements to define:
  • Files containing the areas to be reloaded
  • Intermediate work files
  • Sort space
Work file JCL considerations for STEP mode
RELOAD normally runs as a single step but runs as separate steps using the "STEP step-name" syntax. When running in step mode, input files should have dispositions that state the file already exists, for example, "DISP=OLD".
Preserve output files on successful completion but not when the job fails, for example, "DISP=(NEW,CATLG,DELETE)."
See the "Intermediate Work File" table to determine which files are input and which files are output and when they are used.
The RELDCTL file is always input to every step.
The SYSPCH file is created by an IDMSDBLx step and used as input to a SORT
x
 step. When used as input, it is defined as SYS001.
Work file record lengths:
  • The RELDCTL file is a fixed-length file with a record length of 60 bytes.
  • The SYSPCH file is a fixed-length file with a record length of 80 bytes.
  • All SYS
    xxx
     files are variable length files. The record length can vary from one step to the next, from one job to the next. Do not code an LRECL value in the JCL, just code a BLKSIZE value. A BLKSIZE value should be chosen based on the optimal size for the device being used, for example, 1/2 track if disk or 32k if tape.
For more information about the generic JCL used to execute the batch command facility, see one of the following sample JCLs:
Example
The following example directs the RELOAD utility to reload a previously unloaded non-SQL-defined database.

reload;
The following command directs RELOAD to run all steps as a sortexit and to reuse workfiles:

reload as sortexit reuse workfiles;
Sample Output
The RELOAD utility generates the following listing after the successful execution of the RELOAD statement in the previous example. Note that the file the unloaded database is reloaded into is formatted first.

IDMSBCF                                              IDMS Batch Command Facility                            mm/dd/yy   PAGE 1

SET BATCH WIDTH PAGE 80 ;
Status = 0
FORMAT FILE USERDB.EMPF1;

File USERDB.EMPF1                blocks 1 to 50.
Area USERDB.EMP_AREA             pages 5,001 to 5,050.
Page size in file 4,096.

Status = 0
  RELOAD ;
UT010002 BEGINNING PROCESSING FOR STEP SORT1
UT009001 IDMSDBLY RELEASE nn.n TAPE volser SORT STARTED
UT009002    105 RECORDS WERE READ FROM SYS002
UT009003    105 RECORDS WERE WRITTEN TO SYS004
UT009004 IDMSDBLY RELEASE nn.n SORT COMPLETED SUCCESSFULLY
UT010003 STEP SORT1    HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP IDMSDBL2
UT005001 IDMSDBL2 RELEASE nn.n TAPE volser PROCESSING STARTED
UT005002 DATABASE LOAD STATISTICS
 DATABASE LOADED ON mm/dd/yy AT 123700
PAGES READ ...............            19
PAGES WRITTEN ............            18
PAGES REQUESTED ..........            20
CALC RCDS IN TARGET PAGE .            12
CALC RCDS OVERFLOWED .....             0
VIA RCDS IN TARGET PAGE ..            53
VIA RCDS OVERFLOWED ......             1
LINES REQUESTED BY IDMS ..           222
RCDS MADE CURRENT OF R/U .            64
CALLS TO IDMS ............            70
FRAGMENTS STORED .........             0
RECORDS RELOCATED ........             0

UT005003    77 INTERMEDIATE RECORDS WERE WRITTEN TO SYS006
UT005003    69 INTERMEDIATE RECORDS WERE WRITTEN TO SYS005
UT005004    SYS005   RECORD LENGTH IS 32
UT005005    NO DATABASE ERRORS WERE ENCOUNTERED
UT005006 IDMSDBL2 RELEASE nn.n PROCESSING COMPLETED
UT010003 STEP IDMSDBL2 HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP SORT2
UT009001 IDMSDBLY RELEASE nn.n TAPE volser SORT STARTED
UT009002    67 RECORDS WERE READ FROM SYS003
UT009002    77 RECORDS WERE READ FROM SYS006
UT009003    144 RECORDS WERE WRITTEN TO SYS007
UT009004 IDMSDBLY RELEASE nn.n SORT COMPLETED SUCCESSFULLY
UT010003 STEP SORT2    HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP IDMSDBLX
UT008001 IDMSDBLX RELEASE nn.n TAPE volser PROCESSING STARTED
UT008002    67 RECORDS WERE WRITTEN TO SYS008
UT008006 IDMSDBLX RELEASE nn.n PROCESSING COMPLETED
UT010003 STEP IDMSDBLX HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP SORT3
UT009001 IDMSDBLY RELEASE nn.n TAPE volser SORT STARTED
UT009002    69 RECORDS WERE READ FROM SYS005
UT009002    67 RECORDS WERE READ FROM SYS008
UT009003    136 RECORDS WERE WRITTEN TO SYS009
UT009004 IDMSDBLY RELEASE nn.n SORT COMPLETED SUCCESSFULLY
UT010003 STEP SORT3    HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP IDMSDBL3
UT006001 IDMSDBL3 RELEASE nn.n TAPE volser PROCESSING STARTED
UT006007    136 INTERMEDIATE RECORDS WERE READ FROM SYS009
UT006002    42 INTERMEDIATE RECORDS WERE WRITTEN TO SYS010
UT006005    NO DATABASE ERRORS WERE ENCOUNTERED
UT006006 IDMSDBL3 RELEASE nn.n PROCESSING COMPLETED
UT010003 STEP IDMSDBL3 HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP SORT4
UT009001 IDMSDBLY RELEASE nn.n TAPE volser SORT STARTED
UT009002    42 RECORDS WERE READ FROM SYS010
UT009003    42 RECORDS WERE WRITTEN TO SYS011
UT009004 IDMSDBLY RELEASE nn.n SORT COMPLETED SUCCESSFULLY
UT010003 STEP SORT4    HAS COMPLETED SUCCESSFULLY
UT010002 BEGINNING PROCESSING FOR STEP IDMSDBL4
UT007001 IDMSDBL4 RELEASE nn.n TAPE volser PROCESSING STARTED
UT007004    NO DATABASE ERRORS WERE ENCOUNTERED
UT007005    NO LOGIC ERRORS WERE ENCOUNTERED
UT007002    42 RECORDS WERE READ FROM SYS011
UT007006 IDMSDBL4 RELEASE nn.n PROCESSING COMPLETED
UT010003 STEP IDMSDBL4 HAS COMPLETED SUCCESSFULLY
UT010001 DATABASE RELOAD HAS COMPLETED SUCCESSFULLY
Status = 0

AutoCommit will COMMIT transaction

Command Facility ended with no errors or warnings