Recovering from a log stream problem

In the event of a problem with a specific log stream, you might need to keep DFSMStvs from using the log stream while you correct the problem. To stop DFSMStvs from using the log stream, follow these steps:

Use the VARY SMS,LOG operator command to quiesce or disable DFSMStvs from using the log stream. If the log stream is usable but currently experiencing problems, quiesce access to it. This enables DFSMStvs to complete processing of any in-progress units of recovery. If the log stream has become unusable, disable it. This causes DFSMStvs to stop using the log stream immediately.
Recommendation: Be careful about quiesce with a path name; always use a base name.

If you disable DFSMStvs, it goes into a disabling state in which it rejects any new record management requests (get, point, put, or erase). For DFSMStvs to go into a disabled state, all current transactions must be brought to a sync point (committed or backed out) and all ACBs must be closed.

If you quiesce DFSMStvs, it goes into a quiescing state in which it processes record management requests for existing transactions but fails any record management request that would initiate a new transaction. For DFSMStvs to go to a quiesced state, all current transactions must be brought to a sync point and all ACBs must be closed.

Quiescing or disabling a DFSMStvs primary system (undo) log or secondary system (shunt) log is equivalent to quiescing or disabling DFSMStvs. DFSMStvs processing is unavailable until the log is re-enabled.
For a system log problem, identify and recover any data sets that might have been involved in in-flight units of recovery.
1. Do not try to bring DFSMStvs back up until you have finished this procedure.
2. Obtain a dump of XCF and system logger address spaces from all systems by issuing the following series of MVS™ commands:
```
DUMP COMM=(meaningful dump title)
R ww,JOBNAME=(IXGLOGR,XCFAS,cics_job),DSPNAME=('IXGLOGR'.*,'XCFAS'.*),CONT
R xx,STRLIST=(STRNAME=structure,(LISTNUM=ALL),ACC=NOLIM),CONT
R yy,REMOTE=(SYSLIST=*('XCFAS','IXGLOGR'),DSPNAME,SDATA),CONT
R zz,SDATA=(COUPLE,ALLNUC,LPA,LSQA,PSA,RGN,SQA,TRT,CSA,GRSQ,XESDATA),END
```
  Use the R xx,STRLIST=(STRNAME=structure,(LISTNUM=ALL),ACC=NOLIM),CONT instruction only where you suspect a problem with the coupling-facility structure.
3. Use the log data to identify any data sets that might have been involved in in-flight units of recovery.
4. For forward recoverable data sets, revert to the last good backup of the data set and apply forward recovery to it. Make sure not to apply anything that might belong to the in-flight unit of recovery because backout would not have been able to write the compensating records.
5. For data sets that are not forward recoverable, you probably need to look at the individual log records and fix each of the record manually by looking at what your batch job was doing and putting the records back the way they were. DFSMStvs log records include the subsystem ID, like IGWTVS01 and IGWTVS02.
Correct the problem. If the log is severely damaged, this might involve deleting and redefining it. If you delete and redefine the primary system log, ensure that any incomplete units of recovery are discarded. One way to do this is to cold start DFSMStvs, following these steps:
1. Use SET SMS=xx to assign an IGDSMSxx parmlib member in which a start type of cold is specified (TV_START_TYPE(COLD)) .
2. Use the V SMS,TRANVSAM(nnn),E command to restart DFSMStvs.
3. Use the SET SMS command (TV_START_TYPE) to specify a PARMLIB member that has a start type of WARM.
Re-enable the log stream to give DFSMStvs access using the VARY SMS,LOG operator command.