On 01-Aug-2014 10:52 -0500, Gary Thompson wrote:
Actually it was the OS recognizing the data did not support the
UNIQUE attribute I specified for the key.
What I now know is the OS is happy to create the requested file but,
due to data in the based-on file, does not create a file member.
The Create Logical File (CRTLF) request, in its attempt to perform
the implicit Add Logical File Member (ADDLFM) per the MBR(specified) on
the Create request, or for an explicit ADDLFM request, should have
*failed* with the escape msg CPF7306 "Member &1 not added to file &2 in
&3." in response to a prior error msg CPF3240 "Duplicate key values
exist for member &3." due to the UNIQUE file-level designation being
incompatible with the data over which the LFM was being added.
If that exception was ignored, well then that is termed a usage
problem; or a User Error :-) [though be sure to read the last paragraph
of my reply]
However if the OS Database [in conjunction with the DDS compiler] had
failed to diagnose that overall Create request as having failed with the
CPF7306 exception, then that would be a defect [except if the LF was
being created over a system file rather than a user file, for which the
condition may be diagnosed correctly instead, by a diagnostic message
identifying that the UNIQUE attribute had been ignored; e.g. CPD3237].
By design, the Member (MBR) parameter exists solely as a one-off
convenience, simply to allow for avoiding a two-step process to Add
Database Member [of just the first and only member of a newly created
file] after the Create Database File. The DDS compiler processes the
specifications in the source and the database processes the
specifications from the command [for the file attributes to be reflected
in each member if\when added]; having passed validation from both, the
database *FILE object can be created with success, as the first stage of
a potentially two-stage process. So *if* a member will be created with
the Create DB-File request [per MBR(named)] then the DDS compiler, after
completing creation of the Database file, implicitly will make the
separate ADDLFM request as a convenience for the user.
The "file created" condition is not backed-out if the additional work
to add the member had failed, because all of the real work of the DDS
compiler [and the OS Database] was completed to create the file; plus
that the create is deemed to be two distinct stages. If the implicit
additional activity [of adding the member] fails, then courtesy dictates
that the DD compiler feature should notify that the overall request
experienced a failure, but differently than CPF7302 "File &1 not created
in library &2." because conspicuously, the *FILE object remains after
that first stage of processing completes.
I see that the CPF7306 is not documented in the list of "Error
messages: *ESCAPE Messages" found in the following docs [which within
the astoundingly wonderful KC was unsearchable; I had to use a web
search to find that link]. I presume there remains a means to report
defects in the documentation there, like there was in the InfoCenter docs:
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/cl/crtlf.htm>
midrange.com
