Thanks Chuck,
I am going to look into this more on Monday and ask the customer what they
want to do.
John
-----Original Message-----
From: CRPence [mailto:crpbottle@xxxxxxxxx]
Sent: Friday, April 17, 2015 8:43 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
