Robust REXX and Rules in OPS Robust REXX and Rules in OPS

Telephone: USA (303) 652-3900 Email: MarkPelt@peltind.com

ProTech: USA (412) 373-8855© Copyright 1998 Pelt Industries. All Rights Reserved.

Telephone: USA (303) 652-3900 Email: MarkPelt@peltind.com

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