IMS Crash and SYSVIEW SDUMP with GoldenGate

Products

• SYSVIEW Performance Management

Issue/Introduction

• CA sysview sdump produced
• IMS Abended at same time 
• IBM has requested CA SYSVIEW investigate
• Occurred on 3rd processor upgrade

Environment

Release : 15.0

Component : SYSVIEW

Cause

Golden Gate software prior to release 19.1.0.0.2.

Resolution

It was determined that SYSVIEW was a victim of the situation.  The underlying cause is potentially linked to Golden Gate and appears to be a task-startup timing issue at IPL:

 If the GoldenGate Extract starts BEFORE most other ECSA users:

1. 1. The redundant free-ECSA request will be ignored (with a non-zero storage return code).
   2. Then GoldenGate and later ESCA requestors can obtain valid ECSA storage without issue.
2. If the GoldenGate Extract starts AFTER a ECSA user, such as IMS, starts:
   1. The GoldenGate free-ECSA request can free the common storage now obtained by the other user -- resulting in an ABEND0C4 forone of more
   2. In fact, GoldenGate’s freeing of critical system storage could cause a system crash or hang!
   3. Fortunately, the probability of a system crash is low since GoldenGate Extract starts after most system tasks and can never share their storage.

 The reported GoldenGate error condition is fixed in version 19.1.0.0.2.

 For earlier releases of Golden Gate there is a workaround:

 ‘GoldenGate Application Support’ to delete a status file, ./dirtmp/ecsainfo.dat, on the zLinux platform.

 However, this could cause mainframe common ‘storage leaks’ if it is done indiscriminately.

 A more restrictive workaround would be to delete the file only before starting the GoldenGate Extract process with each IPL.

This would require a new co-ordination effort between MVS Support and GoldenGate Application Support for mainframe IPLs.