Re: want to CHKOBJ from cobol pgm

On 25 Apr 2012 10:42, Stone, Joel wrote:

Great ideas, but I don't think it will work in this case! Please
prove me wrong.

Where "it" refers to allowing whatever depends on a missing object to fail, thus by presumed-success style coding, allowing a function to proceed without first ensuring all the required objects exist.

I am printing signatures (*PAGSEG) on a document. The pgm writing
the *PAGSEG object couldn't care less if the signature exists or
not, it will happily write the external printer file record with the
JOHNDOE signature and keep on going.

Obviously if the feature being utilized does not "fail" per the missing objects, the presumed-success style is vitiated by the design of the [at least poorly informative] feature being utilized. Thus as I had suggested, "normally" one would defer the dependency check to the feature that has the dependency.

Besides, I was not intending to suggest that presumed-failure should never be utilized; merely alluding that often such code still might encounter the same missing-object problem, but arising only from a concurrent delete which has since-removed the object that has just been verified to exist [but was not allocated to prevent the concurrent deletion; i.e. CHKOBJ vs ALCOBJ was utilized]. And if concurrency is not a general concern for the application, for example ameliorated in some manner or easily handled in only rare exception cases outside of coding or for which coding for that exception case is not grievous, then the only harm in proactively checking for existence is generally just cycles that probably would never have been used anyhow.

However when the OS starts printing the spool file, and the *PAGSEG
named JOHNDOE isn't found, it crashes with error "*PAGSEG" not
found.

Dastardly!

How can I avoid the pre-checking for the *PAGSEG object? Can I
OVRSPLF and somehow tell the writer to ignore *AFPDS elements that
are not available at print time?

If there were an OVRSPLF, perhaps. But, Sorry, No. I do not know how one would handle the scenario well for the design of printing with "named" [versus by address] external resources that are not protected from rename, move, or delete; presumably also from neither re-create nor change where the resource could conceivably entirely different to the point of incompatibility. But as described [even if not accurately], that implies the pre-checking performed at spooling-time may still be pointless to the eventually printing-time.

Regards, Chuck

CRPence on Wednesday, April 25, 2012 12:20 PM wrote:

On 25 Apr 2012 09:04, Stone, Joel wrote:

<<SNIP>> Is there a better method for checking if object exists?

Normally the attempt to use a missing object is the best way. If
any proactive attempt is made, then concurrency means the
presumed-failure style of proactive checking could make an improper
decision; i.e. had the programming style been presumed-success and
just attempted to use the object and found the object to have been
created by then, the code could have continued without error or
ever knowing the object may have been missing even just a
microsecond before.

If one must insist on using the very less desirable pre-check,
then <<SNIP>>