Re: Can a PF have >1 record format?

I checked out some programs & could not find what I had said I remembered we 
had, so I could well be wrong about some things I had said.

Domenico Finucci had asked about RECORD format in DDS so I checked that also.

All of ours follow very similar format ... one or two lines associated with 
the R, then a bunch of lines for each of the fields in that record.

File name HCIF (Purchased Raw Maerials connected to which Customer End Items)
A* format name has to be 8 characters or less
A R IPHCIF
A* then I have chart of naming convention for the fields of the file 
& then the fields defined

File name VJTWU (External Object definition that only contains data when the 
programs running)
R VJTWUDS TEXT('Where Used Data Structure')
Is the ONLY line for RECORD format of an externally described data structure 
where I have one program passing an item of interest to a called program 
which populates the data structure that both programs share.
Each of the fields of this structure has 2 lines such as:
WUIT01 R 
COLHDG('Item #'' 'Whr-Used' '01/24')
REFFLD(IPROD)
WUCS01 R
COLHDG('Item'' 'Class '01/24')
REFFLD(IPROD)
Then this is repeated for all 24 elements of the 2 interlocking arrays

File name ECLL70 (Logical ECL by Warehouse/Customer/Item - Active) used for 
defining temporary members associated with reports different selections 
concurrently by different users
R IPE500CL 
TEXT('Order Line Items')
PFILE(ECL)
then I have the keys & selection

I hope this helps Domenico Finucci with what he was looking for

Some of our file naming is due to our ERP package, which I think is 
unneccessarily obtuse.  I do not see why format names cannot just be same 
name as their files.

Weird transmissions from customers is one of the reasons my employer 
abandoned EDI - we were spending too much time futzing with software to 
interpret their data ... EDI had certain standards ... different trading 
partners had different violations of of the EDI standards that they were 
allegedly using ... different employees at these companies had their own 
variants ... so our software got an EDI transmission ... searched through for 
a particular header type that we knew from experience they not violating the 
standards of, then get at which customer this is, so now the program knows 
which set of customer variants to the standard EDI rules are in this 
transmission, now search for the record type that specifies what part model 
line is involved & from that know which set of end user rules at that 
customer is in effect, until that person changes their mind again & not 
notify anyone.

In other words the deal with "this format has certain layout" "and "the codes 
for this field has certain significance" and "next N records will be that 
layout" was not something we could depend upon.

Processing the data was via analysis of each record based on analysis of 
prior records to determine what the format must be, then a humongous CASE 
statement (several pages of compile long) which took us to a subroutine in 
which the first step was to copy the entire incoming record into a data 
structure whose layout was unique to this record format scenario.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| 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
+---