Re: cannot find printer file defined field

[Barbara Morris <bmorris@xxxxxxxxxx>]

Lim Hock-Chai wrote:
> Thanks for the tip.  Sure is a strange one.  Couldn't quite understand
> the reason given.

When the compiler reaches the end of the source file, it checks to see
if there are any externally-described record formats that had output
operations (write, update, exfmt), then it generates O specs for those
record formats.  Since O specs appear before subprocedures, and since
they are logically part of the main procedure, the O spec generation has
to happen before procedures are scanned.  So when the compiler finds a P
spec, it does the O spec generation; but it can't just do the ones that
have had output operations in the main procedure; it has to do them all,
in case they have output operations later in a subprocedure.

It could be considered a bug, but the compiler decides it has entered P
specs even if it's a blank P spec.

Joep is right that just putting a blank P spec by itself is a dirty
trick in a production program; if this were necessary as part of the
permanent program, it should be preceded or followed by a comment.  But
if the fields in the output format were needed just as fields, it would
be better to define an externally-described data structure to bring in
the fields.

Usually this problem only comes up because the program is in an early
stage of development and the output operations haven't been added yet. 
In that case, adding a kludgy empty P spec seems ok to me; better than
adding output statements before you're ready to add them.