RE: Can a PF have >1 record format? -- MIDRANGE-L

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:jimlangston@conexfreight.com]

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: david@midrange.com
+---