GeeZ! I can hardly understand everything you wrote but I caught the
essential I think.
I'll read it more carefully next tiem I face the problem.
Thanks very much!
Pascal Bellerose
pascal_bellerose@xxxxxxxxxxxx
Cascades Canada inc.
Analyst-Programmer-Helpdesk
Telephone: 819-363-6114 (2114)
Fax: 819-363-6155 (6155)
Do you really need to print this e-mail? Change your environmentality!
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
midrange.com
