Re: Exit program not called. Reason code 2.

On 16-Apr-2015 16:35 -0500, John Allen wrote:

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

<<SNIP rqs for more info about the OP failing scenario; see:
<http://archive.midrange.com/midrange-l/201504/msg00437.html>>>

Here is additional information to address your response

1. They are running V5R2 (probably why they are not under IBM
support)

Ugh. That was when the alluded /corruption/ of the *EXITRG object QUSEXRGOBJ in library QUSRSYS was likely specifically what was seen. See my other replies to this message thread, both mentioning v5r1m0 APAR SE10152:
<http://archive.midrange.com/midrange-l/201504/msg00485.html>
<http://archive.midrange.com/midrange-l/201504/msg00488.html>

2. No the first invocation of DDINSTALL did not perform without any
errors.
They installed our software using RSTLIB
Then they execute DDINSTALL to do some setup processing and it
generates the error first time and every time as well as when they
execute any of our commands (Programs work fine)

That makes more sense. Otherwise I would have expected the origin to have been something as a side effect of the noted /install/ or something between that installation and the eventual first incident. The origin is likely long-existing, and as described by the APAR SE10152.

3. Here is complete message information as found in joblog with
LOG(4 0 *SECLVL) LOGCL(*YES)

CPF3CDB Escape 40 04/15/15 15:45:09.234720
QUSRGFA2 QSYS *STMT QCADRV2 QSYS 019E
From module . . . . . . . . : QUSRGFCM
From procedure . . . . . . : Send_message
Statement . . . . . . . . . : 778
Message . . . . : Exit point QIBM_QCA_CHG_COMMAND with format
CHGC0100 does not exist.
Cause . . . . . : The exit point specified does not exist.
Recovery . . . : Do one of the following and try the request again:
-- Correct the spelling of the exit point or format name.
-- Ensure the exit point requested exists.

Symptom: msgCPF3CDB T/QCADRV2 x/019E
F/QUSRGFA2 FM/QUSRGFCM FP/Send_message stmt/778
EXITPNT(QIBM_QCA_CHG_COMMAND) FORMAT(CHGC0100)

CPI0001 Information 20 04/15/15 15:45:09.237496
QCADRV2 QSYS 02CC QUIMNDRV QSYS 055F
Message . . : Exit program not called. Reason code 2.
Cause . . . : An exit program for exit point QIBM_QCA_CHG_COMMAND
for command OURLIB/DDINSTALL was not called. Command processing will
continue without calling the exit program. Possible reason codes are:
<<1 snipped>>
2 - The exit program information could not be retrieved from the
registration facility repository. See the previous messages in the
joblog for more information. Correct the condition and try your
request again.
<<3 snipped>>

Symptom: msgCPI0001 RC2 F/QCADRV2 x/02CC T/QUIMNDRV x/055F

<<SNIP above two messages repeated, except this time per:
"Exit point QIBM_QCA_RTV_COMMAND with format *ALL">>

Symptoms same as above, except adding also:
EXITPNT(QIBM_QCA_RTV_COMMAND) FORMAT(*ALL)

4. I will run WRKCMD CMD(*ALLUSR/*ALL) and see if I can find a
command to test with to see if it also generates these errors

Probably moot at this stage, yet I would remain curious why the effect seemed limited. I can fathom the errors are either suppressed or otherwise somehow that system-supplied command might operate differently [without errors logged], but I would [as the reviewer of the failing scenario] want to confirm that the issue was for all command objects that were not provided by IBM, to ameliorate my concern that only the commands that I had provided would be impacted [despite the underlying issue with the registry as the conspicuous origin].

Thanks for the rest of your suggestions I will continue researching
this

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.

Note: I doubt a scratch-restore of the object is or even could be deemed necessary, because a prior DLTEXITRG request or the near-equivalent effect would be required. Yet per no command of that name existing, and the rename object API being the obvious but still problematic alternative per leaving the since-defunct object, such an action is unreasonable so improbable as a requirement; nor even desirable, as the effect of scratch-restore scenario of the object requires authority recovery for the object, whereas a slip-restore scenario of the object requires no additional action.