Re: V5R1 STRTRC problems

Thanks for the response. It helps a lot.

I still have one concern. There was an exit program on TRCJOB. What is the
equivalent on STRTRC? The purpose was to filter events that you didn't need.

Thanks again

At 06:34 PM 3/30/02 -0600, you wrote:

>I can respond to your comments below....
>
>You can have more than one PEX session, and you can have more than one
>trace started with STRTRC, active on the system at a time.
>
>The restriction is that a job can be in one PEX collection or one trace at
>a time; you cannot trace the same job two times at the same time.
>
>Using STRTRC, you do not need to use STRSRVJOB.  However, the STRTRC
>command allows you to specify the job name directly (see the JOB
>parameter).  So yes, you can trace jobs other than your own.    In
>addition, the STRTRC command allows you to specify up to 8 job names on one
>STRTRC invocation - you can start a single trace that will collect the
>trace on up to 8 specific jobs at one time.  In order to trace 8 jobs using
>TRCJOB, you needed to have 8 jobs in which you did the STRSRVJOB/TRCJOB
>(since you can only STRSRVJOB on a single job at a time).
>
>In addition, STRTRC allows the specification of a generic job name.  Any
>job specified on the STRTRC command that is not a fully qualified name
>(######/USERID/JOBNAME) is considered to be a generic job name.  Only one
>trace started with STRTRC that traces a job with a generic name can run on
>the system at a time.  Trying to start a second 'generic trace' will result
>in an error message.
>
>When tracing multiple jobs with the STRTRC command, you can later use the
>PRTTRC command to print out all the trace information, or you can print it
>out for a subset of the jobs that were traced.
>
>STRTRC eliminates many problems TRCJOB had, including:
>- STRTRC has significantly improved performance characteristics,
>particularly on call-intensive applications (it is much less intrusive -
>however, ENDTRC may take a while to complete - it's probably a good idea to
>submit the ENDTRC command to batch)
>- STRTRC has a much larger buffer size (up to 4Gig, whereas TRCJOB only had
>16Mb)
>- STRTRC allows multiple jobs to be traced with one STRTRC invocation
>- STRTRC eliminates the need to use STRSRVJOB to trace other jobs
>- More granular timestamps in the trace output (microseconds instead of
>milliseconds)
>- More granular database statistics in the trace output
>
>
>Dawn May
>A biased developer who worked on the new job trace!
>
>
>
>
>
>                       Vernon Hamberg
>                       <vhamberg@attbi.co        To:
> midrange-l@midrange.com
>                       m>                        cc:
>                       Sent by:                  Subject:  V5R1 STRTRC
> problems
>                       midrange-l-admin@m
>                       idrange.com
>
>
>                       03/29/2002 04:50
>                       PM
>                       Please respond to
>                       midrange-l
>
>
>
>
>
><snip>
>
>If someone says that you can only have 1 PEX session at a time (as the
>Redbook says) on the system, I know this is not true. And TRCJOB never had
>that kind of restriction. Maybe one per job, but that was the case with
>TRCJOB--no loss.
>
>2. TRCJOB (and STRJOBTRC if you have Perf Tools) were connected to
>STRSRVJOB. I.e., if you had run STRSRVJOB and then TRCJOB, it collected
>data over the serviced job, not your own, as is the case if you are not
>servicing another job.
>
>STRTRC does not do this. So we have lost what could be an important bit of
>functionality, IMO.
>
><esnip>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.