Re: Exit program not called. Reason code 2.

On 17-Apr-2015 11:41 -0500, John Allen wrote:

On 16-Apr-2015 10:39 -0500, CRPence wrote:

<<SNIP>> v5r1m0 APAR SE10152 <<SNIP>>

I suspect the Save Object (SAVOBJ) and then Restore Object
(RSTOBJ) of the *EXITRG object named QUSEXRGOBJ in QUSRSYS
[effecting a simple restore-over of the object with the identical
copy on media] will effect the correction; that save taken on the
same system as the system exhibiting the error [no need to take one
from elsewhere, possibly losing or adding something not consistent
with the PTF level installed on the customer system], and of course
the restore done there as well.
<<SNIP>>

<<SNIP>>

So simply doing the following should fix the issue?

1. SAVOBJ OBJ(QUSEXRGOBJ) LIB(QUSRSYS) DEV(*SAVF) OBJTYPE(*EXITRG)
SAVF(TEMP/SAVEXITREG)

Followed with

2. RSTOBJ OBJ(QUSEXRGOBJ) SAVLIB(QUSRSYS) DEV(*SAVF)
OBJTYPE(*EXITRG) SAVF(TEMP/SAVEXITREG)

Optionally add steps [collated accordingly]:

1.2) DMPOBJ QUSRSYS/QUSEXRGOBJ *EXITRG
1.4) DSPSPLF QPSRVDMP SPLNBR(*LAST)
1.6) F16=Find on: QIBM_QCA
1.8) expected result: CPI3407 "Character string not found in file."

2.2) DMPOBJ QUSRSYS/QUSEXRGOBJ *EXITRG
2.4) DSPSPLF QPSRVDMP SPLNBR(*LAST)
2.6) F16=Find on: QIBM_QCA
2.8) expected result: CPI3408 "String found in position 100." and very near exactly the following in the /eye-catcher/ area in ~column positions 87 to 120:

* 0 QIBM_QCA_CHG_COMMAND*
*CHGC0100 1 *
**NONE *
* æ °*
* µ QIBM_QCA_RTV_COMMAND*
*RTVC0100 1 *
**NONE *

Those explicit steps 1) and 2) are what I meant to imply, despite that a pedantic reading of the APAR would have me second-guessing myself. The copy of the APAR SE10152 [that was culled from the web] is arguably very poorly worded. But from what I recall about the problem on those releases with those missing QIBM_QCA* Exit Points, and the apparently matching situation on that customer's system, I have almost no doubt about those [save and restore] actions effecting recovery... without having to do anything more [except to create the save file as a pre-requisite and to delete the save file after the completion].

This is not my system and I would not want to do anything to bring it
down or to affect their applications.

I would be remiss in failing to note that:

• Such actions would best be delayed until a restricted state with the aim of minimizing any possible negative effects _during_ the restore activity. And ideally also to be scheduled during a restricted state, after which an pwrdwn\IPL sequence *also* could be scheduled [if deemed necessary], as an action that _could be_ presumed corrective to any negative effects that persisted rather than a negative effect that was exhibited _only in the moment_ that the restore [and post-restore fix-up] transpired.

That being said, I am confident that:

• Based on my expectation [rather than actual understanding] of both the Save and Restore against that simple space object [of hex type 0x19 subtype 0x13 with symbolic type *EXITRG and] named QUSEXRGOBJ in QUSRSYS, there will be _no noticeable effect_ on jobs across the system.

• I am correct in my expectation [rather than actual understanding] _about how_ that object is referenced at run-time by the Command Analyzer [i.e. system pointer resolved, a pointer to the object and\or space of the object is stored, and the object\space is re-resolved if a MCH3402 transpired due to the object having been replaced-by-restore], such that chances for problems being encountered would be extremely low even if the save\restore was performed while the system is /active/ and the chances for problems approaching nil if the save\restore was performed while the system is in restricted-state.

• If any such negative effects were noticed, they likely would be few and most any likely mostly non-disruptive and almost surely limited to those operations that would span the tiny window of time *during* the restore; operations having made an inquiry against the registry at that moment. I expect the effect would be the same msg CPI0001 "Exit program not called. Reason code &1." already mentioned in this topic thread, but possibly preceded by both the logged MCH3402 [aka exception x2204] and the CPF3CDA "Registration facility repository not available for use."

• Conspicuously, any _commands_ for which there were an expectation of, or for whatever reason the OS looks for [what was the impetus for the OP], an exit program for either of those missing QIBM_QCA* exit points, because they are already missing, the situation is unchanged; i.e. impossible to have any exit-programs for non-existent exit-points, so any processing diagnosing those missing exit points would continue until after the post-restore fixup.