RE: Odd situation involving IFS objects and ZLIB compression

Could there be ... but nailing down the "what" inside your code, the pdf
code, the zip code, etc - since you mentioned another server job locked up
- i've always found in multi-product code there is a need for some form of
monitor/retry.
Almost any part of this could have asynchronous actions.
Have seen very similar issues in spool transform products and then emailing
the pdf (with a different vendor's product).

Jim Franz

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James
H. H. Lampert
Sent: Monday, February 12, 2018 5:52 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Odd situation involving IFS objects and ZLIB compression

New information, even without the new diagnostic:

I found another server job locked up at the same point, in the same CL
program (it had launched, and resolved the CL program, before I added the
diagnostic, so it didn't have it). And this time, the temporary directory
was still there, and the PDF was still sitting in it.

I was easily able to create a test ZIP from the PDF, exactly the same way
the CL program does.

Could there be some process that is asynchronously "not finished with"
the PDF, at the time the CL program attempts to ZIP it? I should think that
if this were the case, it would be somehow connected with the CHGOBJOWN,
rather than with the PDF generation itself, (if it were the latter, then
wouldn't it interfere with the CHGOBJOWN?)

--
JHHL