WRITE WORK FILE

, ,
1

I just came across a module that READS a WORK FILE and WRITES A WORK FILE (from the READ file). There is a comment that states: "Any time a WRITE WORK FILE statement is used, the WORK FILE is open regardless of whether any records are written to it. This program saves the file so when the next program is run the file is not left empty.

Is this necessary/real or is this an old (NAT 1.2) problem that’s been corrected or a figment of someone’s imagination?

Thanks
GXPACKF5.DOC (3.56 KB)

2

Natural clears the workfile before writing into it. So if you want so save the original content of a workfile, you should copy it. And that’s exactly what your attached program does. BTW: A printfile wouldn’t be cleared.

But the comment sounds like “If there is a WRITE WORK FILE anywhere in the code, Natural clears the file, regardless whether the WRITE WORK FILE statement is reached during execution or not.”
I don’t know such a problem (Maybe it’s really old). I tried out the following code:

if 1 = 0
  write work file 1 'test'
end-if
end

And my workfile 1 isn’t empty afterwards…

3

You didn’t show us how this module is executed or what the work file contains, so it’s difficult to discuss your specific situation, but many developers have had difficulty creating empty files in Natural, and this program may be a result of that difficulty. (How’s that for a run-on sentence? :slight_smile: ) My guess is that your program doesn’t write any records at all, but is used to force the creation of an empty file.

Here’s the typical situation:
. A large program writes a WORK file.
. Due to size constraints, the program is broken into subprograms, one of which writes the WORK file. This subprogram is invoked conditionally.
. During some runs, the “condition” does not exist, and the subprogram is not called. No records are written to the WORK file.
. Because Natural does not “see” the WORK file (ie does not encounter a WRITE WORK statement), it neither opens nor closes it. There is no reason to inform the operating system of such things as the file’s logical record length (LRECL).
. The operating system attempts to close the file, but finds no LRECL in the JCL. Because Natural did not pass the LRECL, the file is not closed properly.
. When attempting to open the file in a subsequent JCL step, an I/O error is thrown.

The solution is to allow Natural to provide the LRECL to the operating system.
Option 1: code the LRECL in the JCL (my recommendation)
Option 2: ensure that Natural “sees” the file. In the mainline, code something like

IF  FALSE   
  THEN   
    WRITE WORK 1 #A (1:450)   /* must match LRECL in subpgm XXXXXXXX   
END-IF

For more information, go to the SAG-L archives, or come see my presentation, Natural Batch Topics, at the Natural Conference in Philadelphia in October. :smiley:

4

Richard,

have a look at the documentation of the WORK profile parameter and NTWORK macro, subparameters OPEN/CLOSE. With this information and the information of the prior posters this might help to understand and solve your problem.

5

Just to be clear about who’s doing what: the operating system resets the file to empty when a program opens it for writing, unless DISP=MOD was specified. So if for any reason Natural issues an open request, the result is an empty file (unless Natural also writes some records after the open.) The document Wilfried linked to describes how Natural determines whether or not to issue the open request.