Are you saying your physicals aren't keyed, that the details are associated with the header purely by location within the file? Wow, what a screwy design that must be! You have my respect for coping with that, if that's the case. I've never had the misfortune to see such a thing. If that's the case, then multi-format logicals wouldn't work, since they do require keys for proper retrievals of their contents. -----Original Message----- From: Jim Langston [mailto:firstname.lastname@example.org] The main thing wrong with this approach, imo, is when we receive files from our customers with dual formats. We currently receive 2 such transmissions daily. One of the files has to way to specify which header record goes with which detail records. The easiest way to deal with this is the internally described external file descriptions. That way I know which header goes with which detail records. All the detail records go with the previous header. Otherwise I would have to write a program to write this file to two physicals and add a key type field to specify which headers go with which records, and, of course, in that program I would still be in the same boat of having to deal with two file formats in one physical file, which would also add an additional layer of complication to the process. The other file, sent to us by another company, does have a unique identifier to identify with headers go with which records, but this file winds up in the same post-processing files as the first customer's file does, and it makes it much more simpler to maintain if both of the import programs act and do almost the same thing. The second thing wrong with this approach is that I couldn't get it to work seamlessly with our existing S36 programs without having to modify the programs. I worked on this approach for a while with our Accounts Receivable file which has dual formats. There was some issue, which I don't quite recall what it is now since it's been 3+ years since I tried this, with having to modify the S36 RPG programs in some way to receive the records in the correct order. I have learned quite a bit since then and could probably figure out how to work around this now, but the current method works perfectly with both S36 and native RPG programs, and I see no real advantage to changing it at this time, since this system is dying a natural death now anyway (we are using another AS/400's system and programs for accounting now, and this current one will just be using for archival purposes of legacy data). +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.