Do Your File Specifications Lie?

Published: January 21, 2009

by Ted Holt

An old joke says, "How do you know a salesman (or politician) is lying to you?" The answer: "His lips are moving." All joking aside, your RPG IV F specs can lie to you, and it's not obvious when they do. This is not a serious problem, but I've run across it on occasion and want to be sure others are aware of it.

Let's say the following program is running:

H dftactgrp(*no) actgrp('QILE')
Fcustcdt   uf   e             disk
Ferd01p    o    e             printer
 /free
     *inlr = *on;
     dow '1';
        read cusrec;
        if %eof();  
            leave;
        endif;
        write erd01p1;
     enddo;
     return;

This is a simple program, right? Read a record, write a record.

Someone else comes along and starts up this program while the first program is running.

pgm

alcobj obj((custcdt *file *exclrd)) wait(0)
call   SomePgm /* that uses custcdt */
dlcobj obj((custcdt *file *exclrd))

endpgm

The second user is greeted with message CPF1002 (Cannot allocate object CUSTCDT) because the second program thinks the first program is updating file CUSTCDT. The F spec in the first program lied, therefore the second program won't run.

Maybe the first program used to update CUSTCDT, but someone since removed the update operation and failed to change the F spec. Here's the corrected F spec, with the file designated as input only rather than updatable.

Fcustcdt   if   e             disk

Here's another variation of the same program, with yet another lying F spec.

H dftactgrp(*no) actgrp('QILE')
Fcustcdt   if   e             disk
Fsalesrep  if   e           k disk
Ferd01p    o    e             printer
 /free
     *inlr = *on;
     dow '1';
        read cusrec;
        if %eof();  
            leave;
        endif;
        write erd01p1;
     enddo;
     return;

The second F spec claims that this program uses the sales representative file, but that's not true. The compiler generates warning message RNF7066 (Record-Format REP not used for input or output), but that warning message is unreliable. If you issue native I/O operations, such as CHAIN or READ, to a file name rather than its record format name(s), the compiler will generate RNF7066. In other words, RNF7066 is not a trustworthy indicator that the file is not used in the program. For this reason alone, I use record format names, rather than file names, in calculations when possible.

By the way, the RPG III compiler will generate hard errors for these situations, but I'm not suggesting you use RPG III.

The consequences of lying F specs may be more nuisance than catastrophe, but here are a few of the results that I have seen.

1. As illustrated above, a program might not run because of another program's lying F spec.
2. Performance is affected, as programs open and close files they don't use.
3. Documentation packages may erroneously report that a file is being used, leading to wasted developer time when that file is modified.
4. Based on their reading of source code, developers may make erroneous decisions or infer erroneous behavior of job streams.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot