Stratum.Server: DALOAD & GISLSDRV

Published by

Stratum Under CoversIn my previous posts, I covered the four main components of Stratum.  Now, it’s time to get a little more in-depth about each of them!

In this post, we’ll cover the Stratum.Server DALOAD process for IBMi and the equivalent GISLSDRV process for Windows.  My previous Stratum.Server post discussed how the IMPDATA command on IBMi and the GISLSDRV executable on Windows summarize data in the XXIMPORT table(s) and write it to the EXTPNDXX table(s) or optionally to the temporary .txt file in the case of GISLSDRV.

DALOAD on IBMi

The DALOAD command retrieves data by category / year from the EXTPNDXX table(s) and updates the corresponding category / year data summary levels (DSLs) in the Stratum database. If the corresponding category / year DSLs are not found in the Stratum database, the DALOAD command will ignore that particular data set and move on to the next category/year combination.

The DALOAD process on IBMi creates log files that can be very useful in understanding what happened during the DALOAD process and in troubleshooting should DALOAD end abnormally. The log file(s) are labeled QDSXX where XX represents the category. These log file(s) will show the source file (EXTPNDXX) used by DALOAD, the number of records read from the source file, the number of records used, the DSLs and years that were updated, and the elapsed time to complete the job.

Should you encounter a situation where DALOAD read a number of records but the number of records used was zero, this almost always indicates that DALOAD did not find any DSL(s) for the category / year it was processing at the time. There is also a corresponding IBMi job log for the DALOAD process. The job log provides information related to the library list used, the DALOAD job subsystem, the user ID used to run the job, etc.

When the DALOAD process completes successfully the “complete” field in the STCSDT16 table will have a value of 2 and the “status” field in the STCSGI10 table will have a value of 99. Any other value in these fields indicates that DALOAD did not complete successfully and will prevent DALOAD from running again until the problem is resolved.

GISLSDRV on Windows

The GISLSDVR executable retrieves data by category / year from either the EXTPNDXX table(s) or the temporary .txt file and updates the corresponding category / year data summary levels (DSLs) in the Stratum database. If the corresponding category / year DSLs are not found in the Stratum database, the GISLSDRV executable will ignore that particular data set and move on to the next category/year combination.

The GISLSDRV creates a log file that can be very useful in understanding what happened during the DALOAD process and in troubleshooting should DALOAD end abnormally. The log file is by default created in the DTDATA directory and is called GI.log. It is possible to override the default directory at installation time whereby the GI.log file could be located in another directory. The log file will show the source file (EXTPNDXX or .txt) used by GISLSDRV, the number of records read from the source file, the number of records used, the DSL’s and years that were updated and the elapsed time to complete the job.

Should you encounter a situation where GISLSDRV read a number of records but the number of records used was zero, this almost always indicates that GISLSDRV did not find any DSL(s) for the category / year it was processing at the time.

Each GISLSDRV process adds entries to the log file and over time this log file can become quite large. We recommend that you monitor the size of this file and occasionally delete it. The next GISLSDRV process will automatically recreate the file.

When the GISLSDRV process completes successfully the “complete” field in the STCSDT16 table will have a value of 2 and the “status” field in the STCSGI10 table will have a value of 99. Any other value in these fields indicates that GISLSDRV did not complete successfully and will prevent GISLSDRV from running again until the problem is resolved.

 

Categorized in:

This post was written by Steve Morgan