Upgraded to SOLVE:Operations 11.9 recently.
The RUNSYSIN is modified to write logs out to data sets instead of JES.
However, the JES log shows the log abending with
At this point, if I try to look at LOG2 (or may be enmpt on a new reigon, it has old data, but LOG1 is not logging further information.
All SOLVE and Netmaster products
The product is working as designed.
Hardcopy logs (dataset instead of SYSOUT) are purposely defined with no secondary extents.
An SD37-04 occurs when one log fills up and the logswap process switches over to use the next log.
Here is what can be expected each time a logswap occurs for these files:
1. LOG1 has enough records written to it that it hits the end of the dataset, which causes an SD37-04 and swaps the log.
The JESMSGLG shows:
The activity log (/LOG from any command line in SOLVE) shows
At this point, if I try to look at LOG2, it may appear to either be empty or contain old information, but LOG1 is not logging further information.
So it looks like there's a problem.
However,when I go to CMD and issue SHOW LOGFILES I see
So LOG2 is actually in use. The reason it initially appears to contain old/missing information is that the buffer that writes to the LOGx is not yet full.
This is generally only an issue on a test system with little traffic.
Once the buffer writes out to LOG2, the data will be visible.
This same processes and messages apply when going from LOG2 to LOG3, or from LOG3 back to LOG1.
Once all logs contain data, a logswap causes new data to overwrite the old, so you might see something like
So the SD37-04 is simply the log spin doing its thing.
If you need to see logging information that is not yet appearing in the hardcopy logs, you can view the log directly from the SOLVE / Netmaster region by logging on and issuing either /LOG or $LOG from any command line. This data is stored in the hlq.LOG01-LOG03 VSAM files defined in the LOGFILES parameter group.