LOG datasets in SOLVE / Netmaster getting SD37-04 abend

book

Article ID: 186194

calendar_today

Updated On:

Products

CA SOLVE:Operations Automation CA SOLVE:FTS CA SOLVE CA Mainframe Connector for Linux on System z CA NetMaster File Transfer Management CA NetMaster Network Automation CA NetMaster Network Management for SNA CA NetMaster Network Management for TCP/IP CA SOLVE

Issue/Introduction

Upgraded to SOLVE:Operations 11.9 recently. 

The RUNSYSIN is modified to write logs out to data sets instead of JES.

It shows
      DD=LOG1,DISP=SHR,DSN=hlq.LOG1 
      DD=LOG2,DISP=SHR,DSN=hlq.LOG2        
*     DD=LOG3,DISP=SHR,DSN=hlq.LOG3       
*     DD=LOG4,SYSOUT=*,FREE=CLOSE       
*     DD=LOG5,SYSOUT=*,FREE=CLOSE         
*     DD=LOG6,SYSOUT=*,FREE=CLOSE 
*     DD=LOG7,SYSOUT=*,FREE=CLOSE               
*     DD=LOG8,SYSOUT=*,FREE=CLOSE    
*     DD=LOG9,SYSOUT=*,FREE=CLOSE                             


However, the JES log shows the log abending with
13.18.28 S0000311  IEC031I D37-04,IFG0554P,NMCS71,[email protected],LOG1,20B6,NMD037,  732
   732             AUCM0.NMCS7161.LOG1   


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.

Cause

Not an error

Environment

All SOLVE and Netmaster products

 

Resolution

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:   
13.18.28 S0023516  IEC031I D37-04,IFG0554P,NMCS71,[email protected],LOG1,20B6,NMD037,  732
   732             AUCM0.NMCS7161.LOG1   

The activity log (/LOG from any command line in SOLVE) shows
13.18.28 N16103 I/O ERROR ON ACTIVITY LOG DD=LOG1 , ABEND CODE=D37-04, USING NEXT LOG.  
13.18.28 N16110 LOGSWAP COMPLETED, NEW LOG DD=LOG2                                      


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
 sh logfiles                                                                           
 N11924 -DD-   STATUS-   ---START TIME--   ---STOP TIME---  PAGES   -SWAPPED BY-       
 N11923 LOG1   SWAPPED   20.069 13.16.52   20.069 13.18.28    181   FULL               
 N11923 LOG2   IN USE    20.069 13.18.28                       37                      
 N11907 *END*                                                                          
 ** END OF DELIVERED MESSAGES **   

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

005064 14.04.56.57  *001185*  THOLO01    N22202 MAIVAUTH YES                       DEFAULT        -
005065  14.04.56.57  *001185*  THOLO01    N22202 MAXRUSZ  4096                      DEFAULT        -
005066  14.04.56.57  *001185*  THOLO01    N22202 MDFYLIM  5                         DEFAULT        - 
005067  13.18.26.24  BG-SYS    C716BSYS   4466 3390 F-NRD      
005068  13.18.26.24  BG-SYS    C716BSYS   4467 3390 F-NRD     
005069  13.18.26.24  BG-SYS    C716BSYS   4468 3390 F-NRD   
                                              
So the SD37-04 is simply the log spin doing its thing.

Additional Information

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.