On 18-May-2014 08:35 -0500, Steve Richter wrote:
Any way a source physical file can be created with more than 3
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
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
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
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.