-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, December 27, 2007 12:24 PM To: [email protected] Subject: Re: Controlling COBOL DDs named SYSOUT
<SNIPAGE> Judicious use is, barely, tolerable to me (see below). About all that I consider to be judicious is the writing of "statistics" such as "records read", "records deleted", "records updated", "new records written", although I've never noticed anybody actually using that information for anything. <SNIPAGE> I guess after the 30th time that some nit-wit of a programmer (granted that they are few in number) used up 35% of my SPOOL, I got just a bit "down" on use of the DISPLAY verb. Especially when it was putting out "debugging" information about entering and exitting paragraphs, while reading a 30 million record master file. Anything that can be done with the DISPLAY can be done using the "normal" COBOL I/O verbs. So far as I am concerned, if it is a report, then use an FD! It's just that DISPLAY is so simple that, in my experience, it can be greatly abused. And if it is a report, I unsure which is more CPU efficient: an FD with a WRITE or a DISPLAY ... UPON SYSOUT. CPU costs hard dollars in my z/OS world. We are looking at a CPU upgrade which I will bet could be delayed if our application code was more efficient. Perhaps Strobe will help. If anybody will use it. We had Strobe in the past, but programmers only used it during a contest where they got bonuses for finding and fixing CPU hogs. Another reason why management wants off of the "z". Windows or Linux on Intel is basically licensed by processor, regardless of the "power" of that processor. System z and I think System i and System p also is licensed by "power". I have a number of "surly sysprog" buttons. Basically anything that wakes me up at 2 am about a "problem" that is not mine and that I cannot fix. These are the same people who direct their "reports" to our JCL archiver instead of our report distribution system because it is just so much easier. That is, they don't have to put in a report archive defination request. <SNIP> It occurs to me that what you are describing is a lack of production control with departments that are held accountable for outages that they cause. If (and I'm not saying you don't) you have a regular production post mortem meeting (daily or weekly) to discuss what caused outages, and had various groups have to take responsibility for these, you might see a change. Particularly if there is an escalation policy that a manager of payroll, or accounting, or whatever is the one that has to make the call to a systems programmer. In a past life, a customer of mine did just this. And all the various parties responsible for different aspects of production had to show up (including non-mainframe). In this particular case (for them) we were cranking the screws to get the batch window cut in half. The answer "Well we just re-ran the job and that fixed it" was NOT accepted. Many times the Data Center Manager would turn to me and ask why I had been called or what I had observed (since we were installing PAVs and other things I was on hand at 2AM when things fell over). The point to this was, run-away spool users got their hands slapped publicly. Improperly tested and moved to production situations got VP visibility and stopped. And the non-mainframe groups had their feet held to the fire when they caused the "6AM Onlines Have to be LIVE" commandment to be broken. Perhaps you should take this kind of thing up with your management to handle these things a bit better -- after all, this costs the company real money. What we did in the above example cut loses by US$1M (what it cost to miss the 6AM Onlines Operational deadline by 15 minutes) a month (average number of misses was 1 per month, dropped it to 1 every 3-4 months). They also were able to drop a CPU from their z/800 (3 down to 2). Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- ---------------------------------------------------------------------- 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
