OPSMVS: OPSOSF Server suspended due to CATALOG AS failure

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

OPS/MVS was started with SUB=MSTR. 

It can happen that, due to a CATALOG AS failure, OPSOSF Servers are not able to provide service at all due to 'max transaction time exceeded' and they are suspended. 

Any solution that can avoid this? 

Environment

Release : All

Component : OPS/MVS

Resolution

If the z/OS CATALOG AS is not functioning, then the OPSOSF proc would not be able to start as any datasets referenced in the JCL, that are managed by a Catalog, would not be accessible. This could further extend to the OPSLOG and SYSCHK1 datasets as well.

To avoid this situation, it is possible to include the VOL=SER= and the UNIT= parameters on the DD statements for all OSF referenced datasets and for the allocation of the OPSLOG and SYSCHK1 datasets. Although this is the primary purpose of the CATALOG AS, in this way these datasets will be referenced as though they were not cataloged and therefore need to ALWAYS maintain the JCL to insure the VOL=SER= was currently accurate.

The CATALOG AS is a basic component of Z/OS and the solution provided is just a known method using JCL with un-cataloged datasets - specify the VOL=SER= and UNIT= parameters on DD statements.

The other alternative from an OPS/MVS perspective would be to have the CATALOG AS managed by OPS/MVS, and possibly SSM, to insure it is up and executing properly based on system events and proactive probing of the Catalog address space.