×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 05-Apr-2012 08:47 , Stone, Joel wrote:
Here is what I have so far - am I going in the right direction? Or
totally off base?
<<SNIP>> Example of use: If file is CUSTFILE, then
orig DDS is &SAVLIB/QDDSRC-custfile (no changes);
temp DDS (with renamed fields for CPYF *nochk) is in
TPGMLIB/QDDSSRC-custfileT ("T" appended for temp),
and DDS with both change AND new fields is in
&OBJLIB/QDDSSRC-custfile (for CPYF *MAP *DROP).
I am hoping that this will work to promote any file with field name
changes AND new fields inserted into the middle of the record.
That is overly hopeful in my estimation. Limitations and caveats for
use of the FMTOPT(*NOCHK) feature of the CPYF utility will surely limit
the _general_ capability. That is, files with some specific\limited
Record Format definitions will be capable of being modified in that
manner, while others may have attributes for which caveats result in
data loss. Most notably [for DDS created files, I am not sure of what
else], the nullability or ALWNULL attribute can be maintained in the
RcdFmt in all versions of the file [old, temporary, and new], but the
loss of all null values is a side-effect for any data copy using the
FMTOPT(*NOCHK) feature.
Everyone is telling me (in general) this can't be done, both in my
company, Aldon, and on the BBS. What am I missing?
Can not be done, generically. Also can not be effected nicely, both
for the requirement to perform two passes\copies of the data, and having
to create an intermediate file. The SQL can effect the copy more
generally and generically [with input that describes the rename effects]
using dynamic DML, with no explicit intermediate copy. I am unclear
what is the significant difference between having to name the columns in
an intermediate DDS versus having named them on an SQL DML statement,
such that the desire seems so strong to avoid the SQL.
<<SNIP>>
/* ...TMP dds member doesnt exist? (no field name chgs), then use PROD DDS */
MONMSG MSGID(CPF7302) EXEC(CRTPF
<<SNIP>>
I would think that avoiding the FMTOPT(*NOCHK) would be advisable for
the above scenario, instead of accommodating the hard-coded references
to the library name QTEMP in the later CL command(s).? No reason to
make two copies in that scenario.
/* copy data to QTEMP file, renaming fields */
/* ALL fields including renamed fields MUST retain same position & length attr*/
/* (renamed fields MUST retain same position & length attributes) */
CPYF FROMFILE(&savlib/&objname) TOFILE(QTEMP/&objname) +
MBROPT(*REPLACE) FMTOPT(*NOCHK)
This copy, like the final copy from the temporary to the new file,
should use FROMRCD(1) TORCD(*END)
The changes in this phase really should be _nothing more than_ the
rename of the columns; i.e. ordinal position unchanged is implied, and
although non-attribute changes such as /text/ item [including editing]
changes could be done such as removing them all, there would be no
point. Attribute changes other than just /length/ may have impacts to
the /record buffer/ [i.e. the internal\storage for the field\column], so
those should be avoided [or well-understood as to the effects].
/* copy qtemp version back to NEW version with new fields added */
dltf &objlib/&objname
CRTPF FILE(&objlib/&objname) SRCMBR(&DDSMBR) +
SIZE(*NOMAX) SHARE(*YES)
CPYF FROMFILE(QTEMP/&objname) TOFILE(&objlib/&objname) +
MBROPT(*REPLACE) FROMRCD(1) FMTOPT(*MAP)
endpgm: ENDPGM
Interesting that the member SHARE attribute is explicitly specified
on that CRTPF, instead of being extracted from the old file.? Any other
customized member attributes are also being lost, because the CRTPF
defaults to MBR(*FILE) instead of specifying MBR(*NONE); admittedly,
that may be the intended effect.
Regards, Chuck
midrange.com
