> > I am not doing a COMPILE,BIND,LINKLED. Its the application trainee users who perform > this task. Not the same user but different users performing same task as part of > training. Just curious to know if there are any limitation on TGNUM or CPU time to > know if a Job is taking more resources
Jake, The answer to this question is - it depends. A large number of TGNUMs maybe valid depending on what the data is that is going to sysout. If it is due to a Compile/Link/Bind, and the program being compiled is very large, then it might be okay. CPU utilization - same answer. It might be okay. Since you do not have any performance tools (at least none that you have identified), the one way to handle this is to use RMF. You need a job that repeats this issue for you. Once you have a job that if you run it x number of times you see the same behavior, then you can review the sysout it produces, the RMF data to see what resources it is using, and possible run a GTF trace or gather an SVC Dump for review. If this is not repeatable with the same job. Then you have an unknown condition where you need to be waiting for it to occur. There is not rule of thumb that says - if the job is taking XX number of EXCPs it is in a loop. Or if job is producing YY amount of output (TGNUMS) it is in a loop. As others have pointed out - you need to know what the job is doing and determine if it is okay or not. Since each shop is unique, it is very had to say When condition A occurs, I have a loop. For example, I can use IEBGENER to copy a tape to SYSOUT. I use a large number of TGNUMs but I am not looping. Or, my LPAR does not have sufficient Page Packs or Central Storage, therefore my job is causing a high number of Swaps. Due to limited resources, my job is having problems that is causing problems for other jobs on that LPAR. It does not mean my job is the problem. But that the lack of resources and the workload running causes an overall system issue. So, I would suggest that the next time you have what might appear to be a looping condition you start with RMF and using option 3 (RMF Mon III) drill into the job and see what resources are being used and what impactors might be involved. I would also recommend looking at the REDBOOK - EFFECTIVE PERFORMANCE MONITORING Using RMF http://www.redbooks.ibm.com/redbooks/pdfs/sg246645.pdf . Even if you do not have RMF it would probably help you get ideas where to look or what to trap. If you do not have RMF or implemented RMF on this LPAR, then this will become even more of a challenge to do. But perhaps you have other LPARs where RMF or other performance tool is running. If so, you might be able to collect the data from this LPAR where the problem resides and take it to another LPAR for analysis. Questions you need to consider 1) What is the job doing? Is the process normal or an exception a) Is it always a compile/bind and link? Or are there other types of jobs that are doing this? b) Do the job that appear to loop always use the same JCL when this occurs? Or is the JCL different? c) Do the job that appear to loop always use the same PARMs when this occurs? Or are the parms different? 2) Does this issue occur with the exact same job or does it vary with the same job or does it happen to random jobs? 3) When this happens, can an SVC Dump be collected? a) What does the Trace data show. Make sure the Trace table for SVC Dumps is at maximum if possible for this 4) What other GTF Traces might be useful for this analysis? IO, VSM, etc... 5) Is RMF available? If so, look at the various options under RMF MON III 6) Any slip traps that could be set to capture data to identify the problem? This might be on the program (compiler, binder or linker) or possible a generic slip for a specific job name. or a MSGID slip to dump when a specific message occurs. There are probably other directions to look. But these would be my choices to start. Lizette ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
