About Program Described input files

695 pts.
Tags:
I-Spec
Record Identification Code
RPG
RPG ILE
RPG/400
hi all, Can anyone explain me what is meant by Program described input files and what is the use of this files compared to Externally Described files and please give one complete example program of using Program described files with I SPECS and explain me about Record identification codes

Answer Wiki

Thanks. We'll let you know when a new response is added.

Program described files are used rather infrequently.
But when a fixed spacing flat file is created for reason then it can be useful.
The additional I spec stuff ties into RPG II automatic cycle processing — not my bag, and not used much in new coding. The sequencd on the I spec of NS stands for no sequence, again an RPG II field.

<pre>
Fmyfile if f 132 disk

Imyfile ns
I 1 10 Field1
I 11 20 Field2
I 21 132 Field3

C read myfile
C dow not(%eof(myfile))
C if Field1 – ‘Hello’
C call ‘PGM2′
C parm Field1
C parm Field2
C parm Field3
C endif
C read myfile
C enddo
C eval *inlr = *on
C return</pre>

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Pcatlin
    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
    200 pointsBadges:
    report
  • Geekprime
    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.
    275 pointsBadges:
    report
  • astradyne
    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.
    370 pointsBadges:
    report
  • Vicki
    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.
    10 pointsBadges:
    report
  • TomLiotta
    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.
    125,585 pointsBadges:
    report
  • Gg1
    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.
    45 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following