Program Described File in RPGIV

pts.
Tags:
RPG
RPGLE
Can any one send me an Example, How a Program Described File is used in RPGIV?

Answer Wiki

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

Hi

The trick is to code the file layout using the I-specs. The following is a simple example:

H DFTACTGRP(*NO)

FSrcFile IP F 92 Disk

D Char20 s 20a

ISrcFile Ns
I 1 6 2SrcSeq
I 7 12 0SecDat
I 13 92 SrcDta

C Eval Char20 = SrcDta
C Char20 Dsply

Here the file is defined as Input Primary so I haven’t had to worry about using READ, CHAIN, etc. Compile the program and then call it with:

OVRDBF FILE(SRCFILE) TOFILE(*LIBL/QCLSRC) OVRSCOPE(*JOB)
CALL program_name
DLTOVR FILE(SRCFILE) OVRSCOPE(*JOB)

You should see the first CL source member in your library list displayed line by line.

All of the other file operations work the same way as they do for externally defined files, you just have to define the key attributes in the F-spec if you want to use random access.

All the best

Jonathan

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.
  • Kbarnette
    UTM400P is program described. File Specs 0025.00 FUTM400P IF F 96 DISK Input Specs 0153.00 * 0154.00 * Record layout for UTM400P 0155.00 * 0156.00 IUTM400P AA 1 C0 2 C0 3 C0 0157.00 I AND 4 C1 0158.00 I 11 22 CY 0159.00 I 31 42 CR 0160.00 I AA 0161.00 I 1 4 0RRNTHS 0162.00 I 5 6 0CALKEYmnth 0163.00 I 7 8 0CALKEYday 0164.00 I 9 10 0CALKEYyear 0165.00 I 14 14 0CALDAY Calc Specs 0188.00 C READ UTM400P 98 0189.00 C IF (*IN98 = *ON) OR 0190.00 C (CY(1) = *BLANKS) AND (CY(2) = *BLANKS) AND 0191.00 C (CY(3) = *BLANKS) 0192.00 C CALL 'QCMDEXC' 0193.00 C PARM CMD(2) 0194.00 C PARM 50 WKN155 0195.00 C GOTO ENDPGM 0196.00 C END 0248.00 C RRNTHS CHAIN UTM400P 98
    0 pointsBadges:
    report
  • TomLiotta
    What do you mean by "how a file is used"? A program-described file is used the same way an externally-described file is used. You READ them or WRITE them with the same instructions. Do you mean that you want to know how a program-described file is declared in a program? Tom
    125,585 pointsBadges:
    report
  • Siva313
    Hi,
    I have two input files infile1 and infile2.
    For infile1 I have fields emp_id, designation, location and bu
    For infile2 I have emp_id, first name and last name.
    I need a output in output file like empid, fullname, designation, location and bu.
    In program for obtaining full name we need to write eval fullname =first name + last name. 

    Please suggest me the program for dis ASAP
    10 pointsBadges:
    report
  • TheRealRaven
    In general, there should (almost) never be a need to code a program-described file. All physical files can be accessed as externally-described with a single field, and output files can be generated similarly. The field can then be redefined by a DS to enable the program to work with data in any way it needs to.

    You should only ever see a program-described file in old programs that have never been updated to work with newer features.

    (There can be isolated exceptions. Some utility functions can barely benefit from 'program-described', though they're almost always better done in other ways, usually in other languages.)

    A program-described file is a way of defining file records in program code instead of describing records in DB2. No DDS nor DML is used. Records are defined with I-specs for input files or O-specs for output files. O-specs for printing are perhaps most common now.

    (I'm not sure why. Almost no one would try using I-specs or O-specs for display files. A DSPF would be described with DDS and compiled, then referenced as an externally-described file. For some strange reason, though, some developers still use O-specs for PRTFs. I haven't figured out why DB files and DSPFs are good for external descriptions, but PRTFs should be described inside programs... especially when external PRTFs are so much easier to program over.)
    21,845 pointsBadges:
    report
  • Subhendu Sen
    To use a program described file in this environment, you must: have knowledge to identify the file(s) in the file description specifications that is input/output as. To create this type of file, use one of the create file commands, which can be found in the CL/APIs section of the programming category. A program described file must exist on the system also. Probably you are in a learning process. However, studying books are the best way to gather solid knowledge. For more info, you can link here, https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rzasd/filedes.htm.
    89,360 pointsBadges:
    report
  • TheRealRaven
    When a file is referenced in F-specs, a *FILE object must exist in the library list with the same name at compile time. That's true whether it's a program- or externally-described file. It can be just a temporary object, though, and deleted once the compile is complete.

    One use of "program-described" is to compile with a generic name of, say, 'INPUT' and a record length of the maximum allowed for a database file. When the program is run, OVRDBF can direct INPUT to point to essentially any database file on the system. Records can be read from any file and processed by the program as a single string of bytes rather than as a set of declared fields.

    This might be done as part of a process to locate and correct invalid bytes in records, such as non-numeric characters in packed-decimal fields.

    That's not a real problem for files created with DML, but it can be for older files created with DDS. DB2 validates data when a record is being written for DML, but it's done when records are read for DDS. So invalid data can be stored in DDS files. DDS files might have originated on older systems before SQL/DML was invented.

    That's one big reason why DDS should be avoided for creation of new database files.
    21,845 pointsBadges:
    report
  • GregManzo
    I disagree. An external file with only a single field is, for all intents & purposes, the same as a program described one. You get no real benefit from making it external. However, we have on a few occasions had programs that would need to write to one of N external files without knowing until run-time which one. A program described file & an override works quite nicely. (Yes, internally it has a DS to fill in specific fields.)
    1,720 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.

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

Following

Share this item with your network: