× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We had the same need many years ago. We wanted to track jobs that ran overnight and see if there was any trending that some were taking longer and longer. We just created a simple table with job, program, date, start time, end time and an RPG to update this new file. Then wrapped the RPG around each call in the CL.

CALL UTRTIMER ('START' &JOB, 'PROGRAMA')
CALL PROGRAMA
CALL UTRTIMER ('END' &JOB, 'PROGRAMA')

Table looks like this
<job>,<application>,<date>,<start>,<end>
SR_NIGHT, PROGRAMA, 20090812,10:45:23, 10:47:34

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, December 10, 2010 10:26 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Need to record the timing of each CALL step in a batch job...

On 12/8/10 1:32 PM, Charles Wilt wrote:
I have a request to start tracking the time each step takes in a batch
process...

A manual process might be, to look through the job log for

*NONE Command 12/08/10 02:29:44.407088
QCLCLCPR QSYS 04CB FS001C HLTHPRDPGM 0242
Message . . . . : 34100 - CALL PGM(PR002R)
/* The CALL command contains parameters */

*NONE Command 12/08/10 02:29:57.622312
QCLCLCPR QSYS 04CB FS001C HLTHPRDPGM 0251
Message . . . . : 34900 - CALL PGM(PR051R)
/* The CALL command contains parameters */

Obviously, a manual process would not be my preferred method, given
that this needs to be done for multiple jobs and is not a one-time
thing. Additionally, I need the specifics of the parameters used
during the call.

My thoughts
1) Use command exit point(s) process/log the CALLs, but it appears
that CALL is one command for which the exit point is not invoked.
2) Replace CALL command with custom command whose CPP does the logging
needed
3) DSPJOBLOG OUTPUT(*FILE) or maybe OUTPUT(*APIDFN) at the end of the
process, but *FILE at least doesn't provide the parameters used during
the call
4) List Job Log Messages (QMHLJOBL) API or Open List of Job Log
Messages (QGYOLJBL) API, guessing that neither of these will have the
parameter info I need either...

So it appear that my only option is option 2....

Does anybody have any thoughts, comments or alternatives?


When I have had need to do something like the described for a specific process [e.g. a test-case or other batch script or CLP], I typically would convert the CL or CLP to REXX to have a procedure DoRequest which is then invoked by "DoRequest CALL PGM(...", having replaced each "CALL PGM(...". The DoRequest procedure first does a SAY of the request, then the request itself, and finally a summary SAY; the former adding something like TIME() as a prefix.

FWiW, seems to me that "5) Application logging" is a better option if the function might best, not be limited to just the one script\program:

One approach is to change the calling program(s) to invoke some logging prior to [and probably also after] each call. Another approach has each called program inquire [by review either of a passed parameter or of some logging indication] to determine if a request for logging is currently active, then log entry and optionally exit.

Regards, Chuck
--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.