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



A physical file can only have one record format.  A record format is a
_name_ that the system uses for various purposes.  The record format name
identifies the specific arrangement of fields within the file.  

The confusion here is between "program described" and "externally described"
files, and how the programmer is perceiving the data, not how the record
format name is defined to OS/400.

For externally described files using DDS, I think that everyone agrees that
the DDS compiler allows only one record format name per physical file.  For
program described files created with CRTPF ... RCDLEN() the record format
name is the same as the file name.  DSPFD will readily confirm this.

Any physical file can contain any arbitrary arrangement of data, whether the
file is externally described or not - e.g. cpyf custmas prodmas mbropt(*add)
fmtopt(*nochk).  This would result in say, 100 product records followed by
500 customer records.  To the programmer, there are two different "record
formats" in the file, but the system knows only the product master record
format name as shown by DSPFD.

Any RPG program that "program describes" the data can arbitrarily assign
whatever fields to whatever columns.  This means that the program can
interpret the data as being either customer data or product data based on
some "marker" in the record.  This is how most S/36 style programs work.  In
the above example, the programmer could describe separate input
specifications to describe the different "formats," whether the product
master file is externally described or not.  This is how the S/36 folks
"move up" to the native database.  They externally describe their files so
that new programs can use external definitions, but the existing programs
run "as-is" because the record layout they describe in the I specifications
matches the external definition of the record in the DDS.  Even though the
_programs_ know about these different "formats", the _system_ does not.
There is and can be only one record format name for the PF.

The original question was "What does the CPYF RCDFMT parameter do  for
physical files?"  The simple answer is: nothing at all.  The help title
specifically refers to logical files, and while the help text refers to
physical files, going the "extra mile" to type in the record format name
doesn't get you any extra functionality because there is only one record
format name in the PF.  The default, *ONLY is perfect for this parameter.
One can only guess that Rochester put in that text for completeness.  Since
there _is_ a record format name in the PF, they added text to tell us that
we could waste our time and type it in if we feel so inclined.  My guess
only.

If you have a file like the above example (customer and product data in one
PF) and want to use CPYF to discriminate between the "record types" you'll
have to use INCREL or INCCHAR to puck out the distinguishing characteristics
of the different records.

This is not dependent upon release level.

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| 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.