|
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). Regards, Jim Langston Date: Thu, 11 Jan 2001 11:36:59 -0500 From: "Shaw, David" <dshaw@spartan.com> Subject: RE: Can a PF have >1 record format? Jim, What's wrong with the classic approach of a separate physical for each record format, a multi-format (NOT join) logical to replace the original physical, and a record format selector program to accommodate writes to the logical which don't specify a record format? This capability has been around since CPF Release 1.0 and was put there specifically to make migrating S/3 apps to the S/38 easier, back when the S/38 was the "official" upgrade path for S/3 users. Dave Shaw Spartan International, Inc. Spartanburg, SC To subscribe to the MAPICS-L mailing list send email to MAPICS-L-SUB@midrange.com or go to www.midrange.com and follow the instructions. +--- | 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: david@midrange.com +---
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.