If you look at the I spec… there are a couple of other things you can do:

IMYFILE NS 01 1 CH 2 CE 3 CL
I 1 10 FIELD1
I 11 20 FIELD2
I 21 132 FIELD3
I NS 02 1 CB 2 CY 3 CE
I 1 3 RCDID
I 4 15 ISODTE
I 16 30 NAME
I 31 132 FILLER

In this example there are 2 distinct formats of data in “myfile”. The first starts with “HEL” (HELLO) the 2nd starts with BYE… In the above that’s designated with the 1 CH 2 CE 3 CL

In the code you would differentiate them by testing *IN01 for the HELLO record and *IN02 for the BYE record

As mentioned above the NS can be replaced with a couple of different things, but you really should read the RPG manual for more information there… Merge files and Sequence processing are involved topics and beyond a simple answer or example

even with flat files I use them externally, if I need to separate out fields I do it in the D specs. I avoid program defined files whenever possible… left hand indicators too.

I have to agree with GeekPrime, even if the file is a flat file you should still be able to define it as an Externally described file in the F-specs (it does exist, right?) and then use a data structure in the D-specs for the layout. I-specs are only really there these days (in RPGLE members) for backwards compatability.

If you know RPG-IV (i.e. RPGLE member type) then use it. If you only know RPG/400 then learn RPG-IV and spend some time learning about ILE concepts too.

Program (internally) described files are useful when you have a flat file that contains multiple record types. Back in the days before relational databases, it was a way to have different types of data readily accessible to the program. Whereas using file keys to find related data in another file is a snap, back then you had to use matching record processing, which was extremely painful. So, for example, a file would have name and address info on one record, and bank account numbers on the next. You would use record identifying codes to distinguish one record type from another.

There are 3 record types defined here. The first has “M” in byte 149 and “N” in 150. the second “M” and “D” and the third “S” and “P”. Your code would identify the type by testing the values in those bytes. You could also identify the different types using record identifying indicators (the 03, 04, and 05 below). When the program reads a record with “MN” in 149-50, it will set on *IN03. If the record has “SP” it will set on *IN05, etc.

0020.00 F*****************************************************************
0021.00 FMFILE2 IP F 150 DISK
0022.00 FEXTPPRTFO E DISK
0023.00 E*****************************************************************
0024.00 I*
0025.00 I* RECORD TYPE 1 THROUGH 11 IN MFAEXTP4
0026.00 IMFAEXTP4011 01
0027.00 I 1 148 DATA
0028.00 I 149 150 RECID
0029.00 I*
0030.00 I* RECORD TYPE 03 – MODEL NUMBER
0031.00 I NS 03 149 CM 150 CN
0032.00 I 1 150 MDLFMX
0033.00 I 3 8 MMODEL
0034.00 I*
0036.00 I* RECORD TYPE 04 – MODEL DESCRIPTION
0036.01 I NS 04 149 CM 150 CD
0037.00 I 1 150 MDLFMT
0038.00 I 9 33 MDESC1
0039.00 I 34 58 MDESC2
0040.00 I 59 83 MDESC3
0044.00 I*
0045.00 I* RECORD TYPE 05 – SALESPACKAGE
0045.01 I NS 05 149 CS 150 CP
0047.00 I 1 150 SPVFMT
0048.00 I 3 27 SLSP1X
0049.00 I 28 52 SLSP2X
0050.00 I 53 77 SLSP3X
0051.00 I 78 102 SLSP4X
0106.00 I*****************************************************************
0109.00 C*
0110.00 C *IN03 IFEQ ’1′
0111.00 C MOVELDATA ZZLFMX
0112.00 C WRITEEXTFILE
0113.00 C ENDIF
0114.00 C *IN04 IFEQ ’1′
0115.00 C MOVELDATA ZZLFMT
0116.00 C WRITEEXTFILE
0117.00 C ENDIF
0118.00 C *IN05 IFEQ ’1′
0119.00 C MOVELDATA ZZVFMT
0120.00 C WRITEEXTFILE
0121.00 C ENDIF
****************** End of data ****************************************

This program happens to use the internally described file as a primary file, but full procedural files can be internally described, too.

I can’t think of a compelling reason to use an internally described file today, other than to avoid taking the input specs out programs they’re already in.

If you RUNQRY *N QUSRSYS/QATOCTCPIP on almost any AS/400 (or later), you’ll see what the system’s basic TCP/IP configuration file contains. It has two externally-described fields for “KEYWORD” and “ASSOCIATED DATA”. As such, it is an externally-described file.

However, you will see that the “ASSOCIATED DATA” has different structures that change for different KEYWORDs. There is no easy way to define variable data structures via DDS, especially when there are more than a couple.

But programs can describe thousands of data structures.

That file is provided as an externally-described file, so almost every (AS/400) programmer would write a program to use the external description. The structures would then be BASED over the “ASSOCIATED DATA” field and accessed depending on the value of KEYWORD. On a different platform, a COBOL (for example) programmer wouldn’t have the advantage of externally-described file “objects” being integrated with the compiler. Instead, they would code a program-described file. (They almost certainly would have a /COPY book that provided related capabilities — a method of consistency between developers.)

A program-described file is simply one that ignores any field definitions from a *FILE object. The definitions are coded directly in the program.

FYI, the “NS” on the I-spec does not really stand for “No Sequence”. The valid entries for that field are either a 2-digit number of 2 characters of which the first is a letter (A-Z).
In the old days of card input, the various record types were held in sequence in the box of cards. Just to check the you did not drop the box and ruin the sequence, the program would check the sequence of record types, the first would be 01, the second 02, the third 03, etc. For instance, the customer record would be type 01, the date last updated type 02, and the transactions would be type 03. You could not feed the program types 03 before having provided an 02 for that customer.
Any other value, as described above, indicate that the program need not check the sequence. It was just common practice to put NS, not mandatory.

Internally described files are coming back. What a number of you write about creating a DDS file and defining the fields in a DS is almost identical to describing the file directly in the I-specs. The only differenceis when defining the file directly, you have to give the “from” and “to” values, whereas in the DS the “to” value is sufficient.
But if you define things properly you can to some fancy things with the “from”-”to” method. Firstly the fields need not be defined in order. Secondly you need only define the fields that are relevant to the program. You can redefine the fields in any number of ways, etc, etc.
For a small consideration I am prepared to give you a small refresher course! Seriously, ant questions, please ask. Anyone writing RPG for mor than about 25 years will be able to answer you.

What a number of you write about creating a DDS file and defining the fields in a DS is almost identical to describing the file directly in the I-specs.

This is a very limited view of the difference between a DDS or SQL DML externally described file and a program described file using I-specs. The two a very different objects with very different characteristics. They are very definitely not “almost identical”. They are hardly recognizable at all as even being related.

An externally described file provides the definitions of every byte in the records to programs. Program-described files only present the length of the record with no internal structure at all.

An externally described file will automatically have the same definition in every program that uses them, as well as every utility that uses them and every remote system that queries or updates them. Program described files are prone to numerous errors because every single program must have the correct definition in the program code, and external utilities have no knowledge of the internal record structure.

Externally described files carry the data definitions with the file objects themselves. This allows DB2 to provide data validation. A SQL table with a DATE field cannot have an invalid date value put in it. Program described files have no rules except record length. A portion of the record that is supposed to hold a date can just as easily hold a street name without raising a signal that anything is wrong. Such files have historically carried errors for years and sometimes decades before errors are discovered.

To dismiss externally described data files is as misunderstanding of their purpose and capabilities as is choosing to use program described display files rather than externally described (even though DSPFs are commonly used only in single programs.)

In any case, the question at the top ought to be dismissed. The answer ought to be “Ignore program described files. Don’t use them. If you find one, create an external definition for it and use it instead.”

Tom