RE: Quantify processing wasted by lots of little jobs

We code all of our NEP's to check for external shut down just before the
command to get the next transactions, weather it is read a data queue,
message queue, or socket. (or read a file.) We also set a wait for
around 60 seconds, usually set from a control file or data area. We
also code special entries to reset, end, or clear queues. The reset
allows us to make program changes and then resubmit the job to pick up
the new program just before ending.

Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, November 01, 2007 3:21 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Quantify processing wasted by lots of little jobs

FWiW:
Although the "end-the-program" request is good practice to enable a
controlled shutdown of the NEP, that does not help with the controlled
ENDJOB or ENDSBS requests. That also does not assist when it is a
non-keyed single-queue implementation, and the only queue has many
entries in wait; queued up before the end request. Thus the NEP could
still timeout and check the in-controlled-end status flag in a coded
loop; where the timeout is under half of the default controlled end
wait-time -- the /default/ according to the system management rules, not

necessarily the default on the ENDxxx commands themselves. If the NEP
processes large/long requests, and the importance of allowing completion

of a request should dictate a delay to the start of controlled end
requests, a scripted/custom ENDSYS can send the "end-the-program" and
await feedback from that request, before issuing the actual ENDxxx.