Charles (or others!)

Here is what I have so far - am I going in the right direction? Or totally off base?

I left out the Aldon DCL stuff so as not to mess with any copyright issues :)

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.

Everyone is telling me (in general) this cant be done, both in my company, Aldon, and on the BBS. What am I missing?

Thanks

/*----------------------------------------------------------------------------*/
/* */
/* Aldon */
/* Convert file: field name chgs + new fields */
/* */
/*----------------------------------------------------------------------------*/

DCL &ddsmbr TYPE(*CHAR) LEN(10)
/* temp DDS member with field name change (but no NEW fields added) */
DCL &ddsmbrT TYPE(*CHAR) LEN(10)

CHGVAR VAR(&RTN_STS) VALUE('0')

CHGJOB LOGCLPGM(*YES)

CHGVAR &ddsmbr &objname

CHGVAR &ddsmbrT (&ddsmbr *tcat 'T')

/* create version of PROD in qtemp with mostly PROD fields */
/* except with fields renamed to new names (no new fields added yet) */
dltf FILE(qtemp/&objname)
CRTPF FILE(QTEMP/&objname) SRCFILE(TPGMLIB/QDDSSRC) +
SRCMBR(&ddsmbrT) SIZE(*NOMAX)
/* ...TMP dds member doesnt exist? (no field name chgs), then use PROD DDS */
MONMSG MSGID(CPF7302) EXEC(CRTPF +
FILE(QTEMP/&objname) +
SRCFILE(&SAVLIB/QDDSSRC) SRCMBR(&ddsmbr) +
SIZE(*NOMAX))

/* 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)

/* 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




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, April 05, 2012 9:56 AM
To: Midrange Systems Technical Discussion
Subject: Re: we are using Aldon Lifecycle Manager for System i - how to create a file conversion pgm

How do you plan to create the QTEMP version of the file?

There's certainly no built in support of such an intermediate version
of a file object in Aldon. If your production and development systems
are separate, working outside Aldon may be difficult.

The idea that you can do this in a reusable fashion is not valid,
given that you're renaming & adding (and maybe removing) fields. Thus
every case is going to be unique to the file your working with since
the mapping will be unique.

If you plan to do a lot of this, I suggest building a program that
will display the fields from both versions and generate the unique
conversion program for you.

I've been using Aldon for 16ys...I think I've used a custom conversion
program once....


HTH,
Charles

On Thu, Apr 5, 2012 at 10:32 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:
Why is a very simple CL with CPYF a poor choice?  It will do the job WITHOUT naming fields, and could be used on ANY file conversion - as opposed to SQL, which would need specific fields named and is NOT reusable for other files??

Step1:
To copy data with ONLY field name changes (no new fields, no field length changes:
CPYF *nochk from SOURCELIB to QTEMP version of file with field name changes


Step2:
CPYF *MAP *DROP from QTEMP to TARGETLIB version of file with field name changes AND new fields inserted.


Please explain why this simple, reusable method would be a poor choice??





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, April 05, 2012 8:37 AM
To: Midrange Systems Technical Discussion
Subject: Re: we are using Aldon Lifecycle Manager for System i - how to create a file conversion pgm

CL is a poor choice for your needs...

Looking at the example (ACMSUSER/USEREXIT(DATACNV)

DCL &OBJNAME             *CHAR 10
DCL &OBJLIB              *CHAR 10
DCL &SAVNAME             *CHAR 10
DCL &SAVLIB              *CHAR 10

&OBJLIB/&OBJNAME is the new version of your file without data.
&SAVLIB/&SAVNAME is the old version of your file with your data.

You can use the INSERT part of chuck's SQL example, but you'll have to
create the statement dynamically and run it using PREPARE and EXECUTE
or just EXECUTE IMMEDIATE.

wSQLstmt = 'insert into ' + %trim(objlib) + '/' + %trim(objname)
                  + '(fld1, newfld2, fld5)
                  + ' select fld1, fld2, fld3 '
                  + ' from  ' + %trim(savlib) + '/' + %trim(savname)


HTH,
Charles

On Wed, Apr 4, 2012 at 5:51 PM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:
Im trying to write a CL routine to promote a file with fields renamed AND several fields added into the middle of the record format.


I am looking for an example data conversion program.  If you have one you could share to get me started, that would be great!


1)      CPYF *nochk to copy the data
2)      CPYF *map to move the data into the proper fields


Do I use *LIBL for the "from" lib?

Do I use &OBJLIB for the "target" lib?


They provide a sample CL with parms only, not much regarding what they contain.

Thanks



______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs SkyScan
service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].