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