The RELOAD utility reloads a database using input created by the UNLOAD utility statement.
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:
To reload data into a segment, you need the privilege DBAWRITE on all areas associated with the segment.
►►─── RELOAD ─┬──────────────────────┬────────────────────────────────────────► ├─ STEP ─┬─ step-name ─┘ └─ FROM ─┘ ►─┬──────────────────────────────┬───────────────────────────────────────────► └─ NOTIFY notify-record-count ─┘ ►─────┬─────────────────┬────────────────┬─────────────────────┬─────────────►◄ └── as SORTEXIT ──┘ └── REUSE workfiles ──┘
- STEPSpecifies 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-nameSpecifies the name of the step to execute.The name must be one of the following:
- FROMSpecifies 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-nameSpecifies the name of the step to execute.The name must be one of the following:
- NOTIFYIndicates a message is sent to the system console after a specified number of records have been processed in the current step.
- notify-record-countSpecifies 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 SORTEXITCauses each DBLxstep 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 workfilesCauses 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.
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 notsimply 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 filemust be input to every step.
SORTEXIT and FROM/STEP
When using the FROM and STEP options with the SORTEXIT option, each pair of SORT
xsteps are considered to be one step. If either half of the SORT
xis specified on a FROM or STEP option, processing will start with the SORT
nstep and the DBL
xstep 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
nstep with the DBL
xstep that follows it, if a failure occurs in the DBL
xstep, 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
nsteps 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
xstep, the SYSPCH file was an output file and should be deleted before restarting. But if the failure occurred in a SORT
xstep, the contents of the SYSPCH file should contain the same values that were input to the SORT
xstep. 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
xand 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
xstep where the SYSPCH file is opened for output and new SORT parameters are written. If the job fails at this point, the entire SORT
xstep 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
xstep 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.
RELOAD: NOT sortexit mode and NOT reusing workfile
RELOAD: NOT sortexit mode and REUSING workfiles.
RELOAD: SORTEXIT mode and NOT reusing workfiles.
RELOAD: SORTEXIT mode and REUSING workfiles.
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.
Sorts the contents of SYS002.
SYS004 contains the sorted record information
SYS004 record length = SYS002 record length from UNLOAD
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.
Sorts the contents of SYS003 and SYS006.
SYS007 contains the sorted contents of SYS003 and SYS006
SYS007 record length = larger of RELOAD's SYS006 or UNLOAD's SYS003
Establishes pointers for each index in which each record participates but does not build the indexes in the database.
SYS008 contains reformatted index information
SYS008 record length = same as SYS007
Sorts the contents of SYS005 and SYS008.
SYS009 contains sorted index set descriptors
SYS009 record length = larger of RELOAD's SYS008 or IDMSDBL2's SYS005
SYS010 record length = 32 bytes
Sorts the contents of SYS010.
SYS011 contains sorted prefix pointer information
SYS011 record length = same as SYS010 from prior step
Inserts the record prefixes by performing a serial sweep of the database.
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:
File to sort
SYS003 and SYS006
SYS005 and SYS008
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.
Address of an eight byte field containing the name of the module making the call.
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.
Address of the current input record being processed by the calling module.
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
xstep. 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 SYSxxxfiles 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:
The following example directs the RELOAD utility to reload a previously unloaded non-SQL-defined database.
The following command directs RELOAD to run all steps as a sortexit and to reuse workfiles:
reload as sortexit reuse workfiles;
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