Re: Curiousity: CPU % for COBOL program
You shouldn't be looking at high CPU utilization but at total CPU usage and EXCP counts for the job step (freely available from the usual IEFACTRT exits). High CPU utilization could be a sign of a very efficient and well tuned program, or a sign of gross choice of internal algorithms. Bottom line though, if total consumption is not enough to be significant in your shop, or to adversely affect other important work, or to cost more than the user end-user is willing to pay, it may not be worth pursuing. If the job is causing problems either from excessive CPU usage or excessive I/O, the cheapest thing to check and fix is I/O tuning since in many cases this is just a JCL change. If EXCPs on any DD is high (say 10K EXCPs and up), check that this is reasonable based on the number of records and blocks in the file. For sequential DASD files check for the obvious - poorly blocked or unblocked records. If a sequential file is humongous, requesting enough buffers for full cylinder or at least multi-track I/O may reduce overhead. For VSAM, BUFNI and BUFND should always be specified, as the defaults are inadequate for either sequential or random processing. In extreme cases you may want to trying using BLSR. I have seen cases where a factor of 10-100 reduction in EXCP's and CPU has been achieved simply by adding appropriate buffering to a VSAM file. IDCAMS LISTCAT before and after a run is your friend for detecting VSAM abuse. If you have to go down to the level of program code, then look for the obvious again: Arrays being repeatedly searched, especially serial search (it's incredible how much CPU can be used by a serial search of even a relatively small array of 10-20 elements if you do it 100,000 times). I have seen extreme cases where a corporate want-a-be programmer had actually written COBOL code using a serial search of a 100,000 element table! Even a binary search (SEARCH ALL) of a large array of several 1000 elements is radically less efficient than a hash table lookup if you are going to do it 1,000,000 times. Another big problem (which will also show up in your EXCP data) is repeated look up of the same data using a VSAM file as a table when an internal table is more appropriate. A strong clue to this kind of behavior is a VSAM file with an EXCP count orders of magnitude larger than the total number of records in the file! Frequently the biggest savings are made by taking a totally different approach to the problem, but when dealing with applications that are not your responsibility one would rather not get down to that level. McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Thursday, October 12, 2006 9:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 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, Thanks. I guess I was asking because I don't have an automated way to check for bad coding. And I was wondering if it was even worth my time. If a high CPU utilization is normal, then it would likely be a waste of time to desk check the code. But if high CPU utilization is sufficiently abnormal, then it might be worth my time (and salary) to do some spot checks of code and write a report to management. One that would likely cause the programmers to hate me even more. They already don't like me becase I now almost always require a service desk ticket to do any work. But I can charge time to those tickets, which proves my salary is worth paying. Why it is easier to walk to my desk and ask me to do something than to write a email to the help desk to open a ticket is beyond me. Perhaps because they don't want it known how often they ask for our services? Speculation. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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
Curiousity: CPU % for COBOL program
I'm feeling under the weather today and our zSeries is pegged at 100%, so I thought I'd ask a curiousity question here. I hope you don't mind. I have never considered COBOL to be a language which would normally be used to write a program which would cause high CPU utilization (as in percentage). But I've noticed lately that many of our batch COBOL programs can run our z890 (capacity 250) at over 20% CPU as shown by SDSF. And I don't mean just a spike now and then, but for minutes at a time. Does this seem weird to anybody else? I am afraid that it likely means that the COBOL code is not written very well, but we don't have anything like Strobe (which we threw out due to cost during the previous management cycle), so I cannot be sure. Oh, and we won't likely get anything to replace it because the programmers refuse to use it anyway. They're too busy (and they are). Well, since I can't do anything about it anyway, it is just a talking point. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Curiousity: CPU % for COBOL program
Not odd at all. We have COBOL jobs that do that. We have 1 particular job that walks an IDMS database and formats the records for pushing out to MQSeries. When they run this thing, I can almost see the lights dim. The COBOL takes 50% of the machine and MQ takes the other 50%. 14 hours later, the thing is done. I know this is an exception, but they do exist... We also have others that are somewhat CPU intensive - just not to this extreme. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, October 12, 2006 8:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Curiousity: CPU % for COBOL program I'm feeling under the weather today and our zSeries is pegged at 100%, so I thought I'd ask a curiousity question here. I hope you don't mind. I have never considered COBOL to be a language which would normally be used to write a program which would cause high CPU utilization (as in percentage). But I've noticed lately that many of our batch COBOL programs can run our z890 (capacity 250) at over 20% CPU as shown by SDSF. And I don't mean just a spike now and then, but for minutes at a time. Does this seem weird to anybody else? I am afraid that it likely means that the COBOL code is not written very well, but we don't have anything like Strobe (which we threw out due to cost during the previous management cycle), so I cannot be sure. Oh, and we won't likely get anything to replace it because the programmers refuse to use it anyway. They're too busy (and they are). Well, since I can't do anything about it anyway, it is just a talking point. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 -- 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
Re: Curiousity: CPU % for COBOL program
snip I have never considered COBOL to be a language which would normally be used to write a program which would cause high CPU utilization (as in percentage). But I've noticed lately that many of our batch COBOL programs can run our z890 (capacity 250) at over 20% CPU as shown by SDSF. And I don't mean just a spike now and then, but for minutes at a time. Does this seem weird to anybody else? I am afraid that it likely means that the COBOL code is not written very well, but we don't have anything like Strobe (which we threw out due to cost during the previous management cycle), so I cannot be sure. Oh, and we won't likely get anything to replace it because the programmers refuse to use it anyway. They're too busy (and they are). /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 9 vs pic 9 comp-3 vs pic 9 comp). -- 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
Re: Curiousity: CPU % for COBOL program
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Thursday, October 12, 2006 8:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Curiousity: CPU % for COBOL program 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 9 vs pic 9 comp-3 vs pic 9 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. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
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 9 vs pic 9 comp-3 vs pic 9 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
Re: Curiousity: CPU % for COBOL program
Hi. In general I have seen that most of the problems of performance and consumption of CPU in program Cobol Batchy must to problems with the I/O in archives VSAM. Very good improvements are obtained with adjustment of buffers and sizes of CI in the definition of clusters. Also the performance improves if in the programs the logic is modified to accede the records in sequential mode. Atte. Alvaro. -Mensaje original- De: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] En nombre de McKown, John Enviado el: Jueves, 12 de Octubre de 2006 10:03 Para: IBM-MAIN@BAMA.UA.EDU Asunto: Re: Curiousity: CPU % for COBOL program -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Thursday, October 12, 2006 8:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Curiousity: CPU % for COBOL program 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 9 vs pic 9 comp-3 vs pic 9 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. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 -- 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
Re: Curiousity: CPU % for COBOL program
John, I presume you've checked the compiler options and the run time options. Do you have a copy of the COBOL Performance Tuning manual. Jim McAlpine On 10/12/06, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Thursday, October 12, 2006 9:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 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, Thanks. I guess I was asking because I don't have an automated way to check for bad coding. And I was wondering if it was even worth my time. If a high CPU utilization is normal, then it would likely be a waste of time to desk check the code. But if high CPU utilization is sufficiently abnormal, then it might be worth my time (and salary) to do some spot checks of code and write a report to management. One that would likely cause the programmers to hate me even more. They already don't like me becase I now almost always require a service desk ticket to do any work. But I can charge time to those tickets, which proves my salary is worth paying. Why it is easier to walk to my desk and ask me to do something than to write a email to the help desk to open a ticket is beyond me. Perhaps because they don't want it known how often they ask for our services? Speculation. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 -- 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
Re: Curiousity: CPU % for COBOL program
I have used Omegamon to look at batch CPU usage. Sometimes most of the CPU is in the Cobol (or whatever) main module, sometimes there is inter-module calling, sometimes systems services like IDGZILLA show up. I think if one module in a call-each-other job lags on a non-LE compiler when the others move to LE, it can be bad as well. It's been a long time, but compiler options can do bad things. We still have CA-Optimizer and certain debug options here are standard. I think the way it's used here, it's a DE-optimizer. -- 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
Re: Curiousity: CPU % for COBOL program
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim McAlpine Sent: Thursday, October 12, 2006 9:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Curiousity: CPU % for COBOL program John, I presume you've checked the compiler options and the run time options. Do you have a copy of the COBOL Performance Tuning manual. Jim McAlpine I don't know. I'll check when I'm back in the office. I'm working from the house today due to a medical procedure around lunch time. I live fairly close to the doctor's office. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Curiousity: CPU % for COBOL program
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 9 vs pic 9 comp-3 vs pic 9 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
Re: Curiousity: CPU % for COBOL program
John I'm home-bound all the time which means that all my reading is done online and Google is my friend. Using IBM COBOL Performance Guide I discovered IBM Enterprise COBOL Version 3 Release 1, Performance Tuning with my first hit, which was http://www-306.ibm.com/software/awdtools/cobol/library/ leading me to http://www-1.ibm.com/support/docview.wss?uid=swg27001475aid=1 Is this the manual you need? Chris Mason - Original Message - From: McKown, John [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, 12 October, 2006 4:37 PM Subject: Re: Curiousity: CPU % for COBOL program -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim McAlpine Sent: Thursday, October 12, 2006 9:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Curiousity: CPU % for COBOL program John, I presume you've checked the compiler options and the run time options. Do you have a copy of the COBOL Performance Tuning manual. Jim McAlpine I don't know. I'll check when I'm back in the office. I'm working from the house today due to a medical procedure around lunch time. I live fairly close to the doctor's office. -- John McKown -- 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
Re: Curiousity: CPU % for COBOL program
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Thursday, October 12, 2006 10:25 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Curiousity: CPU % for COBOL program John I'm home-bound all the time which means that all my reading is done online and Google is my friend. Using IBM COBOL Performance Guide I discovered IBM Enterprise COBOL Version 3 Release 1, Performance Tuning with my first hit, which was http://www-306.ibm.com/software/awdtools/cobol/library/ leading me to http://www-1.ibm.com/support/docview.wss?uid=swg27001475aid=1 Is this the manual you need? Chris Mason I'll look tomorrow. Thank you very much for looking them up for me. I appreciate it. I'm using a 'work at home' (Microsoft Terminal Server) system and it is a bit difficult for me to get used to for some reason. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Curiousity: CPU % for COBOL program
I know that someone has already given one of these references, but the two places that I would start (given the information you have provided in the thread) are: The Performance tuning paper (which application programmers can EASILY read and understand) at: http://www-1.ibm.com/support/docview.wss?rs=203q=7001475uid=swg27001475 And the section Improving VSAM performance of the Programming Guide at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/1.10.7 You should be aware that the latter SAYS that normally a systems programmer will help (or do) the tuning for VSAM, but I still think that application programmers can get a lot out of that section. McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I'm feeling under the weather today and our zSeries is pegged at 100%, so I thought I'd ask a curiousity question here. I hope you don't mind. I have never considered COBOL to be a language which would normally be used to write a program which would cause high CPU utilization (as in percentage). But I've noticed lately that many of our batch COBOL programs can run our z890 (capacity 250) at over 20% CPU as shown by SDSF. And I don't mean just a spike now and then, but for minutes at a time. Does this seem weird to anybody else? I am afraid that it likely means that the COBOL code is not written very well, but we don't have anything like Strobe (which we threw out due to cost during the previous management cycle), so I cannot be sure. Oh, and we won't likely get anything to replace it because the programmers refuse to use it anyway. They're too busy (and they are). Well, since I can't do anything about it anyway, it is just a talking point. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- 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
Re: Curiousity: CPU % for COBOL program
John, Over the years I have seen plenty (more that 25) cobol programs than can pin the needle for as long as they are running. This was on a variety of COBOL compilers, This was also not a looping condition per se. It was designed into the program and yes it was productive computing. The looping was varied as to the programming reason. Yes it drove our cap perf person nuts. We had one troublesome program that typically drive the pin for 3 or 4 hours (sorry don't remember which as it was a long time ago. We hired a expert cobol type and he was able to reduce it enough to pay for his expertise. I do remember the application people were tight mouthed as to what he did. I don't know whether it was because it was less than competent programming or what. I have heard that some companies justified STROBE because of this type of program. I fought it tooth and nail and was able to shoot it down 2 or 3 times. Ed On Oct 12, 2006, at 8:13 AM, McKown, John wrote: I'm feeling under the weather today and our zSeries is pegged at 100%, so I thought I'd ask a curiousity question here. I hope you don't mind. I have never considered COBOL to be a language which would normally be used to write a program which would cause high CPU utilization (as in percentage). But I've noticed lately that many of our batch COBOL programs can run our z890 (capacity 250) at over 20% CPU as shown by SDSF. And I don't mean just a spike now and then, but for minutes at a time. Does this seem weird to anybody else? I am afraid that it likely means that the COBOL code is not written very well, but we don't have anything like Strobe (which we threw out due to cost during the previous management cycle), so I cannot be sure. Oh, and we won't likely get anything to replace it because the programmers refuse to use it anyway. They're too busy (and they are). Well, since I can't do anything about it anyway, it is just a talking point. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 -- 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
