Chuck,
Thanks for all the information thus far. I greatly appreciate it
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)
This is not my system and I would not want to do anything to bring it down
or to affect their applications.
John
-----Original Message-----
From: CRPence [mailto:crpbottle@xxxxxxxxx]
Sent: Thursday, April 16, 2015 7:41 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
midrange.com
