× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Can a PF have >1 record format?
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 11 Jan 2001 11:45:38 -0800
  • Organization: Pacer International

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 thread ...


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

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.