OPSMVS Clarification of Hyper notification for SO05663 - SO05676 - SO05680
Article ID: 117366
Updated On:
Products
OPS/MVS Event Management & Automation
Issue/Introduction
Hyper notification for possible Address Space hang due to latches possibly leading to an IPL.
It is possible for address spaces to become hung up behind a latch holder from OPSMVS. This may cause a system outage. A possible deadly embrace scenario can occur if the OPS4290 message is issued on a system where a rule fires on it and does an SQL call if the message was issued because of a prior SQL INSERT or UPDATE. Other possible scenarios include a low priority unit of work obtains a latch due to a rule that fired on it and becomes suspended due to system workload. Other units of work may end up as waiters for the latch that the first unit of work obtained. This may only occur on OPSMVS 12.3 and up with the following PTF's applied:
12.3 SO01035
13.0 SO00647
13.5 SO00597
The impact could be a System outage that could cause a forced IPL.
The PTFs CIRCUMVENTION specifies that the exposure to the problem may be limited by disabling rules that perform SQL operations, especially rules that fire on all messages.
Any additional detail about the causes of the problem and how to prevent it?
It is possible for address spaces to become hung up behind a latch holder from OPSMVS. This may cause a system outage. A possible deadly embrace scenario can occur if the OPS4290 message is issued on a system where a rule fires on it and does an SQL call if the message was issued because of a prior SQL INSERT or UPDATE. Other possible scenarios include a low priority unit of work obtains a latch due to a rule that fired on it and becomes suspended due to system workload. Other units of work may end up as waiters for the latch that the first unit of work obtained. This may only occur on OPSMVS 12.3 and up with the following PTF's applied:
12.3 SO01035
13.0 SO00647
13.5 SO00597
The impact could be a System outage that could cause a forced IPL.
The PTFs CIRCUMVENTION specifies that the exposure to the problem may be limited by disabling rules that perform SQL operations, especially rules that fire on all messages.
Any additional detail about the causes of the problem and how to prevent it?
Environment
Release:
Component: OPSMVS
Component: OPSMVS
Resolution
The problem typically occurs on systems where a MSG * rule is issuing SQL updates and either
- had the OPS4290 message issued
- a unit of work holding the latch was suspended by WLM.
The low priority unit of work scenario isn't a deadly embrace, but can hang other address spaces if they issue messages/commands etc. that have OPS/MVS rules for them that issue SQL requests. If enough of the suspended events occur all OPSMVS process blocks may be used up, so that we don't even see an EOM or EOT from the low unit of work task that goes away. In which case everything that is hung up will stay that way, until an IPL.
If there isn't any rule that use SQL, the exposure to this would be limited to the following, assuming the STATEMAN component of OPS/MVS is not used (since it does use rules with SQL).
If a low priority piece of work such as a batch job that runs an OPS/REXX program or TSO/E rexx program using OPSMVS SQL is suspended by WLM while holding a latch other units of work maybe suspended waiting for a latch. These could be other batch jobs, or TSO users using the OPSVIEW table editor, or REXX routines accessing OPSMVS RDF tables, as well as work in OSF servers utilizing SQL as well.
If OPSMVS RDF tables are not used at all, then there isn't any risk..
The fix for 12.3.is SO05663
The fix for 13.0 is SO05676
The fix for 13.5 is SO05680
The Hyper flag has been set for 2 main reasons:
1. the PTF corrects a PE PTF
2. the bug if the PTF is not applied can cause IPL in production.
- had the OPS4290 message issued
- a unit of work holding the latch was suspended by WLM.
The low priority unit of work scenario isn't a deadly embrace, but can hang other address spaces if they issue messages/commands etc. that have OPS/MVS rules for them that issue SQL requests. If enough of the suspended events occur all OPSMVS process blocks may be used up, so that we don't even see an EOM or EOT from the low unit of work task that goes away. In which case everything that is hung up will stay that way, until an IPL.
If there isn't any rule that use SQL, the exposure to this would be limited to the following, assuming the STATEMAN component of OPS/MVS is not used (since it does use rules with SQL).
If a low priority piece of work such as a batch job that runs an OPS/REXX program or TSO/E rexx program using OPSMVS SQL is suspended by WLM while holding a latch other units of work maybe suspended waiting for a latch. These could be other batch jobs, or TSO users using the OPSVIEW table editor, or REXX routines accessing OPSMVS RDF tables, as well as work in OSF servers utilizing SQL as well.
If OPSMVS RDF tables are not used at all, then there isn't any risk..
The fix for 12.3.is SO05663
The fix for 13.0 is SO05676
The fix for 13.5 is SO05680
The Hyper flag has been set for 2 main reasons:
1. the PTF corrects a PE PTF
2. the bug if the PTF is not applied can cause IPL in production.
Feedback
Yes
No
Powered by
