Re: WRKDBF & V5R4

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

> 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