Robust REXX and Rules in OPS Telephone: USA (303) 652-3900Email: [email protected] ProTech: USA...
-
Upload
everett-fletcher -
Category
Documents
-
view
212 -
download
0
Transcript of Robust REXX and Rules in OPS Telephone: USA (303) 652-3900Email: [email protected] ProTech: USA...
Robust REXX and Rules in OPS Robust REXX and Rules in OPS
Telephone: USA (303) 652-3900 Email: [email protected]
ProTech: USA (412) 373-8855© Copyright 1998 Pelt Industries. All Rights Reserved.
Telephone: USA (303) 652-3900 Email: [email protected]
ProTech: USA (412) 373-8855© Copyright 1998 Pelt Industries. All Rights Reserved.
An independent consultant with ProTech Inc.ProTech Inc.An independent consultant with ProTech Inc.ProTech Inc.
Systems Automation Xchange - Sept. 24-25, 1998 Systems Automation Xchange - Sept. 24-25, 1998 Systems Automation Xchange - Sept. 24-25, 1998 Systems Automation Xchange - Sept. 24-25, 1998
Robust REXX and Rules in OPSRobust REXX and Rules in OPS
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.
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.
Markus PeltConsultantPelt Industries
Markus PeltConsultantPelt Industries
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 USAB.S. Mathematics - Virginia Commonwealth University, Richmond, VAM.S. Operations Research - Stanford, California
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 USAB.S. Mathematics - Virginia Commonwealth University, Richmond, VAM.S. Operations Research - Stanford, California
AgendaAgenda
What’s Robust ?
Why Robust ?
Characteristics of Robust Programs
The top 10 things you can do in your rules to make them more robust
What’s Robust ?
Why Robust ?
Characteristics of Robust Programs
The top 10 things you can do in your rules to make them more robust
What’s Robust ?What’s Robust ?
STRONGDoesn’t fall over easily
HARDYHandles all conditions
HEALTHYLow maintenance diet
VIGOROUSActively reports
problems
STRONGDoesn’t fall over easily
HARDYHandles all conditions
HEALTHYLow maintenance diet
VIGOROUSActively reports
problems
Why Robust ?Why Robust ?
Saves time–Maintenance time
–Rerun time
Saves money–Cost of system unavailability–Cost of YOUR unavailability
Saves face–The code keeps working
Saves time–Maintenance time
–Rerun time
Saves money–Cost of system unavailability–Cost of YOUR unavailability
Saves face–The code keeps working
Characteristics of Robust ProgramsCharacteristics of Robust Programs
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
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
The top 10 things you can do in your rules to make them more robust.
The top 10 things you can do in your rules to make them more robust.
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
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
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
How to avoid hard-codingHow to avoid hard-coding
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
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
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
How to handle message format changes
How to handle message format changes
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
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
Don’t die quietly !Report all detected message changes
Error reporting should not create a new problem
Consider impact of handling a message wrong
How to avoid timing dependenciesHow to avoid timing dependencies
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
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
How to avoid timing dependenciesHow to avoid timing dependencies
Be willing to go the depth
Do live testing under differing circumstances
Challenge assumptions(we’ve always done it that way)
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 Use SSM to define resource dependenciesresource dependencies
Check results of all Check results of all actions where possibleactions where possible
Don’t die quietly ! Don’t die quietly ! Report all errorsReport all errors
Last resort - retry several Last resort - retry several timestimes
Use SSM to define Use SSM to define resource dependenciesresource dependencies
Check results of all Check results of all actions where possibleactions where possible
Don’t die quietly ! Don’t die quietly ! Report all errorsReport all errors
Last resort - retry several Last resort - retry several timestimes
How to recover from unexpected conditionsHow to recover from unexpected conditions
You can’t check for specific unexpected conditions
You can check for expected conditions
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)
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)
Why adding comments doesn't waste time
Why adding comments doesn't waste time
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
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
Why adding comments doesn't waste time
Why adding comments doesn't waste time
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.
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.
What AOF TEST won't testWhat AOF TEST won't test
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
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
How to avoid Auto-Enable from killing your system
How to avoid Auto-Enable from killing your system
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
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
How to handle SQL errorsHow to handle SQL errors
SQL has many “gotchas”
Check for normal EOF first
Check RC & SQLcode return codes
Handle anticipated return codes
Use standard error check routine
SQL has many “gotchas”
Check for normal EOF first
Check RC & SQLcode return codes
Handle anticipated return codes
Use standard error check routine
How to handle SQL errorsHow to handle SQL errors
pgmname = “MYPROG” /* For error messages */
sqlcmd = “SELECT …” /* Setup SQL command */
address SQL sqlcmd /* Issue SQL command */sqlrc = RC /* Save return code */if SQLEOF(sqlrc,sqlcode,sqlcmd,pgmname) thendo
/* Handle EOF (no records found) */endelseif SQLERR(sqlrc,sqlcode,sqlcmd,pgmname,”LOG”) then
do/* Handle SQL error here */
end
pgmname = “MYPROG” /* For error messages */
sqlcmd = “SELECT …” /* Setup SQL command */
address SQL sqlcmd /* Issue SQL command */sqlrc = RC /* Save return code */if SQLEOF(sqlrc,sqlcode,sqlcmd,pgmname) thendo
/* Handle EOF (no records found) */endelseif SQLERR(sqlrc,sqlcode,sqlcmd,pgmname,”LOG”) then
do/* Handle SQL error here */
end
How to handle EPI errorsHow to handle EPI errors
Don’t assume session state
Check RC
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
How to handle EPI errorsHow to handle EPI errors
pgmname = “MYPROG” /* For error messages */
epicmd = “TYPE ...” /* Setup EPI command */
address EPI sqlcmd /* Issue EPI command */epirc = RC /* Save return code */if EPIERR(epirc,epicmd,pgmname,”LOG”) thendo
/* Handle EPI error here */end
pgmname = “MYPROG” /* For error messages */
epicmd = “TYPE ...” /* Setup EPI command */
address EPI sqlcmd /* Issue EPI command */epirc = RC /* Save return code */if EPIERR(epirc,epicmd,pgmname,”LOG”) thendo
/* Handle EPI error here */end
How to handle cross-system problems
How to handle cross-system problems
Problems:
MSF links down
Long delays
No responses
Problems:
MSF links down
Long delays
No responses
Solutions:
Automatic retry of link
Wait longer for response
Check return code
Reissue command (if possible)
Don’t assume other system alive
Use standard error check routine
Solutions:
Automatic retry of link
Wait longer for response
Check return code
Reissue command (if possible)
Don’t assume other system alive
Use standard error check routine
ConclusionConclusion
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
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
QUESTIONSQUESTIONS
Copyright 1994 Kokopelli AdventuresCopyright 1994 Kokopelli Adventures
NotesNotes