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:

Return to Archive home page | Return to MIDRANGE.COM home page