Académique Documents
Professionnel Documents
Culture Documents
Course Overview
Audience
This course is designed for application developers who have learned or
programmed in COBOL, and who need to do z/OS Traditional Development and
Maintenance as well as build leading-edge applications using COBOL and
Rational Developer for System z.
Prerequisites
This course assumes that the student has a basic understanding and knowledge
of software computing technologies, and general data processing terms,
concepts and vocabulary, as well as a working knowledge of COBOL and z/OS.
Knowledge of SQL (Structured Query Language) is assumed for database
access is assumed as well.
Basic PC and mouse-driven development skills, terms and concepts are also
assumed.
Course Topics
Course Name: Rational Developer for System z Foundation Training
Course Description: Learn how to use Rational Developer for System z to do z/OS traditional
development, maintenance, support and for Enterprise Modernization of z/OS applications
Pre-requisites: Some experience developing COBOL applications using z/OS is expected. A working
knowledge of SQL is also recommended.
Course Length: ~5days or if done in self-paced mode, at your own pace
Topics (Agenda)
Getting Started - installing and configuring RDz - and the course materials, and using Eclipse
The RDz Workbench
Code analysis tools
Editing
Compiling programs
Debugging local COBOL programs
The Data Perspective:
Working with relational data sources
Modifying test data
Editing and testing SQL statements
Working with remote system resources:
Connecting to a mainframe
Data management
Accessing and editing files
z/OS Application Development
Creating MVS Subprojects
Creating and customizing project properties
Debugging z/OS Applications
Debugging Batch Applications
Setting Debug Tool for Online Applications
Working with File Manager
Creating test data
Editing complex file-types
Working with mainframe ABENDs using Fault Analyzer
Creating Fault History views
Analyzing and solving mainframe ABENDs
Creating and modifying BMS Maps using the BMS Map Editor 5
UNIT
Unit objectives
After completing this unit on Production Support/Application Testing/Software Defect
and IBM Mainframe COBOL ABEND Research, you should be able to:
Define the steps in a generalized methodology of ABEND resolution
List the various sources of ABEND inputs, including:
PD Tools documents
Other sysout
Dynamic trace facilities
List the common types of COBOL program ABENDS
ABEND Overview
When an application ABEND (ABnormal END-of-job) occurs, z/OS stops executing
your program, closes files and buffers and generates a single high-level message in
the form of a System Completion Code (Sxxx).
The System Completion Code is usually written to an output listing file through
your //SYSOUT DD * JCL entry.
This completion code indicates why the system has decided to stop executing your
application.
It is related to, but often only loosely related to what is really wrong with your
application
Because of this the System Completion Code represents the starting point for your
analysis of the problem.
She won't be laughing
when she gets back to
her desk and finds out
that last night's
production jobs blew
sky high!
Debugging Assistance
Along with the System Completion Code, using IBMs Problem Determination tools (PD
Tools) Fault Analyzer you can obtain various reports which describe What/Where and
How the ABEND occurred.
Valuable information contained in the Fault Analyzer report-files includes:
The System Completion Code (and often a short text description of what it designates)
A short explanation of the cause of the ABEND
The COBOL instruction (statement) or line number, which contained the invalid operation causing
z/OS to halt execution
Variables of interest and code surrounding the instruction that halted execution
A "core-dump" (a hexadecimal printout) of the internal machine storage and registers relevant to
the areas of your program surrounding the COBOL instruction which caused z/OS to halt
execution.
This information is critical to begin understanding and researching the problem, but it is
sometimes insufficient to solve the underlying application problem, which could be any
combination of:
Getting Started
There are as many different ways to analyze and research COBOL ABENDs as there are
individual approaches to writing procedural logic. However, if you've never done
software production support work, consider starting with the following structured
problem-solving approach:
1.
2.
3.
4.
5.
Preparation
Research
Hypothesis
Solution
Resolution
As a final note before we begin discussing the above, understand that there are often two
distinct phases of application Production Support:
1. Data Center on-call ABEND resolution - wherein a technician receives notification that a job
or transaction has ABENDd and must be "fixed" within an extremely short timeframe (usually
minutes to hours). In this case, the technician's main concern is to "patch" the problem - get
the system back online, or get the batch job-stream back into production ("Patch-It").
2. NextDay problem resolution - wherein technician(s) actually track down and solve the
problem that caused the ABEND ("Fix-It").
The steps that follow represent a structured approach to "FixIt" in that they go well
beyond the scope of the emergency measures used to "patch" the problem during
an OnCall emergency.
10
JCL
Program source
All copybooks (or
expanded source
listings)
11
Learn the nature of the batch job from system documentation, or from an application business
expert (at least at the level of module-flow and file-access)
12
From the preparation step, construct a mental map (understanding) of the program's
execution (HOW the ABEND occurred - which will start you down the path of research
to understand "WHY" the ABEND occurred
WHY determination usually requires a combination of "Static" and "Dynamic" analysis complementary research and investigative approaches.
These steps need not be followed in this order. Rather, in time you will develop an
"intuition" as to which kind(s) of analysis will be most likely to provide the information
you need to solve your problem.
To assist, you can use application research and analysis tools such as
Static Analysis
So if the reason "why" the ABEND occurred is not apparent at this point, perform
Static and/or Dynamic Analysis on the specific areas of the application relating to the
ABEND.
Note: Recompiling old COB2 programs with Enterprise COBOL can create many of these
problems, even though "Nothing has changed in the program"
13
Structural Visualization can done be "top-down", by asking open-ended questions; such as learning how a
particular routine "hangs-together logically", or it can be used "bottom-up", by asking specific close-ended
questions about a program, such as "How does this particular paragraph get executed?" "How did this module
get invoked?"
2. Data Flow Analysis: A combination of control structure analysis and data item analysis, which seeks to
determine the usage of particular fields throughout a program. Data flow analysis is used to determine (from a
given instance of a data item) where the next occurrences of that item exist in your program, and how the data
item is used; (as a receiving field in a MOVE or mathematical operation, as the sending field in a MOVE
statement, as part of a logic-branch (IF, PERFORM UNTIL/VARYING, etc.).
3. Data Impact Analysis: An expansion of Data Flow Analysis which traces the movement of data from field-tofield throughout a program, or throughout an entire application; including I/O (screens and files). Using Data
Impact Analysis, you can identify all fields that might have had an impact on the contents of a field (before the
ABEND occurred). And just as importantly - you can learn the affect changing this field will have on the behavior
of the application.
4. Textual or Data Item Usage: Utilized more for application maintenance and enhancement requests, this type of
Static Analysis involves searching for "categories" of program-items, such as "List all fields that contain *JUL*,
*GREG*, *YR*, *YEAR* (suspect date candidates for Year2000 conversion), or list all such fields with two digits
(numeric) or two-byte (alphanumeric) definitions.
5. Code Partitioning: Again, utilized more for application maintenance, enhancements and application
reengineering, Code Partitioning involves mentally organizing and analyzing code by function or process, such
that you understand and can distinguish the usage of code by business process. For example: Find all code
that relates to the calculation of premium renewal payments or Isolate the code that edits a particular file,
with an eye towards creating a shared subroutine from the code.
14
15
16
Or what if - in the case of the file containing blanks in the numeric fields - the input file was supposed to
be "clean" (validated) by this point in the job-stream - having gone through allegedly "exhaustive" edits
in prior modules.
By simply adding an IF test you may solve your program's specific ABEND, but you will not have resolved
the actual problem - which exists somewhere else in the system.
In other words, localized/piecemeal approaches to resolving production ABENDs are not recommended - as
they usually change the problem, instead of solving it. And sometimes they just spawn new problems.
17
Note that, in addition to an understanding of the reason for the ABEND, the
results of your investigation should produce an understanding of the
solution to the problem (the fix itself).
18
19
Resolution
Batch
Job
http://en.wikipedia.org/wiki/IBM_Rational_ClearCase
20
Unit objectives
After having completed this unit on Production Support/Application Testing/Software
Defect and IBM Mainframe COBOL ABEND Research, you should now be able to:
Define the steps in a generalized methodology of ABEND resolution
List the various sources of ABEND inputs, including:
PD Tools documents
Fault Analyzer reports
Other SYSOUT
Static analysis
Dynamic trace facilities
List the common types of COBOL program ABENDS
21
UNIT
22
23
24
Instructions:
OPEN, CLOSE, READ, WRITE
Frequent Coding Causes:
Most of these ABENDs occur running und z/OS (some may not even occur under z/OS, although older modules running
OSVS or VS COBOL II code that have not been recompiled can produce them).
Most are due JCL/COBOL
FD inconsistencies.
Tools to debug:
Static
S013-18: Open multiple windows on RAA Batch Job Diagram and program Environment Division - SELECT
ASSIGN.
25
27
28
Dynamic
Run through to the S0CB
Locate to field definitions of the offending fields
Solution:
Add edit to check for zero divide:
IF divisor > ZERO
THEN
COMPUTE ...
ELSE
PERFORM error-processing routine
Tools to debug:
Static
RAA screens on logic in PERFORM chain
RAA Display Perform Thru
Dynamic
PD Tools (mainframe) Debug to S222
Analyze counts (color)
Query and Monitor on subscript
Set an Advanced Break Point - Conditional on count
Solution:
From within Debug, use RAAi to identify logic which could cause looping.
Select and click on PERFORM THRU, PERFORM UNTIL, GO TO.
Place break points on potential error lines.
30
Tools to debug:
Static
Do RSE search on module name.
Dynamic
Set Program Advanced Break Point (Entry) to set program break before entry to system.
Solution:
Spell name correctly
31
Instructions:
WRITE
Frequent Coding Causes:
- Not enough space initially allocated to output file(s).
- (more likely) Logic error - program in (infinite) loop writing output file(s) - see S222/S322 reasons.
Tools to debug:
Static - if (unlikely as this may be) you're debugging locally (on your Workstation) you can find the out-of-space file and statistics on it as follows:.
Do directory list on the file you are writing to:
Go to DOS Window
Type "DIR fname.ext"
On the host the JCL will show the DDNAME and z/OS filespec of the dataset in question
Dynamic
Set an advanced conditional break point to break on a certain number on iterations
See S222/S322 reasons and solutions
Also, set break point on file WRITE statements
Note: If not logic error and actually have full disk, you may have to clean up your disk and erase files:
32
Database Abends
DB2 application access rarely abends, they "die gracefully" due to return code processing.
DB2:
SQLCODE
A large 01 block, which contains several other fields pertinent to debugging, particularly the
SQLWARNs.
Suggestion:
Set Line Breakpoint and/or Variable Monitor on SQLCODE and other key feedback areas
- or Set Line Breakpoint and Watch Monitor for /"On-Change Break"
Double-click on field, Ctrl/F3
Notes on UDB Offloading and Database Abends
UDB handles SQLCODE processing in a manner consistent with DB2. However, it should be noted
that UDB does not handle SQLWARNO-n and the SQLCA (SQLERRD, etc.) fields compatibly.
DB2 ABENDs
If DB2 tables have not been defined, you may get a -204 return code on your SQL statement.
UDB may allow you to fix Database errors dynamically, without completely stopping your animator session:
33
UNIT
34
Topic Considerations
Note: In this topic you will learn how to use Fault Analyzer to
debug an ABEND. The screen captures all describe connecting to a public z/OS
machine that IBM makes available during classes.
If you are taking this course through standard IBM services delivery you should
be able to use the properties (I/P address, port#s, etc.), logon IDs and passwords
that your instructor provides you with.
But you may also be taking this course standalone and in that case, you will
need to speak to your company's Systems Programming staff to learn how to
connect and logon.
It goes without saying that the actual file names in the screen captures of
mainframe libraries and datasets will vary. So you should focus on the process
and steps and "how to" and don't be perplexed at differences in screen
captures.
You also may be using your company's own Source Control Management system
to do things like builds, compiles, etc. In that case much of the remote
functionality in RDz will be customized and tailored to your company's unique and
idiosyncratic procedures and protocols.
35
Unit objectives
After completing this unit, you should be able to:
Work with ABEND analysis reports created by IBM Fault Analyzer
Browse Report and Mini-Dump pages
Retrieve various Fault Analyzer view information
Browse and search ABEND codes
Use the various productivity features in the Fault Analyzer perspective
Note:
This presentation and Lab is not a comprehensive IBM Fault
Analyzer unit. It is only intended to introduce you to the
RDz/Fault Analyzer interface. It is assumed that you are already
working with IBM Fault Analyzer on the z/OS host.
36
Face facts:
ABEND research ("shooting a dumps") is not
how you want to spend your week-nights
The good news? You don't have to.
Fault Analyzer:
Identifies the line where execution halted
Shows the points-of-interest surrounding the ABEND:
Variables and variable values
Statements
Data and buffers
Gives you a serious head start on the What/Where and How of ABEND
debugging
37
IBM Fault Analyzer is a tool that helps you determine the cause of an application
ABEND. It is used to determine:
What happened, how it happened, what program, what line/statement,
which variables,
variables what files, were involved, etc.
Fault Analyzer provides the necessary information to perform root cause analysis
on an application ABEND.
You do not have to interpret low-level, system dumps and wade through HEX data.
Information is presented in report format
IBM Fault Analyzer for z/OS gathers information about an application and the
surrounding environment at the time of an abnormal end (ABEND), providing you
with the valuable information you need to work through
After analyzing information about your application and its environment, Fault
Analyzer generates an analysis report (IDIREPORT)
IDIREPORT that describes the problem in
terms of application/program statements and variables
38
http://www-01.ibm.com/software/awdtools/faultanalyzer/
39
***See Notes
ABEND happens
Fault Analyzer exits are invoked
Salient details (points of interest)
written and stored
40
41
43
FAULTANL.V10R1.HIST
44
Fault
FaultAnalyzer
Analyzer
Explorer
Explorer
IDIREPORT
IDIREPORT
Available
Availableinin
Outline
Outlineview
view
Can
Cannavigate
navigate
using
usingthe
the
Outline
Outlineview
view
Additional
AdditionalFault
FaultAnalyzer
Analyzer
views
viewsexist
existfor
forother
other
ABEND
ABENDdocumentation
documentation
including
includinghistory
historydata
data
45
Can also work with options of the Context Menu with each ABEND
entry
46
Click
ClickS0CB
S0CBfor
for
an
explanation
an explanation
ofofthis
thisABEND
ABEND
47
file/FD/JCL DD
connection"
48
Note:
CUST-ACCT-BALANCE's
value is shown in hex (as it
represents invalid data)
49
50
51
52
Fault Analyzer Lookup View for MVS and File Return Codes
The Lookup view
shows a great
deal of
background
information on:
ABEND codes
DB2 SQLCODE
IMS PCB Feedback
VSAM File Status
etc.
53
Select
Selectan
an
ABEND
ABEND
Scroll
Scrollthrough
throughthe
thedump
dump
Issue
Issuenavigation
navigationcommands:
commands:
Show
Shownnn,
nnn,+nn,
+nn,etc.
etc.
54
2
56
The
TheDefault
Defaultview
viewshows
showseither:
either:
AAHistory
HistoryFile
File
AAview
viewof
ofaaHistory
Historyfile
file
57
Available
Available
Line
Line
Commands
Commands
AAlist
listof
ofHistory
HistoryABENDs
ABENDs
Batch
Batchand/or
and/orOnline
Onlinemay
maybe
beininthe
thesame
samelist
list
58
Checkpoint
1. What RDz Perspective is used to view Fault
Analyzer reports?
2. How does RDz obtain Fault Analyzer Information?
Where does the information originate?
3. RDz Fault Analyzer interface has a Lookup View.
What is it used for?
4. How can you jump to the program statement
where the ABEND occurred with the RDz Fault
Analyzer interface?
59
Summary
Having completed this unit, you should now be able to:
Work with ABEND analysis reports created by IBM Fault Analyzer
Browse Report and Mini-Dump pages
Retrieve various Fault Analyzer view information
Browse and search ABEND codes
Use the various productivity features in the Fault Analyzer perspective
60
2.
Modify JCL dataset names (and high-level qualifiers) to match your Sandbox ID
3.
4.
Run HOSPCALC (it will ABEND) and from the Fault Analyzer IDIREPORT:
Find the error in the COBOL source, and use the IDIREPORT ABEND analysis data to fix the error
After you've solved the problem, you will save your edits, and re-compile HOSPCALC. Then run the
program until you either get the next ABEND or get a zero return code
Compile
Compile
Link
LinkEdit
Edit
HOSPCALC
Load Module
2.
3.
62
Workshop Steps 2 of 2
4. Expand the EM4zxx.POT.JCL library:
Edit HOSPCALC.
with
<yourEM4Zxx>
Edit HOSPCRUN.
<yourEM4Zxx>.POT
5. Submit your modified HOSPCALC JCL. When the job finishes, check the results in your JES My Jobs
filter (it should compile successfully but check that the LKED step ran)
6. Submit your modified HOSPCRUN JCL. The job should ABEND. In JES - My Jobs,
Jobs view the IDIREPRT
step, to see the specific system completion code and surrounding Fault Analyzer ABEND analysis
information
Note that HOSPCALC contains four separate ABEND errors that you will hit, one at a time: an 0C7, an 0CB, an 0C4 and a
combined 0C7/0C4 ABEND (Sounds strange ... Essentially Fault Analyzer will find two different problems on one statement)
The comments and descriptions in the IDIREPRT combined with your COBOL knowledge should be sufficient to debug and
fix these problems, but feel free to elicit help from your instructor if you're stuck.
7. Fix the COBOL error that caused the ABEND. Then repeat steps 5 and 6 until you find and fix all of the
ABENDs in HOSPCALC. You're done when HOSPCRUN finishes with a zero return code.
63