en, I think CPU high is very common if there is just one job running. In batch windows, CPU is always above 80%. Program will get the CPU and donnot lose CPU until it need to do IO or system want to dispatch other job. Extremely, bad program is in loop and it will occupy the CPU.
So you can use RMF to monitor the job and open GTF trace to analyst it if you want. Best regards, He Ming (贺 明) 发件人： Staller, Allan 发送时间： 2006-10-12 22:09:32 收件人： IBM-MAIN@BAMA.UA.EDU 抄送： 主题： Re: Curiousity: CPU % for COBOL program Without the souce code I can't make any intelligent suggestions. However, if you can find a copy of "The Elements of Programming Style" it will give several examples of "bad" vs "good" code and how to get from here to there. IIRC, at one time there were (at least) three versions. One each for COBOL, FORTRAN, and ????? HTH, <snip > > > Not unusual at all. Poorly written code in any language can do this. > E.G. In cobol terms, using display fields in computations instead of > the relevant decimal or binary items (PIC 99999 vs pic 99999 comp-3 > vs pic 99999 comp). > See, I am under the weather. I meant other than poor coding. Oh, and perhaps I should add that we don't do anything particularly fancy. This is basically VSAM I/O (no database) and processing records. And I have seen many times where the programmer does exactly as you have said, using a USAGE DISPLAY numeric as an array index value. I really wish that the COBOL compiler would put out "idiot alert!" messages when this happens. And then, as a non-overridable system option, refuse to compile the program. </snip > ---------------------------------------------------------------------- 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
