Re: TIMA cpu use VS DLYJOB

I used to have a screen capture from the thing but I can't find it now. Rats. It was a truly inspiring number I think in the Trillions.

I don't recall the rule about reuse deleted records but there is some logic to that to me. It is not in the help text for OVRDBF.

Also if you read the help text for the EOFDLY parm it doesn't, to me at least, correctly describe the behavior. It actually says the job will wait that long (as specified on EOFDLY) before it will attempt to read another record. But what it actually does is get the next record written to the file immediately. The delay says if NO records are written for one EOFDLY interval then the read fails with EOF. Hmmm.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 3/17/2014 4:08 PM, Steinmetz, Paul wrote:

Larry,

Do you remember what the IO counts were?
IBM marketing/sales may want to patent that program to justify an upgrade is necessary.

Our apps use a combination of DLYJOB and EOF delay. Correct me if I'm wrong, but when using EOF delay, REUSDLTRCD must be set to *NO.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Monday, March 17, 2014 4:00 PM
To: Midrange Systems Technical Discussion
Subject: Re: TIMA cpu use VS DLYJOB

I did some work for a customer who had a model 170 that ran one job. The job would read a file to see if data was in it. If not it would read the file to see if there was data in it. If not it would.....

So the thing ran at over 99% of the CPU all day and that's why they moved it to a server all it's own as it was affecting production.

I asked if they had considered EOF Delay. They said they didn't want the thing to wait they wanted it to get the next record right away. When I explained how EOF Delay worked they face palmed.

I will say the READ counts on that file were truly awesome especially for a mere 170!

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 3/17/2014 12:17 PM, Gary Thompson wrote:

Thanks Brad!

I've been using F10, thinking I wanted cpu re-calculated since the
last F10 press, and not "average" cpu over an extended period with a
mix of "run" and "sleep"

After watching this job today, I think I've made some mistake . . .
the time spent in Status = TIMA seems way too short . . .

The program is coded:
sleep(IdleSec);

Where IdleSec is a 3,0 Numeric (Zoned) value fetched from a data area
. . .

the data area currently has the value: 120

I need to run in debug to verify the mechanics . . .

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Monday, March 17, 2014 9:14 AM
To: Midrange Systems Technical Discussion
Subject: Re: TIMA cpu use VS DLYJOB

Are you using F5 or F10 to view the CPU in WRKACTJOB? And how much time are you sleeping?

I have similar jobs that do this and when sleeping take virtually zero CPU.

Brad
www.bvstools.com



On Mon, Mar 17, 2014 at 8:30 AM, Gary Thompson <gthompson@xxxxxxxxxxx>wrote:

We run a "never-ending" job that monitors for shipments that are
ready for customer delivery and which require an EDI 856 Advance
Shipment Notice.

My question is why the amount of CPU use reported on Work with Active
Jobs shows something like 34% when the job is in Status = TIMA ?

The exact percent CPU use appears to vary depending on load so that
the use during Status = TIMA is lower on a busy system, and higher on
a less busy system.

This job is based on an SQLRPGLE program that calls
sleep() between steps which process products as they are prepared for
customer delivery and creates the required documents and data
required for the Advance Shipment Notice.

I wonder if it would be better to replace the call to sleep() with a
call to a CLLE module to run a DLYJOB command ?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.