Re: CHGPF Ignore question

The message is sent as a warning about the implications irrespective of actual data loss or other data impacts on the file; i.e. even on an empty file. The inquiry message and the underlying CPD32CC "Change to field &3..." and CPD32CD also intend to inform of the potentially negative outcome directly to the requester who either might not have noticed they dropped a field or reduced a size or would be reminded that applications might experience data loss or other negative impacts due to the changes being applied which is applicable even when no data currently resides physically in the file being altered.

Might still be worth reviewing the DSPMSGD CPA32B2 to review the special reply values, to ensure 'i' does not map to 'C' and that the message attribute "Default Reply" is 'C'. If the lower case "i" were entered instead of the upper case "I", the "Special reply values" "Replacement to-value" would be used; e.g. SPCVAL(('c' 'C') ('i' 'C')) would be an obvious origin for a problem. Also consider that a buffered Enter [e.g. KBDBUF(*YES|*TYPEAHEAD)] may cause a default reply to be sent. A request to CHGMSGD CPA32B2 DFT(*NONE) can help prevent some problems [like a buffered Enter with no reply value being entered] if the code receiving the unexpected reply value [of *N] is [properly] coded to re-issue the inquiry; in v5r3 for an interactive job, the inquiry was reissued to the *SYSOPR.

If the failing scenario is "solid" as described, i.e. appears to be a defect in how the CHGPF SRCFILE(named) processes the "potential data loss" condition and occurs each time within the same context, then simply performing another request that mimics that original scenario should suffice to re-create the issue. If reproducible and not operating according to the design intent, then that re-create scenario can be submitted to IBM service to be reviewed, an APAR opened, and a PTF provided; thus preventing future recurrence for you and others. If instead the circumvention was deemed OK this time, then resorting to the circumvention may be required next time, for lack of corrective service being available, even if not so simple to implement the next time; e.g. with a large amount of data, instead of an empty file.

Regards, Chuck

On 03-Feb-2012 13:39 , Michael Naughton wrote:

Thanks, Chuck! It's too late for that this time -- I went ahead and
deleted and recreated the file, but I was just curious. It was an
empty file, so there wasn't actually any data that could have been
lost, and this has always worked for me in the past ....

CRPence wrote:

On 03-Feb-2012 12:24 , Michael Naughton wrote:

I just tried to use CHGPF on a file in a system I'm developing.
I want to remove a field and add a field. When I tried it, I got
the "Change of file MYFILE may cause data to be lost", which I
expected because of dropping the field. In the past, I've always
just replied "I" and the command has proceeded, but this time I
got another message telling me that doing this may cause data to
be lost and informing that the reason is that I'm dropping a
field. There doesn't seem to be any way to reply to this message,
and the command doesn't run.

The file was compiled from DDS, and we're on V7R1. Is this
something new, or is there some setting that got switched? I
googled around and searched the archives, but I didn't find
anything .....

Collect an unfiltered LOG(4 0 *SECLVL) spooled joblog after the
inquiries\messages, and a SysRqs-3 OPTION(*PRINT) [or WRKJOB
OUTPUT(*PRINT) taken of the CHGPF requester from another job] for
each time the inquiry [or whatever message type; unstated; and
presumably a CPA32B2] is given. That should be give a better
representation of what transpired, and very possibly also /why/
that outcome.

Other information like reply list entries, DSPMSGD of the
message(s) given, and WRKREGINF may also be of interest, if the
review of the DSPJOB and DSPJOBLOG information might /hint/ to look
further.