Re: WRKDBF & V5R4

DMPOBJ is about the only way to see it unreformatted.

I infer 'it' meant to refer to data. The DMPOBJ does not provide access to the data of database files. The Display/Alter/Dump utility would need to be used instead.

And if you royally hose up QAQQINI you can't even do a DSPPFM because
of the reformatting checked for - regardless of whether or not you are using any of these fields that DSPPFM reformats.

A reference to the QAQQINI established for a job [that file name in the library identified by CHGQRYA QRYOPTLIB()] during a request to perform DSPPFM, is unnecessary for any reason. Such a reference is not required for the formatting, because the definitional attributes of the fields for the layout and presentation are part of the file object itself. When the open uses DATFMT(), that comes from the job, not a qaqqINI option. Such a reference being made, is effectively a code path that is likely not streamlined to eliminate unnecessary work.
However other non-query opens may still use the common/shared interface for extracting established query attributes, to obtain other information that is pertinent also to non-query open. For example the DEGREE() information, which applies to access paths, is not limited to only queries for its meaning. The value also determines how access path rebuild occurs in a job. Because the CHGQRYA DEGREE() in a job may have overridden the QQRYDEGREE, the database must redirect to the query interface to extract the resolved-to-job value.

The specific case for every database open on the system failing with CPF4128 due to the QAQQINI in QUSRSYS being broken, except those jobs with an alternate QRYOPTLIB() specified [APAR SE29718], apparently had its origin in yet another shared interface. In that case, the determination of whether transactional support has been established in the job is performed by the same function that maintains query options.

Regards, Chuck