The promise of computers is efficiency. But as we are all too aware, glitches arise that can cause a lot of extra work on the part of IT technicians, and allow for very little workflow within a company. One IT professional has come up with a short set of parameters and tools that could save him a lot of time and headache, and make every IT tech's job a lot more enjoyable. If only software programmers would add these features with their next upgrade.
The "dammit" parameter
On a bad day, computer information control systems (CICS) misbehaves. But on a really bad day, it misbehaves and the problem won't go away even after repeated cancel commands. That's where the dammit parameter comes in: When CICS refuses to die, you could enter "C CICSPROD,DAMMIT" from the console and it would fix the problem.
The dammit parameter would also apply to other commands, such as PURGE, STOP, START, VARY (inactive or inactive) and SAVE. Really, dammit would be useful in any situation when the system seems unwilling to perform a reasonable request.
HIGHCPU = yes
Another bad day occurs when the capacity planning guy (CPG) shows up at your desk because the average CPU for your most heavily used transaction increased by 10 milliseconds last week. This relatively benign-sounding discovery often leads to hours of reading tapes, conducting traces and deep analysis accompanied by a chorus of application programmers claiming, "We didn't change a thing!"
Unfortunately, a lot of these searches come up empty. Instead of trying to explain the vagaries of multiprogramming and nondeterministic system performance to management, I would rather say, "We had the HIGHCPU parameter set to yes. We're going to set it to no at the next initial program load." Happy with this explanation, management would then ask to have proper controls put in place so the HIGHCPU parameter is never again set to yes. CPG goes back to his cube, and can look forward to a couple weeks of quiet until the average changes again.
Impending ABEND trap facility (IATF)
Many shops live with contradictory goals. On one hand, data centers want to conserve processors by turning off some debugging facilities (e.g., traces). However, management insists on meeting availability goals and never encountering the same problem twice. This conflict is realized when you have a serious outage and a software vendor tells you, "Gee, we could shoot this bug if only we had the trace."
This is where IATF could come to the rescue. IATF would detect impending problems five minutes before they happen and turn on all the needed diagnostic facilities. Five minutes after the ABEND, it would turn off diagnostics, compress debugging information and ship it off to the vendor. Version 2 should be able to recreate dumps suppressed by dump analysis and elimination (DAE).
An add-on product, the impending ABEND notification facility (IANF), would write actionable messages five minutes before any errors so automation and technical staff can avoid the outage. Unfortunately, this product would be pricey and require a private office for a staff astrologer.
Do what I meant (DWIM) command processor
I'm sure that I am not the only person who has entered what I thought was a safe command, only to find that I've caused problems through the law of unintended consequences. This happens when your brain is thinking one thing and you key it in, only to find that the system interprets it differently. However, with DWIM installed, your computer will read your mind and perform the action you intended instead of the carrying out your commands verbatim. There should be versions of DWIM on Windows, UNIX and TSO, each capable of preventing major damage.
A couple of add-on facilities round out the product suite:
- An option to be prompted before DWIM changes the command. The prompt will be helpful and context sensitive, using verbiage such as, "Do you really want to delete the payroll database (Y or N)." This add-on will also act as if you typed "N" even if you accidentally answered "Y" to the prompt.
- The production detection mechanism (PDM) will prevent commands that are meant for a test from actually executing in production. This product will come in handy on those long days when you're logged on to more than one system and can't keep track of your terminal sessions.
Change muddling system (CMS)
Every shop has a change management strategy to ensure modifications to the production system are planned, well executed and complete. Overall, these procedures are a good idea. But as most IT workers know, some changes are safe and simple enough that they can be done in one-tenth of the time it takes to complete the necessary paperwork and obtain permission. These changes are tempting for technicians, because the greater risk is not the change itself, but getting caught making an unauthorized modification.
CMS allows the systems programmer to (just this one time) slip a change into production undetected. However, as the contract for this software should read, the programmer assumes all responsibility for the change and its effects. If asked, CMS will deny ever knowing the change was made and claim it was actually out of town when it happened.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
