SVT1LOG41W @LOGEXIT RC=4 REASON=407 MODID=SVTSVQUE,BUF#=0000005 when LOGGER data set is not present.
search cancel

SVT1LOG41W @LOGEXIT RC=4 REASON=407 MODID=SVTSVQUE,BUF#=0000005 when LOGGER data set is not present.

book

Article ID: 121521

calendar_today

Updated On:

Products

Vtape Virtual Tape System

Issue/Introduction



We conducted a Disaster Recovery test using Duplex tapes and copies of BSDS etc. 
All went very well.

One small niggle. I presume every time it wrote a record out to the log, certainly quite regularly, we saw message 
SVT1LOG41W @LOGEXIT RC=4 REASON=407 MODID=SVTSVQUE,BUF#=0000005 

Your manual refers me to the IBM IXGWRITE which says 
RC=4 - processed successfully with a warning 
REASON=407 suggests there is a block missing between this block and the one previously returned. 

We delete all the logger log data sets before starting up VTAPE 
I don't think we need the data in these logs if we invoked DR. 
Is there a way tell it to ignore this, or to do some sort of cold Start. 
Or do we need these logs backing up at same time as BSDS? 

Environment

Release: 12.6
Component: Vtape

Resolution

There are 2 options to deal with this problem: 


1) Deactivate the Logger in the VTPARMS member when you do a DR 
2) Restore the active Logger data set backup at the same time as the BSDS. 

Here is what the IBM Redbook says: 


DASD-only log stream recovery like a CF-Structure based log stream, a DASD-only log stream can be affected by a system or System Logger failure. However, because DASD-only log streams are always duplexed to DASD, it is not necessary to go through the same recovery process that is required for CF-Structure based log streams, where System Logger attempts to move the log data to a non-volatile medium as quickly as possible. Also, because DASD-only log streams can only be accessed by one system at a time, the concept of peer recovery does not apply. Recovery for a DASD-only log stream only takes place when an application reconnects to the log stream. As part of connect processing, the System Logger reads log data from the staging data set (associated with the last connection to the log stream) into the local buffers of the current connecting system. This allows the application to control recovery, by selecting which system they wish to have reconnect to the log stream and when. Note that for another system to connect to the log stream and perform recovery, the staging data sets must reside on devices accessible by both systems. 

Here is the link of this documentation: 

IBM Redbook
 
So it is important for the MVS LOGGER address space to read the latest data written into the active logger for Vtape to pursue writing into it on the DR restart.