× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 16-Apr-2015 09:43 -0500, John Allen wrote:

<<SNIP>>a potential new customer that installed our software onto
their system without any issues (that we know of)

1. RSTLIB OURLIB
2. OURLIB/DDINSTALL

Here is the issue:

The release-level may be pertinent; cumulative-level and TR-level may be pertinent or applicable as well, if nothing else, to rule-out any recommended PTFs that would be known already to be applied.


EVERY single command (starting with the first one DDINSTALL) in our
software that is executed generates an Exit program error.


So the first invocation of DDINSTALL is presumed to have performed without any errors.? But since, executing OURLIB/DDINSTALL or executing any of the *CMD listed with WRKCMD OURLIB/*ALL exhibit the following errors?:


Example:

The next message included, offered the message identifier, type, sev, date\time, from&to programs... for the best possible review by readers, so too should have this one:

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.

CPI0001 Information 20 04/15/15 15:45:09.237496
QCADRV2 QSYS 02CC QUIMNDRV QSYS 055F
Message . . . . : Exit program not called. Reason code 2.

In symptom kwd form:
msgCPI0001 rc2 f/QCADRV2 x/02CC t/QUIMNDRV x/055F

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: <<SNIP>>
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.

They also get:

Exit point QIBM_QCA_RTV_COMMAND with format *ALL does not exist.

Again, both the message identifier and the context were not included. Best to help the readers to assist; providing the


These errors occur on every single one of our commands, the IBM
commands execute without this error.

Perhaps learning if any other user-created commands found on the system [WRKCMD *ALLUSR/*ALL to possibly locate one\some] are affected similarly could be telling.?


Of course this company has no IT department and they have nobody on
staff that knows anything about their system.

Ask for the full joblog created with LOG(4 0 *SECLVL) for a job that initiates a command request [e.g. OURLIB/OURCMD] that is known to exhibit the errors. The complete joblog will hold some worthwhile but currently missing information; i.e. release level and messaging with context.


P.S. They do not have IBM support either (Surprise!)

With sufficient details and likely similar past discussion or commentary [to be found on the web], the solution is probably available without their direct assistance.


Does anyone have any idea what could cause this?

The object(s) that is the registry for exit-points [to name exit-programs] is apparently either missing or is corrupted; i.e. the object(s) providing the data output with the Work With Registration Information (WRKREGINF) is in-error. IIRC the effective database of registration information is implemented as object(s) in the quasi-system\user library QUSRSYS. Searching the midrange archive for the message identifiers [separately] from the first and last message [each for which the msgid was omitted].


Or where do I look for the possible cause?


Searching the web for web pages listing matching symptoms is a good start. A quick search on the two tokens "wrkreginf" "qusrsys" turned up, for example, the answer to what I could not recall was the implementation-object for the registry: "Registry is stored in the object QUSEXRGOBJ in library QUSRSYS."


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.