Re: CHGPF - Cannot drop fields

On 29-May-2015 19:46 -0500, CRPence wrote:

On 28-May-2015 10:57 -0500, Buck Calabro wrote:

IBM i insists on issuing a message to warn you if your CHGPF is
about to drop a column - but only if issued interactively. Issue a
CHGPF in a batch job and IBM i behaves differently - IBM i does not
issue CPA32B2 at all in batch. Instead, it issues a CPD32CC *DIAG,
CPD32CE *DIAG (which falsely claims an inquiry message was replied
to!), and a CPF7304 *ESCAPE which terminates the CHGPF. The upshot
of that is that not even changing the reply list will help!

In a last ditch effort to try a workaround, I did a CHGJOB
INQMSGRPY(*RQD) and tried it. No dice. IBM i says 'Hey, you're in
batch so you get auto-killed'.

This is a situation with IBM i itself, not RDi. It'll probably
take a DCR or a COMMON requirement to change CHGPF to allow a
batch process to issue CPA32B2.

Hmm. Odd. I did not recall that behavior. I just tested on v5r3 and
saw exactly that. I thought the effect had always been the inquiry
msg CPA32B2, and that an auto-reply [with the message default] was
the effect for batch with Inquiry Message Reply Handling (INQMSGRPY)
of required (*RQD); and that the System Reply List (*SYSRPYL) option
was also available in batch. Given the clearly incorrect implication
of msg CPD32CE, per the conspicuous contradiction of the claim of the
prior inquiry that is not visible and only the msg CPD32CC being
logged prior, [if it were me affected, then] I would choose to report
the issue as defect.

I can not use trace nor the reply list entry feature, plus I have only v5r3, so I can only speculate; I really do not recall any specifics of this or similar inquiry message coding in the DB feature of the OS.

The situation may be that the QDBCHGFI program, procedure VFYALTER codes an inquiry messaging processing that is not a common System Program Interface (SPI) supplied by the Message Handling (MH) component whereby an inquiry is sent to *EXT for the interactive job, but redirected to *SYSOPR (QSYSOPR) message queue for jobs that do not have the 5250 workstation at which to provide a reply. Effectively that would be an OS interface to the Send User Message (SNDUSRMSG), with the asterisk as special\single value for the To Message Queue (TOMSGQ) parameter specification, for which the meaning is "In an interactive job, the message is to be sent to the external message queue (*EXT). In a batch job, the message is to be sent to the system operator (message queue QSYSOPR in library QSYS)."

Possibly the issue is that the effective specification by VFYALTER of TOPGMQ(*EXT) via whatever is the chosen MH interface to send the inquiry does not log the Sender Copy of the inquiry nor the Reply despite the effect is legitimately that the /default reply/ was sent by the MH due to no WS available in a batch job. Or the VFYALTER is removing the message(s), and the removals effect the loss of both the Sender Copy and the Reply as well as the Inquiry message from the joblog.

Whatever...

I do recall there was some /strange/ System Reply List Entry (SYSRPYLE) added long ago as part of the default system-supplied for CPA32B2; odd, because the comparison data made no sense, CMPDTA('iSeries Navigator'). I believe the MH feature must actually have a special-case for that specific message for work running within the iNav interface; i.e. as a server job for that interface. Perhaps the same effect can be extended to an RDi server job [if someone were to pursue]? That might actually be easier than getting DB to _change_ the inquiry processing to act in the more conventional manner [implicitly; either via alternate specifications on the current SNDPgmMSG-like invocation, or changing to use a different SNDUSRMSG-like interface] whereby the inquiry sent to *EXT is implicitly redirected to *SYSOPR for /batch/ jobs. I would have expected however, that anyone making the change to the MH to effect such a special-case would have recognized the /flaw/ in the DB code and just said... "Code this instead of that to be consistent with other code whereby the inquiry redirects to *SYSOPR in non-interactive."