|
|
|
Telephone: USA (303) 652-3900 Email:
MarkPelt@peltind.com |
|
ProTech: USA (412) 373-8855 |
|
© Copyright 1998 Pelt Industries. All Rights
Reserved. |
|
|
|
|
Abstract: |
|
This session provides some suggestions on how to
make your automation programs and rules strong, hardy, healthy and vigorous. The top 10 things you can do
in your rules to make them more robust are discussed in detail. |
|
|
|
|
Biography: |
|
Markus Pelt has been a mainframe developer for
over 24 years. In 1985 he developed his first automation software package,
now sold by Candle Corp. as AF/Operator. He was one of the initial
developers of OPS/MVS in 1986, and wrote the original versions of MSF, AOF,
AOF TEST, EPI and the OPS/REXX interpreter. He has also been involved in
developing outboard console automation using Windows. Based in Boulder,
Colorado, Mark is currently an independent consultant specializing in
automation conversions, development and training. |
|
Education:
Schools in Holland, Belgium, France and the USA
B.S. Mathematics - Virginia Commonwealth University, Richmond, VA
M.S. Operations Research - Stanford, California |
|
|
|
|
What’s Robust ? |
|
Why Robust ? |
|
Characteristics of Robust Programs |
|
The top 10 things you can do in your rules to
make them more robust |
|
|
|
|
STRONG
Doesn’t fall over easily |
|
HARDY
Handles all conditions |
|
HEALTHY
Low maintenance diet |
|
VIGOROUS
Actively reports
problems |
|
|
|
|
|
Saves time |
|
Maintenance time |
|
Rerun time |
|
Saves money |
|
Cost of system unavailability |
|
Cost of YOUR unavailability |
|
Saves face |
|
The code keeps working |
|
|
|
|
|
Robust programs and rules |
|
Rely little on hard-coded values |
|
Use consistent and standardized routines |
|
Avoid duplicate code |
|
Make as few assumptions as possible |
|
Are well documented for other programmers |
|
Do not create more problems |
|
Require little human intervention |
|
|
|
|
1. How to avoid hard-coding |
|
2. How to handle message format changes |
|
3. How to avoid timing dependencies |
|
4. How to recover from unexpected conditions |
|
5. Why adding comments doesn't waste time |
|
6. What AOF TEST won't test |
|
7. How to avoid Auto-Enable killing your system |
|
8. How to handle SQL errors |
|
9. How to handle EPI errors |
|
10. How to handle cross-system problems |
|
|
|
|
To avoid hard-coding values: |
|
Separate the data from your programs and rules |
|
Check any number or string in your program or
rule as suspect |
|
If you must use them, put them in variables at
top of your program or rule |
|
Change your code to: |
|
Use global variables for multiple rules/programs
using same constants frequently |
|
Use tables for lists of constants |
|
Use self-initializing code |
|
Sanity check values |
|
|
|
|
To lessen impact of minor message format
changes: |
|
Don’t use word or column positions |
|
Avoid punctuation and capitalization assumption |
|
Parse for key phrases |
|
Include sample message in documentation |
|
Don’t die quietly !
Report all detected message changes |
|
Error reporting should not create a new problem |
|
Consider impact of handling a message wrong |
|
|
|
|
Timing dependency =
when event A must complete before event B starts |
|
Do not issue “blind” commands |
|
Actions do not always complete in the same time |
|
Cross-system commands may have long delays |
|
CICS WTOR problem |
|
No response versus partial response |
|
Absence of evidence is not evidence of absence |
|
|
|
|
Be willing to go the depth |
|
Do live testing under differing circumstances |
|
Challenge assumptions
(we’ve always
done it that way) |
|
Use SSM to define resource dependencies |
|
Check results of all actions where possible |
|
Don’t die quietly !
Report all errors |
|
Last resort - retry several times |
|
|
|
|
You can’t check for specific unexpected
conditions |
|
You can check for
expected conditions |
|
Document assumptions made by your programs |
|
Check your assumptions manually when writing |
|
Have code check them too when it’s running |
|
Provide feedback on any false assumption(s) |
|
|
|
|
|
|
|
Without comments your code is like |
|
interpreting smoke signals |
|
reading tea leaves |
|
tracking footprints |
|
gazing in a crystal ball |
|
looking at auras |
|
All possible but not easy |
|
|
|
|
|
A bug is a difference between what a program is
intended to do versus what the program actually is doing. |
|
The code defines what the program does. |
|
Comments define what the program was intended to
do. |
|
Without comments, no one except the original
programmer will know what’s a bug or the program’s purpose. |
|
One minute writing a comment, can save hours
reading and/or re-testing the code. |
|
|
|
|
|
AOF TEST can test your rules against sample
messages |
|
from you |
|
from OPSLOG |
|
|
|
AOF TEST won’t test: |
|
message format errors if you manually enter your
own |
|
the right message if you automate on the wrong
one |
|
messages too rare to capture in OPSLOG |
|
responses from dangerous “live” commands |
|
assumptions about the arrival order of messages |
|
|
|
|
|
|
|
|
A rule that is auto-enabled will
automatically activate on the next OPS startup |
|
If the rule causes a problem at IPL time, you
may actually prevent the system from ever coming up again ! |
|
If you write a rule and enable it “live” without
thorough testing,
you are playing with fire |
|
If you write a rule and auto-enable it without
thorough testing,
you are playing with your job |
|
Use AOF TEST |
|
|
|
|
|
|
|
|
SQL has many “gotchas” |
|
Check for normal EOF first |
|
Check RC & SQLcode return codes |
|
Handle anticipated return codes |
|
Use standard error check routine |
|
|
|
|
|
|
|
|
|
|
|
Don’t assume session state |
|
Check RC |
|
Handle anticipated return codes |
|
Use standard error check routine |
|
|
|
|
|
|
|
|
|
Problems: |
|
MSF links down |
|
Long delays |
|
No responses |
|
|
|
|
|
|
|
|
|
Coding robust rules and REXX |
|
Saves time |
|
Saves money |
|
Saves face |
|
Requires thinking ahead in terms of |
|
reliability |
|
maintainability |
|
the programmer who has to read your code |
|
|
|
|
|