× 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.



Ok, I read carefully and understood all character of your answer.

But here's another case that you didn't mention and which I think
should be in the scope when looking into this problem:

The job could be set to INQMSGRPY(*DFT) which uses automatically the
default answer for the message.

I found out that one of our software is changing this setting.

Thanks for your help!


Pascal Bellerose
pascal_bellerose@xxxxxxxxxxxx
Cascades Canada inc.
Programmeur-analyste au support
Telephone: 819-363-6114 (2114)
Télécopie/Fax: 819-363-6155 (6155)

Tenez-vous vraiment à imprimer ce courriel?
Changez d'environnementalité!


Le 26 Septembre, 2007 à 16:09, CRPence <crp@xxxxxxxxxxxxxxxxxxxx>
a écrit :
Dropping a column effects the inquiry CPA32B2 being issued. For a
job to use an added reply list entry which has registered a reply value

to be sent [as displayed in WRKRPYLE and added by ADDRPYLE], the job
that receives the inquiry must be defined to use the Reply List as its

Inquiry Message Reply Handling [the INQMSGRPY() for a Job or *JOBD].

Thus in a job where a user encounters the message CPA32B2 due to
such
an ALTER request, if the job is setup to have Inquiry Handling = Use
Reply List [i.e. INQMSGRPY(*SYSRPYL)], then for a matching reply list
entry with optional data comparison, that entry will be used for the
defined reply to the inquiry. Or if a generic entry matches, its reply

will be used. If no reply list entry matches either due to no matching

message identifier, for no matching compare-data [CMPDTA()], or for no

matching generic message identifier, the job will default to Inquiry
Handling = Required [i.e. the same behavior as INQMSGRPY(*RQD)].

The original post suggests the job is known to have INQMSGRPY(*RQD),

yet alluding that the operation is canceled in an interactive STRSQL
If
the job is interactive then there is a display from which to respond,
so
*RQD enables awaiting a reply. Three considerations: 1> After a very

long time [days even?], the message will time out and take the
_default_
reply as defined in the message, irrespective of the RCVMSG WAIT(). 2>

If the user buffers an Enter, failing to provide an explicit response
replies with the _default_ reply for the message. 3> If the message is

deleted from the message queue, the _default_ reply for the message is

sent; this does not apply to the noted scenario, because the msgq is
*EXT, which is an inquiry sent to the display.

Since the message is sent to *EXT, if the request is not run at an
interactive display, the reply must come from either the _default_
reply
for the message, or from the system reply list. If the job runs with
Inquiry Handling = Reply List, then have a reply list entry will
suffice. For the default reply [from Enter, from *DFT, from timed out,

or from deleted message], the message itself must be changed to
override
the default value. Although the message in its original message
file(s)
can be changed to effect a desired response, that would be system-wide.

For a change that is specific to a job, using the following script:
crtmsgf qtemp/cpa32b2
mrgmsgf *libl/qcpfmsg qtemp/cpa32b2 select(cpa32b2)
ovrmsgf qcpfmsg qtemp/cpa32b2
chgmsgd cpa32b2 qtemp/cpa32b2 dft('I')
chgjob inqmsgrpy(*dft) /* optional where *rqd sees same */
dltovr qcpfmsg
chgjob inqmsgrpy( &savedval ) /* if changed before */
/* Note: Override to message files is such that the TOMSGF() is
searched first, and if the message is not found, then continue looking

where directed originally by the sender. Thus a one-off message
override need not be a copy of the entire *MSGF */

However that may all be effectively moot for the given scenario,
because the CPF5104 is not even used for diagnosing the default reply
for CPA32B2. Instead a canceled reply for that inquiry is diagnosed by

a message CPD32CE. So again, if CPF5104 is an issue, the origin needs

to be investigated. If it has something to do with security, one would

expect the details from the failure to manifest something about the
origins. The actual spooled joblog needs to be reviewed; just that a
CPF5104 occurs, is of too little value by itself, to give a reasonable

response to the question(s).

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.