|
Mark, It looks like you're two data structures are identical in layout, never mind the field names. If they are, why not just copy one DS to the other? Not sure what you're getting at... if you really want to "unpack" a value with its positions determined at runtime, you can use something like the NumToZoned or NumToNum procedures in my RPG ToolKit. That's whay they do, allow you to unpack a value given a location in an input buffer. There is no "MOVE CORRESPONDING" in RPG IV like we have in COBOL. So if the subfield locations of your data structures is different, you're SOL; even if you use QUALIFIED. Bob Cozzi Cozzi Consulting www.rpgiv.com -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Allen Sent: Friday, May 02, 2003 1:02 PM To: 'RPG programming on the AS400 / iSeries' Cc: buck.calabro@xxxxxxxxxxx Subject: RE: Flat file, same field, different positions AHHHH, the infamous raw toll file!!!!! -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro Sent: Friday, May 02, 2003 1:21 PM To: RPG programming on the AS400 / iSeries Subject: Flat file, same field, different positions I have an EDI-like flat file where I have standard data elements which occur in different places depending on the record type. The fields are all packed. The existing implementation simply maps them all into one set of I specs in RPG III, and has IGNDECERR(*YES) set. Iflatfile NS 02 22 C I OR 01 ... I P 31 31 0SEA500 I P 40 40 0SEA625 I P 46 46 0SEA364 I P 30 30 0SEAUSF ... There are dozens of fields on each record type. I'm doing maintenance and want to make this RPG IV so I can use reasonable names, etc. Unfortunately, I need to use FIXNBR(*ZONED *INPUTPACKED) in order for it to run as-is. This generates tens of thousands of messages in the job log as each 'invalid' number is 'fixed'. Understand that for a 500 record type, the program only references the 500 fields. I want something like: d struc0001 ds d sensType 3p 0 d sensID 7p 0 d roType 3p 0 d roID 7p 0 d struc0360 ds d sensType 3p 0 d sensID 7p 0 d roType 3p 0 d roID 7p 0 But that won't compile because the same field is in a different DS. I could use qualified, but as far as the calculations go, eval sensType=sensType0001 isn't much different from eval sensType=struc0001.sensType. I still have to copy all the fields by hand as it were. I have two goals: 1) I don't want to use FIXNBR; so I'm separating the fields into separate structures 2) I'd rather use one set of names to describe the same fields; not SEA500, SEA625, SEA364, but SEA. Since the input data is packed, I can't readily use the old standby I specs because I can't specify the hex codes needed to recognise the packed fields. I'm stuck, aren't I? It gets worse when having to support this back to V4R5. Just thought I'd post a tale of woe on a rainy Northeast US Friday. --buck _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.