Re: How to CRTSRCPF with more than 3 fields

On 18-May-2014 08:35 -0500, Steve Richter wrote:

Any way a source physical file can be created with more than 3
fields?

Yes, but only by using Data Definition Specifications (DDS) and the Create Physical File (CRTPF) instead of the Create Source Physical File (CRTSRCPF) command. The PF-SRC must have at least three fields defined in the DDS. The first must be defined as 6S02, the second must be defined as 6S00, and the third must be a character field. Extra columns must be either character or zoned decimal. Only the first field can be keyed.

I am thinking it would be useful to store the name of the user who
changed a source line. Also mark deleted source lines with a delete
flag.

The typical editor operates much like most stream editors, whereby the entire /file/ is rewritten. Conceptually there will never be any /changed/ or /deleted/ records [because each /file/ is a newly written copy]; for data members, that is to suggest all records of the source are rewritten to the member as active rows, such that the editor has discarded any deleted records before the rewrite. The Source Entry Utility tracks only line numbers (SRCSEQ) and optionally tracks source record change /date/ (SRCDAT) [beyond actual changes to the /source/], so tracking other actions requires a different editor or external means.

To get the extended source file to work with SEU you would create a
logical file over the source file with the additional fields that
only selects the 3 fields.

The Start Source Entry Utility (STRSEU) can operate without any difficulties against the physical file with the extra fields. That feature merely carries in the data as effectively un-described character data tacked onto the end of the Source Data (SRCDTA) [or by whatever name is the third field]. The restriction to either character or zoned data enables that possibility; at least for positive zoned numeric values which are the EBCDIC decimal digits 0-9.

Unless enhanced, the Work With Members using PDM (WRKMBRPDM) does not allow a member list for an LF, so the list access via STRSEU would probably be required if using SEU was desirable.

Having one SRC-LF per SRC-PF and one LFM per PFM probably is not ideal. Deleting the member leaves the physical data [and member], and deleting the PFM before the LFM is a potential issue if access to the PF is not prevented.

Eliminating the view of the extra columns would be preferable. For some source types, the data extended so far out to the right is just ignored by some /compilers/ so the data conceivably could be maintained by the programmer; probably less ideal than the overhead of the Logical File Members.

I recalled some difficulty using SEU on the LF-SRC, so I just tried a test on v5r3. I believe it is a side effect of requesting clear-on-open, that the old data is never cleared [i.e. rather than Clear Physical File Member (CLRPFM) being performed against the underlying physical member, the SEU asks the database to clear the LFM but there is no support], and so the old member data remains from prior to the edit request. The effect is visible with Edit File (EDTF) utility, per msg CPF4002 "Open of member &1 changed to CLEAR(NO)." logged as a diagnostic because the file is a LF instead of a PF.

And it omits the records with "deleted record" set to "Y".

That seems possible, but again, the editor used would have to be a row editor rather than operating as a conceptual /file/ [member] editor. The bigger issue however, is that the /source/ designation is restricted to a DDS-created DataBase File (DBF) and Select\Omit can only operate on columns included in the LF Record Format.

Then maybe use a trigger program to set the "last change user name"
field in the extended SRCPF record.

Again, possible [with a row editor], but again the typical editor does not allow that because every row will be a new row, inserted each time the /file/ is saved.

Which I guess does not work because SEU clears the source member and
replaces its contents when you exit SEU.

Correct. Neither of the aforementioned row-level tracking, user-as-changer nor as-deleted-record, could be tracked automatically by SEU. The programmer would have to make those updates to the data when editing the physical copy; i.e. they could set on the /deleted/ indicator on any rows instead of actually deleting the row, and they could store their user-id on the line [each aligned appropriately]. A trigger would have a very challenging task to effect those, even if working comparatively from a pre-edited copy of the physical source member; perhaps less challenging, knowing that the old data remains for comparison when editing was performed via the LFM.

I see I cannot use CPYSRCPF when the from file is a CRTPF created
file with 3 fields named SRCSEQ, SRCDAT and SRCDTA. So I assume
anything with a logical file would not work either.

The command is Copy Source File (CPYSRCF) [not limited to Physical File], and is restricted to a Data Base Source File as the From File (FROMFILE) [i.e. a DBF defined with FILETYPE(*SRC), irrespective of Physical or Logical]. But IIRC the feature only copies data across the required\minimal fields and all data beyond the first two is treated as one long un-described character data string; i.e. similar to the Format Option FMTOPT(*CVTSRC) on the Copy File (CPYF) request, but where the From File has even more restrictive data types [of Char and Zoned].

For Create Physical File (CRTPF) to create a "Source Physical File", the File Type (FILETYPE) parameter must have specified the special value *SRC instead of the default of FILETYPE(*DATA).

A LF-SRC can be created over a PF-DTA which removes some of the restrictions on the source physical file. The LF-SRC would of course, still have the source-file restrictions enforced.