Re: EXTFILE not working if filename is DIBFIL

Joep Beckeringh wrote:

For the record:

In an earlier thread (<http://archive.midrange.com/rpg400-l/200812/msg00022.html>) I
reported that EXTFILE did not work on a file with a VARLEN field.
After some experimenting I found out that the VARLEN has nothing
to do with it. It turns out that it is the name of the file that
causes the problem!

For some mysterious reason (maybe Barbara can shed some light)
the name 'DIBFIL' magically stops EXTFILE from working (OVRDBF
has no problem). If I rename the file to anything else,
everything is hunky dory again.

Spooky.

It seems possible that an incorrect conclusion for the claim that "there are no overrides in effect" during the open may be the most logical explanation for the described outcome; i.e. there may be an OVRDBF DIBFIL DIBFIL ACTGRP() OVRSCOPE() that was activated at some point in processing. Was DSPOVR issued within the job performing the open, while stopped in debug just before the OPEN? Was WRKJOB OPTION(*FILOVR) done against the job performing the open, while stopped in debug just before the OPEN? I prefer the former to the latter when possible [may be difficult; not so much for *CALLER], because I think the WRKJOB overstates its capability in showing overrides "at any active call level for the job"; i.e. I would expect "for all active call levels for the job" but I am not sure what I really would get, and I recall having difficulties to see what I expected.

I do not recall exactly what the OPEN details are for trace data in the TRCJOB output, but I seem to recall it shows an original name and the resolved name [including member] that is opened. The trace data may have something of value to review. The trace record is produced by QDMCOPEN. A review of a trace record for the command analyzer would show any incidents of OVRxxxF. The auditing of the override command(s) could show the command string logged and then review for any case of FILE(DIBFIL) or TOFILE(xxx/DIBFIL).

Regards, Chuck