How to LOG to flat files
Article ID: 139595
Updated On:
Products
Issue/Introduction
By default, IDMS maintains its internal LOG in the SYSTEM.DDLDCLOG area of the DMCL.
Internally, this is an IDMS database.
Alternatively, it is possible to configure IDMS to LOG to flat files.
This article describes how to do this, how it works, and the pros and cons of doing so.
Environment
Release : All supported releases.
Component : CA IDMS
Resolution
In the SYSGEN SYSTEM statement, instead of LOG DATABASE, code something like this:
LOG TYPE OS FILE1 CDMSLOGA COUNT1 100000 FILE2 CDMSLOGB COUNT2 100000
Allocate the two physical files, for example IDMS.CV01.CDMSLOGA and IDMS.CV01.CDMSLOGB.
These files must have RECFM=FB,LRECL=133 and BLKSIZE a multiple of 133.
They do not need to be FORMATted in any way.
Define the two files to the CV startup JCL:
//CDMSLOGA DD DSN=IDMS.CV01.CDMSLOGA,DISP=SHR
//CDMSLOGB DD DSN=IDMS.CV01.CDMSLOGB,DISP=SHR
Now when IDMS is re-started, it will LOG to these files and not the SYSTEM.DDLDCLOG area.
IDMS will start by logging to CDMSLOGA.
When CDMSLOGA fills, it automatically switches to CDMSLOGB.
When CDMSLOGB fills, it automatically switches back to CDMSLOGA and starts to write to the file from the beginning again.
This will overwrite what was there when it first logged to CDMSLOGA.
There is no ARCHIVE LOG utility as there is when LOGging to DATABASE.
The files are simply flat files so if archiving the log is required, it will be necessary to run an IEBGENER job to copy each file as they fill.
When a file fills, IDMS writes the following message to the CV joblog,:
CDMSLOGB IS NOW THE CURRENT LOG FILE.
If automatic and consistent archiving of the log is required, consider updating the WTOEXIT process to test for the above message and submit an appropriate job to do the IEBGENER.
Pros and Cons
When logging to files is in use, OLP is not available. It gives this message:
IDMS DC297901 V65 T54 LOG MUST BE TO DATABASE IN ORDER TO USE ONLINE PLOG
Instead, it is possible to simply browse the files in ISPF in order to view the log.
Also, the writing of DC and Performance Monitor statistics is impacted by logging to files.
DC statistics are written in "SNAP" format instead of the internal format in which they would be written to the DDLDCLOG area.
This means that it is not possible to run batch SREPORTS.
Performance Monitor statistics are not written at all, so the only option to be able to run Performance Monitor reports is to use SMF.
Performance
In general, it is expected that logging to files is slightly better performance wise than logging to DATABASE.
However it is doubtful that the benefit is worth the disadvantages of not having OLP, not being able to run batch statistics reports, and having to create and maintain a separate archiving process.
Additional Information
Feedback
