DB2 Cursors

DB2 CURSORS

Using CURSORs in the COBOL programs.
In the part 1, we have seen how to access data using singleton select statement. using singleton select we can only select one record from the table. When there is a situation, like.. program needs to get all data in EMPLOYEE table and print all
employee names and their respective salaries. With singleton select statement (refer part1) it is not possible.

Using CURSORs we can get all records in the table.

Let us see step by step how we can do this in a cobol program.

TASK : Get all records from EMPLOYEE table and display EMPNAME and SALARY in the spool

STEP 1. DECLARE cursor in WORKING-STORAGE SECTION.

EXEC SQL
DECLARE EMPCUR CURSOR FOR
SELECT EMPNAME, SALARY
FROM EMPLOYEE
END-EXEC.

STEP 2. Open the cursor in PROCEDURE division.

EXEC SQL

OPEN EMPCUR

END-EXEC.

At this time, sql specified in the step1 executes and cursor is ready with data.

STEP 3. Get data from cursor record by record.

Following code should be in a loop till we get SQLCODE = 100. Let us assume there are 5 records in EMPLOYEE table, every time when you execute this code, we will get a record. 6th time when we execute the code we will get SQLCODE = 100, we can end the loop.


fetching/retrieving data from cursor.

EXEC SQL
FETCH EMPCUR
INTO :HV-EMPNAME,
:HV-SALARY
END-EXEC.

EVALUATE SQLCODE
WHEN 0

DISPLAY ' -----------------'
DISPLAY ' Employee name ' HV-EMPNAME
DISPLAY ' Employee salary ' HV-SALARY
DISPLAY ' -----------------'

WHEN 100

MOVE 'Y' TO END-OF-LOOP

WHEN OTHER

DISPLAY ' ERROR IN RETRIEVING THE DATA FROM EMPLOYEE TABLE'
DISPLAY 'SQLCODE : ' SQLCODE

END-EVALUATE.



TIP : SQLCODE = 100 is end of the cursor, in case of cursors.
SQLCODE = 100 is record not found in case of singleton select



STEP 4. Once retrieving records from table completed, we need to
close the cursor using following command.

EXEC SQL
CLOSE CURSOR
END-EXEC.



Other info about cursors....

Your program can have several cursors. Each cursor requires its own:
DECLARE CURSOR statement to define the cursor
OPEN and CLOSE statements to open and close the cursor
FETCH tatement to retrieve rows from the cursor's result table.

You can use cursors to fetch, update, or delete a row of a table,
but you cannot use them to insert a row into a table.

Impact of ENDEVOR on SDLC

ENDEVOR
ENDEVOR is an integrated set of management tools used to automate, control, and monitor your applications development process. ENDEVOR runs under MVS, within the TSO/ISPF environment, and in batch.

Using ENDEVOR, you can:
· Track your changes against production, creating an online change history, enabling you to know what was changed, by whom, when, and why.
· Prevent conflicting changes to the same system component.
· Browse and manipulate all components relating to an application from a
· a single screen, saving you time.
· Automate executables creation.
· Ensure that the source, executable, and any other form
· (for example, listings) of an element correspond.
· Apply the same procedures (including automating compiles, impact
· Analyses, and standards checking functions) to any component type.
· Put change packages and approvals online, eliminating paperwork.
· View or retrieve prior levels of any element.
· Report on element definition, content, and change history.
· Enforce change control procedures.

Software Life Cycle :

ENDEVOR allows you to automate and control the movement of software through your software life cycle. Life cycles are site-specific. A representative life cycle might consist of five stages:
* DEVELOPMENT - Programs are developed.
* TEST - Programs are unit tested.
* QA - Applications are system tested.
* EMERGENCY - Fixes are applied to production code.
* PROD - Production applications reside.
The ENDEVOR administrator might decide to put the TEST, QA, EMERGENCY and PROD stages under the control of ENDEVOR.
Basic :
Normal change procedures include:
* Retrieving from production to a development library.
* Making changes.
* Adding/updating into the test stage.
* Moving to QA.
* Moving back into Production.
<------------- retrieve -----------------------------------
******** ******** ******** *******
* TEST * * QA * * EMER * * PROD *
* * * * * * * *
****** ****** ******** *******
$$$$$$$
$ dev $ - move --> -------- move -------------->
$ --add->
$$$$$$$$

Emergency : Emergency change procedures include:

* Retrieving from production.
* Making changes.
* Adding/updating into the emergency stage.
* Moving to Production.
---- move ------->
******** ******** ******* *******
* TEST * * QA * * EMER * * PROD *
* * * * * * * *
******** ******** ******* *******
add $$$$$$$ retrieve
$ dev $
<----- <----
$$$$$$$$

Inventory Structure :

The ENDEVOR inventory structure allows you to:
· Work with program modules without having to know where they are physically located, or how they are compiled.
· List all the program components that make up an application, regardless of type.
· Determine the location(s) of an element simply by entering the element name on a display screen.
· Act on a cross section of your program inventory.
· For example,
you can list all COBOL code in your shop, or promote an entire new release of the payroll application with a single command.
ENDEVOR can produce lists, for example, of:
* All the JCL in the shop
* All the software currently in QA
* All the manufacturing software currently being unit tested
There are many other ways to use this structure to your advantage.
Job Function
*---------------------------------------------------*
Action Dev QA/Test Turnover Audit Mgmnt Admin
*----------------------------------------------------------------
Add/Update x x x
Archive x
Copy x
Delete x x
Display x x x x x x
Generate x
List x x
Move x x x x
Print x x x x x x
Restore x
Retrieve x x x
Signin x x x
Transfer x x
*-------------*---------------------------------------------------*
ENDEVOR helps to manage the software life cycle by providing a
consistent and flexible logical structure for classifying
software inventory.

There are six components to this inventory structure: environments, stages, systems, subsystems, types, and elements.

Environments, stages, systems, subsystems, and types are set up by the ENDEVOR administrator. The actual inventory is made up of elements. Users act on elements.

1 - Environments 5 - Types
2 - Stages 6 - Elements
3 - Systems 7 - Using the inventory structure
4 - Subsystems 8 - The software life cycle

Environment :

Environment is the ENDEVOR term for the functional areas of an organization. For example, there might be separate development and production environments.
There is no limit to the number of environments that may be defined. Environments are defined in the C1DEFLTS table. Environment information can be viewed on the Site/Environment Information panel.

Stage :

Stage is the ENDEVOR term for a stage in the software life cycle. For example, a site may have stages TEST, QA, FIX, and PROD in its life cycle There must be two stages for each environment.
Stages have a name, representing their place in the life cycle (for example TEST) and an ID (1 or 2). Stages are referred to as Stage 1 (the first stage in an environment) and Stage 2 (the second stage in an environment).
Stages are defined in the C1DEFLTS table. Stage information is displayed on the Stage Information panel.
Stages can be linked together to establish unique promotion routes for program inventory within and between environments. These routes make up the map for a site.
1 - Stage information panel 2 - Mapping
Current env - Name of the environment for which stage information is shown.
Next env - The name of the next environment on the map.
Stage ID - ID of the first Stage in the next environment.
Stage 1 and 2 Information.

ID - Stage ID.
Name - Stage name.
Title - Stage description.
MCF data set name - Data set name of the Master Control File for the Stage.

Part of implementing ENDEVOR is to define the stages in the software life cycles at your site, then organize these stages into environments. See Chapter 1 of the Administrator's Guide.

Applications in each life cycle follow a unique route through the environment/stage locations that you have defined. You can set up as many routes as you need to accommodate different life cycles at your site. These routes make up the map for your site.

ENDEVOR uses these routes to automate the adding, displaying, retrieving, moving, and generating of inventory in a given life cycle.
1 - One route map - example 5 - The map and actions
2 - Two route map - example 6 - The map and lists
3 - Establishing routes 7 - The map and signout
4 - Mapping inventory locations 8 - Implementation checklist

1 - One route map - example
In its simplest form, a series of environment/stage locations can be
chained together to form a one-route map.

***************** ***************** *****************
* DEV * * QA * * PROD *
***************** ***************** *****************
* UNIT * INT * * QA * HOLD * * FIX * PROD *
* * * * * * * * *
* -----> -----------> -----> ----------------------> *
* * * * * * * * *
***************** ***************** *****************

2 - Two route map - example

Route R1 (DEV, QA, and PROD) for production applications.
Route R2 (QFIX, PROD) to handle emergency fixes to the applications.

***************** ***************** *****************
* DEV * * QA * * PROD *
***************** ***************** *****************
* UNIT * INT * * QA * HOLD * * FIX * PROD *
* * * * * * * * *
R1 * -----> -----------> -----> --------------------> , *
***************** ***************** ****************

********************
* QFIX *
********************
* TSTFIX * PREPROD *
R2 * -----> ------------
********************
System :
System is the ENDEVOR term for the applications at a site. For example, a site might have financial (system: FINANCE) and manufacturing (system: MFG) systems.
A system must be defined to each environment where it will be used. You work with systems using the System Definition panel. You can clone system definitions within or across environments using the
System Definition - Clone panel.

1 - System definition panel 2 - System definition – clone

Subsystem is the ENDEVOR term for a particular application within a system. For example, there might be purchase order (subsystem: PO) accounts payable (subsystem: AP) applications within system FINANCE.
* There must be at least one subsystem per system.
* A subsystem must be defined to each system in which it will be used.
For example, if you plan to have subsystem PO within system FINANCE, and define system FINANCE to environments TEST, QA, and PROD, you must also define subsystem PO to system FINANCE in each environment.
* A subsystem can have the same name as the system to which you
define it.

Subsystem :

You work with subsystems using the Subsystem Definition panel. Type is the ENDEVOR term for categories of source code. For example, you might create the following types: COBOL (for COBOL code);
COPYBOOK (for copybooks); JCL(for JCL streams). You must define a type to each stage in which you want to use it.

Processors :
ENDEVOR uses JCL streams called processors to automate creating executables. You can associate a group of processors with each type. Each processor group includes the processors needed for a particular type of source. For example, the processor group for type COBOL might include processors for VS COBOL and COBOL II.
You work with types on the Type Definition panel.
Naming Conventions :
Consider using generic type names, such as COBOL. You can then create as many processor groups as you need to handle the variations within each type. For instance, for type COBOL, you could create processor groups to tell ENDEVOR what type of COBOL must be processed.
A list of suggested naming standards for types follows. This list is not complete and is presented here as a guideline only.

ASEMBLER LINKCARD SORTCNTL FORTRAN
BASIC MACRO SPECS RPG
CLIST MARKV TABLES JCL
COBOL NETRON TELON REPORTS
COPYBOOK PLI TRNSFORM
EASYTRE VPROC UTILITY

Element is the term for PDS members, Panvalet or Librarian, or
sequential data sets that have been placed under control of ENDEVOR.
The element name defaults to the member name.

ENDEVOR classifies elements according to the inventory structure you
set up. Each element is described uniquely in terms of its:

* Location in the software life cycle. This is determined by the environment and stage where it resides.
* Inventory classification. This is determined by the system, subsystem, and type with which it is associated.

Working With Elements

You manipulate ENDEVOR inventory by executing commands called actions.
Some actions are available in both foreground and in batch, while
others are available only in batch.. Batch actions are also available
when you build packages.
* The ENDEVOR/MVS User's Guide explains how to execute actions in
foreground and submit batch action requests.
* The ENDEVOR/MVS SCL Reference Manual contains the syntax for
ENDEVOR's Software Control Language (SCL). SCL allows you to code
batch action requests.

Signout/signin :
Signout/signin can be enabled on a system by system basis.

Action Impact on element Options
Add/Update Signs out Override signout
Move Signs in at target Retain signout, Signout to
Retrieve Signs out Override signout, No Signout
Generate No change Override signout
(no copyback)
Generate Signs out copied Override signout
(copyback) back element
Transfer Signs in at target Override signout, Retain signout
Signout to
Archive No change Override signout
Restore Signs in at target Override signout
Signin Signs in Override signout, Signout to
Copy No change Override signout
Delete No change Override signout

Package :
A package is a set of ENDEVOR actions that may require approval before being executed. You create a package by building batch SCL streams containing the actions to be executed.

1 - Creating packages 5 - Committing packages
2 - Casting packages 6 - Package Backout
3 - Reviewing packages 7 - Package shipment
4 - Executing packages 8 - Package action/status summary

Creating a package involves:
* Identifying the elements to be included in the package.
* Building a file of actions to be performed against the elements.
* Identifying the package as standard or emergency.
* Specifying dates between which the package must be executed.
You can also create a package by reusing an existing package. After creation, a package has a status of in-edit. You can modify a package as long as it has a status of in-edit.

Casting a package :
Casting a package prepares the package for review and subsequent execution. When you cast a package, ENDEVOR:

* Determines whether approvers have been assigned to the inventory area(s) included in the package.
* Makes sure that any approvers have authority to perform the package actions against the package inventory areas.
* Checks the integrity of the package components.
* Makes sure that the package contains the most recent versions of all components.

A package cannot be edited once it is cast.

1 - Determining approvers 3 - Security checking
2 - Component validation 4 - Integrity checking

The first step in casting a package is to determine if approvers are associated with the inventory areas referenced in the package.

Action Inventory Area
Add/Update Target
Restore Target
Generate:
With COPYBACK Target
Without COPYBACK Source
Move Target
Delete Source
Signin Source
Transfer:
With DELETE Source and Target
Without DELETE Target
Archive:
With DELETE Source

If component validation is active, ENDEVOR examines the component list associated with each element specified in a Move action. ENDEVOR does not allow a package to be cast if any components
* Reside at the same stage as the source of the Move action and have not been included in the package. In this case, ENDEVOR appends commented Move SCL for the omitted input component.
* Are missing or have been modified (the time stamp in the component list footprint does not correspond to either the Generate or Move time stamp in the MCF) since the element was generated. ENDEVOR issues error messages about this condition.
When a cast fails for either of these reasons, review the package and do one of the following:
* Generate the element to pick up the latest version of a component.
* Cast the package without validation (if allowed).
* Cancel the package if a component has been deleted.
For more information, see Chapter 7 of the User's Guide.

The ENDEVOR C1DEFLTS Table contains a flag*PKGCSEC*that indicates whether action s should be checked at package cast time, to determine whether the person casting the package has the authority to perform all actions contained in that package.
If PKGCSEC=Y, ENDEVOR checks each action in the package. If the person is not authorized to perform all actions, he/she cannot cast the package. If PKGCSEC=N, ENDEVOR does not check action security.


After the package is cast, it contains either a copy of the footprint of the source element or a checksum value for source members from an external data set.
Before executing the package, ENDEVOR compares this footprint or checksum value with the values stored in the package. If any differences exist at that time, the package is not executed.

A package must be reviewed if one or more approver groups are associated with the inventory area(s) included in the package. Once a package is in the review phase, only designated approvers can access the package and review its contents.

Reviewing Packages :

To be approved, a package must:
* Receive approval from at least the required approvers.
* Receive approval from a quorum of approvers.
* Not be denied approval by any approvers

Example: The approver group PKGQA consists of three approvers. The
approver group was established with a quorum size of 2, with one approver required. This means that in addition to the required approver, one of the two remaining members of the approver group
must approve the package in order for it to be executed.

Executing Packages
The package can be either executed online or submitted in batch. The user performing the execution must be an approver and must have the authority to perform the actions contained in the pac kage.

The outputs of packages that have been executed can be backed out, backed in, or shipped to remote locations.

Committing Packages
Package processing provides you with the ability to backout and and subsequently backin, change packages. The backout/backin option is available only after you have executed a package. All package event information, as well as backout/backin data, is maintained with the package until you commit the package.

Committing a package removes any backout/backin data while retaining package event information. A package should be committed only when you are sure that you will no longer need to back it in.

Package Backout

Should you discover a problem once you have executed the package, or if the execution failed, you can back out the package. You can also reinstate backed out packages, using the back in option.
When you back out a package, you must use the BSTCOPY utility, not IEBCOPY. BSTCOPY is discussed in Chapter 5 of the Administrator's Guide.

Note: Package backout deals with ENDEVOR output libraries, not base and delta libraries. If reverse or image delta format is being used, the base library member will not be backed out.

Why backout does not affect source
Package backout is designed to restore load modules and other executables to their pre-package execution state. Backout does not restore the source to its previous image, because the "bad" source is the audit trail of the change. This audit trail should not be disrupted for any reason, because it allows you to view change history and changes only online, facilitating problem resolution.

ENDEVOR "knows" that the executables have been backed out even if the source isn't, by flagging the element in the MCF. ENDEVOR warns users who subsequently attempt to retrieve the backed out element that they are working with a backed out copy.

Note: If you want to restore the prior level of source, you can do so online using the Summary of Levels panel on the Retrieve action. The prior level of source, after retrieval, can then be added back into ENDEVOR, creating a new change level and preserving the audit trail
of the bad change.

Backout and package dependencies
As with package commitment, package backout and backin takes into
consideration dependencies between packages.

Assume you execute package PKG1, containing elements COPYA, COPYB,
COPYC, and COPYF. You then execute package PKG2, also containing
element COPYF, as well as COPYD and COPYE.

You then decide to back out PKG1. Because the execution of PKG2 has
affected element COPYF, which is in both packages, you must back out
PKG2 first. Otherwise, COPYF will not be returned to its original,
pre-execution state.

The package shipment utility uses data transmission programs to
distribute package outputs (source, object, listing, or load modules),
or package backout members from a host site to another site. It is
designed for users who develop software at a central site and want to
transmit source, object, or executable code either locally or to other
(remote) sites.

Package Shipment:
To use the package shipment utility:
* Packages must be created with BACKOUT ENABLED=Y.
* Packages must have been executed, but not committed
* One of these data transmission packages must be available
- XCOM 6.2 (CAI)
- Bulk Data Transfer (IBM) Version 2, or via NJE/NJI
- NetView File Transfer Program Version 1 (IBM)
- Network DataMover (Sterling Software)
* Remote destinations must be defined











Package Action/Status Summary
If You Do This This Status Changes To Next Action Is
Create package None In-edit Modify or cast
Modify package In-edit In-edit Cast
Cast package
Approval In-edit In-approval Review
No Approval In-edit Approved Execute
Unsuccessful In-edit In-edit Correct and re-Cast
Review package
Approved In-approval Approved Execute
Denied In-approval Denied Reset and correct
Execute package
During execution Approved In-execution
Successful In-execution Executed Backout, Backin, Ship
Unsuccessful In-execution Exec-failed correct and re-execute
Commit package Executed Committed
Backout package Executed Executed Backin, Ship
Backin package Executed Executed Backout, Ship
Ship package Executed Executed Backout, Backin, Commit


This document lists the new features and enhancements available in
Release 3.9 of Endevor for OS/390. Select 1 - 10 for information about
the following topics:

1 - Element Locking for Packages
2 - ESORT Command for Sorting ISPF Selection Lists
3 - Full-Image Delta Format
4 - GENERATE-IN-PLACE Quick-Edit Option
5 - Monocase Text Search Option
6 - Prompt for Package ID or Element Name if Omitted Option
7 - Endevor API capability to Perform Element Actions
8 - OS/390 SYSPLEX VSAM Record Level Sharing (RLS)
9 - Endevor for OS/390 Agent Technology
10 - Documentation enhancements

XPEDITER Testing tool

Testing tool that simplifies the task of identifying problems,
applying solutions, and analyzing changes



This Document is intend to teach how we can debug a program in Xpediter.
If you got any problems while trying this, contact me. At ***EMail ID REMOVED... Read Forum Rules***

Software : XPEDITER
VERSION : 7.0
PROGRAM TYPE : BMP (BATCH PROGRAM)


Before going to debug a program, Let us assume following things

Step1 : Write a Simple Cobol Program.
Step2 : Stage it in CHANGE MAN , make sure its status is ACTIVE
(While compiling select the XPEDITER option to 'Y')

If You does not have CHANGE MAN
Include following steps in the compilation JCL, for getting the DDIO files,
Add these steps before link edit steps.

//XOPTIONS DD DISP=SHR,DSN=XT.XT64B1.XOPTIONS
//CWPDDIO DD DISP=SHR,DSN=FLGFGR1.COBOL.DDIO
//CWPPRMO DD *
COBOL(OUTPUT(PRINT,DDIO))
PROCESSOR(OUTPUT(NOPRINT,NODDIO),TEXT(NONE))
LANGUAGE(VSCOBOL)
DDIO(OUTPUT(NOLIST,NOXREF,FIND,NODMAP,NOOFFSET,COMPRESS))
//*


Step3: Write an JCL which runs the COBOL Program.


Assumptions :
PROGRAM NAME : STRING1
CHANGE MAN PACKAGE NAME : ABC1002519
LOAD MODULE : SSSK.ER000000.ABC1.#002519.BLM





Now we can debug the program in XPEDITER

Enter 'XP' on command line in ISPF panel.

Then, the following screen will be displayed

--------------------------------------------------------------------------------



---------------------- XPEDITER/TSO 7.0 - PRIMARY MENU ----------------------
OPTION ===>

0 DEFAULTS - Specify defaults
1 PREPARE - Prepare programs for debugging
2 TSO - Debug programs interactively under TSO
3 BATCH - Debug programs interactively under batch
4 STORED PROC - Debug DB2 Stored Procedures interactively
5 UTILITIES - Perform utility functions
F FADB2 - Invoke File-AID for DB2
FA FILE-AID - Invoke File-AID for MVS
C CODE COVERAGE - Code Coverage NOT INSTALLED

B BULLETIN - Display summary of changes for this release
T TUTORIAL - Display information about XPEDITER/TSO
X EXIT - Exit primary menu

Profile ===> DEFAULT <<


In order to compile our program we need to change

STEP1 : Profile ===> DEFAULT
to
Profile ===> BMP

STEP2 : goto OPTION =>
TYPE 2
ENTER


The following screen will be displayed

------------------------ XPEDITER/TSO - PROFILE (0.4) ---- Enter Description
COMMAND ===> SCROLL ===> PAGE

LINE COMMANDS: S (Select) D (Delete) C (Copy) R (Rename) U (Use)
PRIMARY COMMANDS: MERGE (copy other users profiles)
PROFILE ID:
Profile ===> BMP > BATCH PROGRAM <

CMD PROFILE NEW NAME DESCRIPTION
-------------------------------------------------------------------------------
_ DEFAULT > *** NO DESCRIPTION *** <
******************************* Bottom of data ********************************



ENTER

Profile will be added to the list.
Come back to the XPEDITER Main List

------ ????
What is the use of this Step?

You are creating your own setting to run an BMP program. All
settings will be stored in BMP profiles. Like this you can create
your own profiles to run different types of programs.
------ ?????


--------------------------------------------------------------------------------



Again goto the Main Screen of Xpediter.
TYPE 2
ENTER

It will show following screen.
(If your xpediter setup is over this next screen will be displayed)


Profile: DEFAULT ------ XPEDITER/TSO - ENVIRONMENTS MENU --------------------
OPTION ===>

XPEDITER/TSO
1 STANDARD - Test a program with no special environment services
2 DIALOG - Test programs that make ISPF dialog manager calls
3 IMS - Test a program that makes IMS/DB calls
4 BTS - Test programs using BTS




XPEDITER/IMS
8 MPP - Test programs in an IMS message region
9 BMP/IFP - Test a program in a BMP or Fast Path region




TYPE 1 OR 3
(select 1 if you want to run a simple program)
(select 3 if you want to run a program which will going to access IMS/DB)


ENTER


The following screen will be displayed

Profile: SIMPLE ------- XPEDITER/TSO - STANDARD (2.1) -----------------------
COMMAND ===>

COMMANDS: SEtup (Display Setup Menu)
PROFile (Display Profile Selection)
TEST SELECTION CRITERIA:

Program ===>
Entry Point ===>
Load Module ===>

Initial Script ===>
Post Script ===>

PARM String ===>


File List/JCL Member ===>


Is This a DB2 Test? ===> NO Plan ===> System ===>





TYPE 'SE' on command line

ENTER

The following screen will be displayed


Profile: BMP -------- XPEDITER/TSO - SETUP MENU --------------------------
OPTION ===>

E EXTENDED - Extended Setup Menu
0 ENVIRONMENT - Execution environments menu
1 LOADLIBS - Application load module libraries
2 DDIO - DDIO files
3 INCLUDES - Test script libraries
4 LOG - Session log dataset disposition
5 SCRIPT - Test script dataset disposition
6 DSNLOAD - DB2 system names and DSNLOAD libraries









A ALL - Display all of the above in succession (except 0)

Press ENTER to process or enter END command to terminate






Using this screen you need to tell XPEDITER ,
Where is your load library is?
What libraries you are using in your program?

Type 1
ENTER


The following screen will be displyed

Profile: BMP -------- XPEDITER/TSO - LOAD MODULE LIBRARIES ------------------
COMMAND ===>
COMMANDS: DOWN (for additional User Libraries)
User Libraries: --->>> Include ALL libraries your program requires <<<---
(Even if the library is in LINKLST, ie. COBOL or LE runtime libraries)
(1) ===> 'SYS2.LE370Z.PGMLIB'
(2) ===> ''
(3) ===>
(4) ===>
(5) ===>
(6) ===>
(7) ===>
(8) ===>
Installation Libraries: (This list contains overrides to installed defaults)
(9) ===>
(10) ===>
(11) ===>
(12) ===>
(13) ===>
(14) ===>
(15) ===>
(16) ===>




Here, we need to give IMS Libraries we are using, You can find them in RUN JCL


ENTER

TYPE '2' ON SETUP MENTU
ENTER


Profile: BMP ------------ XPEDITER/TSO - DDIO FILES -------------------------
COMMAND ===>


User Libraries:

(1) ===> 'SSSK.ER000000.ABC1.#002519.DDIO'
(2) ===>
(3) ===>
(4) ===>
(5) ===>
(6) ===>


Installation Libraries: (Changes made to this list override installed default

(7) ===>
(8) ===>
(9) ===>





ENTER


--------------------------------------------------------------------------------

COME BACK TO XPEDITER MAIN MENU

ALL STANDARD SETTINGS ARE OVER.
THE FOLLOWING STEPS YOU NEED TO DO EVERY TIME YOU WANT TO DEBUG A PROGRAM.


---------------------- XPEDITER/TSO 7.0 - PRIMARY MENU ----------------------
OPTION ===> 1

0 DEFAULTS - Specify defaults
1 PREPARE - Prepare programs for debugging
2 TSO - Debug programs interactively under TSO
3 BATCH - Debug programs interactively under batch
4 STORED PROC - Debug DB2 Stored Procedures interactively
5 UTILITIES - Perform utility functions
F FADB2 - Invoke File-AID for DB2
FA FILE-AID - Invoke File-AID for MVS
C CODE COVERAGE - Code Coverage NOT INSTALLED

B BULLETIN - Display summary of changes for this release
T TUTORIAL - Display information about XPEDITER/TSO
X EXIT - Exit primary menu

Profile ===> BMP - IMS BATCH PROGRAM





TYPE 1
ENTER

The following screen will be displayed

------------------ XPEDITER/TSO - PROGRAAM PREPARATION MENU ------------------
OPTION ===>

1 CONVERT COMPILE JCL - Convert compile JCL for XPEDITER
2 COMPILE FACILITY - Compile programs for XPEDITER
3 BIND FACILITY - Bind application plans for File-AID DB2
4 EDIT ALLOCATION LIST - Edit or Create file allocation lists





TYPE 4
ENTER


Following screen will be displayed

----------------------- XPEDITER/TSO - EEDIT FILE LIST -----------------------
COMMAND ===>

Specify File Allocation List Below:

ISPF Library:

Project ===>
Group ===>
Type ===>
Member ===> (Blank for member selection list)

Other Partitioned or Sequential Dataset:
Dataset Name ===> '< EXISTING PDS >(xped1)'
Volume Serial ===> (If not cataloged)

Copy from JCL, CLIST, or Other File Allocation List
Dataset Name ===> '< RUN JCL >'
Copy Option ===> PROMPT (Replace, Append, Prompt, or Cancel copy)
Automatic Expand ===> YES (Yes/No)
Step Selection ===> (Program name for automatic step selection)

Press ENTER to Process or Enter END Command to Terminate





ENTER

It will prompt you with your run jcl.
Select all SYSIN/SYSOUT/INPUT FILES USED IN PROGRAM/OUTPUT FILES
USED IN PROGRAM by putting 'S' infront of that line and Press ENTER.

TYPE END on command line ENTER
TYPE END on commend line ENTER

------------------------ XPEDITER/TSO - SELECT DDNAME ----------- Row 1 Of 6
COMMAND ===> SCROLL ===> CSR

LINE COMMAND: S (Select) PRIMARY COMMANDS: END (Process selected statements)
BR (Browse dataset) CAN (Quit without processing)
ED (Edit dataset) Edit (Edit JCL using ISPF Editor)
EXP (Expand JCL procedures)

Select the DDNAMEs to be copied to the allocate screen

SEL JCL Data Set: 'VAAE98.DFC2.VAAE98.GLOB.FFB.SOURCE(RUNJCL)'
-------------------------------------------------------------------------------
''''' //ESLE04 JOB (34050F,2331S),'RUNJCL',CLASS=S,MSGCLASS=T,
''''' // NOTIFY=&SYSUID
''''' //STEP1 EXEC PGM=STRING1
''''' //STEPLIB DD DSN= SSSK.ER000000.ABC1.#002519.BLM,DISP=SHR
''S'' //SYSIN DD *
''S'' //SYSOUT DD SYSOUT=*
******************************* Bottom of data ********************************





COME BACK TO XPEDITER MAIN SCREEN.

TYPE 2
ENTER


Profile: BMP ---------- XPEDITER/TSO - STANDARD (2.1) -----------------------
COMMAND ===>

COMMANDS: SEtup (Display Setup Menu)
PROFile (Display Profile Selection)
TEST SELECTION CRITERIA:

Program ===> STRING1
Entry Point ===>
Load Module ===>

Initial Script ===>
Post Script ===>

PARM String ===>


File List/JCL Member ===> 'DFC2.VAAE98.GLOB.FFB.SOURCE(XPED1)'


Is This a DB2 Test? ===> NO Plan ===> System ===>




ENTER

YOU WILL BE PROMPTED WITH YOUR PROGRAM








---------------
COMMANDS
---------------

1. PRESS F9 to debug your programs ( = GO 1)


2. PRESS F12 to execute all statement up to break point (= GO)


3. Break Points

B (before execution) / A (After execution)

put 'B' on line where you want to stop execution.

Ex. 00B046 READ INFILE INTO WORK-REC
PRESS ENTER, line will displayed in following way
000046 B READ INFILE INTO WORK-REC

now, If you press F12 , all statements executed and control
will stop at this line


4. KEEP / K

If you want to see a variable value while excuting, use KEEP

syntax - KEEP < VARIABLE NAME >

It shows the variable name and changing value while you debugging in
the top part of screen


5. PEEK < VARIABLE NAME >

P (PEEK) < VARIABLE NAME > and press Enter. The screen
automatically scrolls to the DATA DIVISION statement
where the VARIABLE defined, inserts a P in column 9,
and displays the occurrence and value of that variable


6. SKIP

To skip execution of a particular line


Serial No. 3, 4, 5, 6 command are line commands we can use
them on line

ex. 00S089 MOVE WS-SYS-VAR TO WS-ANM-VAR.


Following are command line commands. means you need to use them
at command line.


7. GOTO

It is used to pass control to particular line/paragraph

syntax : GOTO < LINE NUMBER >

GOTO < PARA NAME >


8. WHEN

WHEN is used to pause the execution of the program at certain
point when the set condition arises

EX. WHEN WS-SYS-VAR = 4587384

Xpediter stops the execution whenever it satisfies the condition.


9. QUIT to come out of Debugging session.


P

Insurance

In law and economics, Insurance is a form of risk management primarily used to hedge against the risk of a contingent, uncertain loss. Insurance is defined as the equitable transfer of the risk of a loss, from one entity to another, in exchange for payment. An insurer is a company selling the insurance; an insured, or policyholder, is the person or entity buying the insurance policy. The insurance rate is a factor used to determine the amount to be charged for a certain amount of insurance coverage, called the premium. Risk management, the practice of appraising and controlling risk, has evolved as a discrete field of study and practice.

The transaction involves the insured assuming a guaranteed and known relatively small loss in the form of payment to the insurer in exchange for the insurer's promise to compensate (indemnify) the insured in the case of a financial (personal) loss. The insured receives a contract, called the insurance policy, which details the conditions and circumstances under which the insured will be financially compensated.

Insurers' business model

Underwriting and investing

The business model is to collect more in premium and investment income than is paid out in losses, and to also offer a competitive price which consumers will accept. Profit can be reduced to a simple equation:

Profit = earned premium + investment income - incurred loss - underwriting expenses.

Insurers make money in two ways:

Through underwriting, the process by which insurers select the risks to insure and decide how much in premiums to charge for accepting those risks;

By investing the premiums they collect from insured parties.

The most complicated aspect of the insurance business is the actuarial science of ratemaking (price-setting) of policies, which uses statistics and probability to approximate the rate of future claims based on a given risk. After producing rates, the insurer will use discretion to reject or accept risks through the underwriting process.

At the most basic level, initial ratemaking involves looking at the frequency and severity of insured perils and the expected average payout resulting from these perils. Thereafter an insurance company will collect historical loss data, bring the loss data to present value, and comparing these prior losses to the premium collected in order to assess rate adequacy. Loss ratios and expense loads are also used. Rating for different risk characteristics involves at the most basic level comparing the losses with "loss relativities" - a policy with twice as money policies would therefore be charged twice as much. However, more complex multivariate analyses through generalized linear modeling are sometimes used when multiple characteristics are involved and a univariate analysis could produce confounded results. Other statistical methods may be used in assessing the probability of future losses.

Upon termination of a given policy, the amount of premium collected and the investment gains thereon, minus the amount paid out in claims is the insurer's underwriting profit on that policy. An insurer's underwriting performance is measured in its combined ratio which is the ratio of losses and expenses to earned premiums. A combined ratio of less than 100 percent indicates underwriting profitability, while anything over 100 indicates an underwriting loss. A company with a combined ratio over 100% may nevertheless remain profitable due to investment earnings.

Insurance companies earn investment profits on "float". Float, or available reserve, is the amount of money on hand at any given moment that an insurer has collected in insurance premiums but has not paid out in claims. Insurers start investing insurance premiums as soon as they are collected and continue to earn interest or other income on them until claims are paid out. The Association of British Insurers (gathering 400 insurance companies and 94% of UK insurance services) has almost 20% of the investments in the London Stock Exchange.

In the United States, the underwriting loss of property and casualty insurance companies was $142.3 billion in the five years ending 2003. But overall profit for the same period was $68.4 billion, as the result of float. Some insurance industry insiders, most notably Hank Greenberg, do not believe that it is forever possible to sustain a profit from float without an underwriting profit as well, but this opinion is not universally held.

Naturally, the float method is difficult to carry out in an economically depressed period. Bear markets do cause insurers to shift away from investments and to toughen up their underwriting standards, so a poor economy generally means high insurance premiums. This tendency to swing between profitable and unprofitable periods over time is commonly known as the underwriting, or insurance, cycle.

Claims:

Claims and loss handling is the materialized utility of insurance; it is the actual "product" paid for. Claims may be filed by insured’s directly with the insurer or through brokers or agents. The insurer may require that the claim be filed on its own proprietary forms, or may accept claims on a standard industry form, such as those produced by ACORD.

Insurance company claims departments employ a large number of claims adjusters supported by a staff of records management and data entry clerks. Incoming claims are classified based on severity and are assigned to adjusters whose settlement authority varies with their knowledge and experience. The adjuster undertakes an investigation of each claim, usually in close cooperation with the insured, determines if coverage is available under the terms of the insurance contract, and if so, the reasonable monetary value of the claim, and authorizes payment.

The policyholder may hire their own public adjuster to negotiate the settlement with the insurance company on their behalf. For policies that are complicated, where claims may be complex, the insured may take out a separate insurance policy add on, called loss recovery insurance, which covers the cost of a public adjuster in the case of a claim.

Adjusting liability insurance claims is particularly difficult because there is a third party involved, the plaintiff, who is under no contractual obligation to cooperate with the insurer and may in fact regard the insurer as a deep pocket. The adjuster must obtain legal counsel for the insured (either inside "house" counsel or outside "panel" counsel), monitor litigation that may take years to complete, and appear in person or over the telephone with settlement authority at a mandatory settlement conference when requested by the judge.

If a claims adjuster suspects under-insurance, the condition of average may come into play to limit the insurance company's exposure.

In managing the claims handling function, insurers seek to balance the elements of customer satisfaction, administrative handling expenses, and claims overpayment leakages. As part of this balancing act, fraudulent insurance practices are a major business risk that must be managed and overcome. Disputes between insurers and insured’s over the validity of claims or claims handling practices occasionally escalate into litigation (see insurance bad faith).

Marketing

Insurers will often use insurance agents to initially market or underwrite their customers. Agents can be captive, meaning they write only for one company, or independent, meaning that they can issue policies from several companies. Commissions to agents represent a significant portion of an insurance cost and insurers such as State Farm that sell policies directly via mass marketing campaigns can offer lower prices. The existence and success of companies using insurance agents (with higher prices) is likely due to improved and personalized service

Health insurance

Health insurance policies issued by publicly funded health programs, such as the UK's National Health Service will cover the cost of medical treatments. Dental insurance, like medical insurance, protects policyholders for dental costs. In the U.S. and Canada, dental insurance is often part of an employer's benefits package, along with health insurance.

Health insurance is insurance against the risk of incurring medical expenses. By estimating the overall risk of health care expenses, an insurer can develop a routine finance structure, such as a monthly premium or payroll tax, to ensure that money is available to pay for the health care benefits specified in the insurance agreement. The benefit is administered by a central organization such as a government agency, private business, or not-for-profit entity.

A health insurance policy is a contract between an insurance company and an individual or his sponsor (e.g. an employer). The contract can be renewable annually, monthly or be life long. The type and amount of health care costs that will be covered by the health insurance company are specified in advance, in a member contract or "Evidence of Coverage" booklet. The individual insured person's obligations may take several forms:

• Premium: The amount the policy-holder or his sponsor (e.g. an employer) pays to the health plan to purchase health coverage.
• Deductible: The amount that the insured must pay out-of-pocket before the health insurer pays its share. For example, policy-holders might have to pay a $500 deductible per year, before any of their health care is covered by the health insurer. It may take several doctor's visits or prescription refills before the insured person reaches the deductible and the insurance company starts to pay for care.
• Co-payment: The amount that the insured person must pay out of pocket before the health insurer pays for a particular visit or service. For example, an insured person might pay a $45 co-payment for a doctor's visit, or to obtain a prescription. A co-payment must be paid each time a particular service is obtained.
• Coinsurance: Instead of, or in addition to, paying a fixed amount up front (a co-payment), the co-insurance is a percentage of the total cost that insured person may also pay. For example, the member might have to pay 20% of the cost of a surgery over and above a co-payment, while the insurance company pays the other 80%. If there is an upper limit on coinsurance, the policy-holder could end up owing very little, or a great deal, depending on the actual costs of the services they obtain.
• Exclusions: Not all services are covered. The insured are generally expected to pay the full cost of non-covered services out of their own pockets.
• Coverage limits: Some health insurance policies only pay for health care up to a certain dollar amount. The insured person may be expected to pay any charges in excess of the health plan's maximum payment for a specific service. In addition, some insurance company schemes have annual or lifetime coverage maximums. In these cases, the health plan will stop payment when they reach the benefit maximum, and the policy-holder must pay all remaining costs.
• Out-of-pocket maximums: Similar to coverage limits, except that in this case, the insured person's payment obligation ends when they reach the out-of-pocket maximum, and health insurance pays all further covered costs. Out-of-pocket maximums can be limited to a specific benefit category (such as prescription drugs) or can apply to all coverage provided during a specific benefit year.
• Capitation: An amount paid by an insurer to a health care provider, for which the provider agrees to treat all members of the insurer.
• In-Network Provider: (U.S. term) A health care provider on a list of providers preselected by the insurer. The insurer will offer discounted coinsurance or co-payments, or additional benefits, to a plan member to see an in-network provider. Generally, providers in network are providers who have a contract with the insurer to accept rates further discounted from the "usual and customary" charges the insurer pays to out-of-network providers.
• Prior Authorization: A certification or authorization that an insurer provides prior to medical service occurring. Obtaining an authorization means that the insurer is obligated to pay for the service, assuming it matches what was authorized. Many smaller, routine services do not require authorization.
• Explanation of Benefits: A document that may be sent by an insurer to a patient explaining what was covered for a medical service, and how payment amount and patient responsibility amount were determined.

Prescription drug plans are a form of insurance offered through some employer benefit plans in the U.S., where the patient pays a copayment and the prescription drug insurance part or all of the balance for drugs covered in the formulary of the plan. Such plans are routinely part of national health insurance programs.

Some, if not most, health care providers in the United States will agree to bill the insurance company if patients are willing to sign an agreement that they will be responsible for the amount that the insurance company doesn't pay. The insurance company pays out of network providers according to "reasonable and customary" charges, which may be less than the provider's usual fee. The provider may also have a separate contract with the insurer to accept what amounts to a discounted rate or capitation to the provider's standard charges. It generally costs the patient less to use an in-network provider.

Xpeditor: How to debug programs interactively under batch

With the Batch Connect facility, you can submit your execution JCL in batch and connect directly to the job as it executes in its native environment, the MVS batch initiator.

Notes:

1.In Batch Connect mode, you do not have to allocate the files and databases required for your program to run. They are automatically allocated to the batch address space via the DD statements in the JCL.

2.No change in the TSO logon size is required for large programs.

The Batch Connect facility presents several screens that are used to automate the process of starting the session. The following summarizes the process:

1.Access the facility: Type option 3 (BATCH) on the Xpediter/TSO Primary Menu and press Enter to access the Batch menu (Figure 4-13). Type option 1 (Batch) on the Batch menu and press Enter to access the Batch Connect facility. The Process Execute JCL screen (Figure 4-14 on page 4-22) is displayed.

2. Process the execution JCL: The Process Execute JCL screen is used to identify the execution JCL for the debugging session. You can also access the ISPF editor to view and make changes to the JCL.

The JCL statements are scanned, expanded if the JCL is a procedure, and the job steps are extracted. A list of the job steps is then displayed on the Select Job Step screen.

3.Convert and submit the JCL: The Select Job Step screen is used to specify how you want each job step to execute (in interactive or unattended mode). When a job step is selected for interactive debugging, the source for that step is displayed at your terminal. When a step is selected to run in unattended mode, you cannot interact with the step from your terminal. If you want to debug the step, Xpediter debugging commands must be read from a test script and the output results from the test session are written to the session log.

You can submit the job from this screen or you can edit the JCL. When you submit the job, the Batch Connect JCL scanner automatically converts each step to execute in the specified mode (interactive or unattended).

4.Connect to the job: If you submit the job with the RUN command, you are automatically connected to the job steps that were specified to execute in interactive mode. If you submit the job with the SUBMIT command, you must use the CONNECT or STATUS command to connect your terminal to the job steps selected for interactive debugging.

Connection Security Check

Connection can be made to any job, including production jobs, as long as your site security grants the authority. The Batch Connect facility is shipped with a default security exit routine that allows connection to a job if the JOBNAME, without the last character, matches the TSO ID where the STATUS panel is accessed. When a connection cannot be made, the messages CANNOT CONNECT... or SECURITY CHECK FAILED... are issued.

The site installer can customize the security exit routine to tailor the security level for certain groups or individuals. When an asterisk (*) is entered in the JOBNAME field on the Status screen, all jobs that are waiting for connection or being tested under Batch Connect are listed. System programmers are able to connect to a remote job and use the facility as a help desk feature in debugging application programs.

Demo

Select option 3

----------------------  XPEDITER/TSO 7.7 - PRIMARY MENU  ----------------------

 OPTION  ===> 3                                                                

                                                                               

          0  DEFAULTS      - Specify defaults                                  

          1  PREPARE       - Prepare programs for debugging                    

          2  TSO           - Debug programs interactively under TSO            

          3  BATCH         - Debug programs interactively under batch          

          4  STORED PROC   - Debug DB2 Stored Procedures interactively         

          5  UTILITIES     - Perform utility functions                         

                                                                                

          FA FILE-AID      - Invoke File-AID for MVS                           

                                                                               

          C  CODE COVERAGE - Code Coverage Reports and Utilities                

                                                                               

          T  TUTORIAL      - Display information about XPEDITER/TSO            

          X  EXIT          - Exit primary menu                                 

                                                                                

    Profile ===> DEFAULT  - *** NO DESCRIPTION ***                             

                                                                               

            Press ENTER to process  or  enter END command to terminate         

Select option 1

Profile: DEFAULT ---------  Xpediter/TSO 7.7 - Batch  -------------------------

 OPTION  ===> 1                                                                 

                                                                               

          1  Batch         - Debug programs interactively under batch          

                                                                                

          2  Multi-Batch   - Debug multiple jobs interactively under batch     

                                                                               

Enter the dataset which has the JCL. Make sure jobname always TSO ID + one character. Otherwise XPED may show “Security check failed” message 

-------------------- XPEDITER/TSO - PROCESS EXECUTE JCL -----------------------

 COMMAND ===>                                                                  

                                                                               

 Primary Commands:  blank (Process JCL)   Browse   Edit   SEtup   STatus       

                                                                               

 ISPF Library:                                                                 

   Project ===>                                                                

   Group   ===>           ===>           ===>           ===>                   

   Type    ===>                                                                

   Member  ===>                (Blank for member selection list)               

                                                                                

 Other Partitioned or Sequential Dataset:                                      

    Dataset Name ===> 'MY.TEST.JCLLIB(TESTJOB)'                           

   Volume Serial ===>          (If not cataloged)                              

                                                                               

                                                                               

                                                                                

                                                                               

                                                                               

                                                                                

                                                                               

                                                                               

            Press ENTER to process  or  enter END command to terminate         

                                                                               

Select the “SE” option to setup the load library and DDIO file

Profile: DEFAULT-------  XPEDITER/TSO - SELECT JOB STEP  ----- Row 1 to 1 of 1

 COMMAND ===> se                                               SCROLL ===> PAGE

                                                                               

 Line Commands:                   Primary Commands:                            

   I - Interactive testing          Edit   - Display converted selected steps  

   U - Unattended testing           END    - Exit without processing           

  Followed optionally by:           RUN    - Submit and connect                

   C - Code Coverage                SEtup  - Setup work datasets               

   T - Code Coverage, plus TDO      SUBmit - Convert selected steps and submit 

   F - System Flow (F, CF or TF)    STatus - Display status of submitted job(s)

                                                                                

 Dataset: 'TSUBAQF.TB7500.TESTING(XPED)'                                       

                                                                               

       PROGRAM     INITSCR  POSTSCR    STEPNAME  PROCNAME  PROCSTEP  EXEC PGM  

 -----------------------------------  -----------------------------------------

 ___   TESTPRGM    ________ ________   STEP010                                 

 ******************************* Bottom of data ********************************

                                                                               

When we enter “SE” option in the previous screen, we get the below screen

                                                                               

Profile: DEFAULT--------  XPEDITER/TSO - SETUP MENU  --------------------------

 OPTION  ===>                                                                   

                                                                               

           0  JOB CARD     - JOB processing parameters                         

           1  LOADLIBS     - Application load module libraries                 

           2  DDIO         - DDIO files                                        

           3  INCLUDES     - Test script libraries                             

           4  LOG          - Session log dataset disposition                    

           5  SCRIPT       - Test script dataset disposition                   

           6  DSNLOAD      - DB2 system names and DSNLOAD libraries            

                                                                               

                                                                                

                                                                               

                                                                               

                                                                                

                                                                               

                                                                               

                                                                                

           C  CODE COVERAGE- Code Coverage setup options                       

           D  DOCUMENT     - Document dataset disposition                      

           E  EXTENDED     - Extended Setup Menu                               

           A  ALL          - Display all of the above in succession (except 0) 

                                                                               

            Press ENTER to process  or  enter END command to terminate         

Give “I” against the step for interactive debugging and enter RUN command. This will submit the below job and show us the debug screen

Profile: DEFAULT-------  XPEDITER/TSO - SELECT JOB STEP  ----- Row 1 to 1 of 1

 COMMAND ===> run                                              SCROLL ===> PAGE

                                                                               

 Line Commands:                   Primary Commands:                            

   I - Interactive testing          Edit   - Display converted selected steps  

   U - Unattended testing           END    - Exit without processing           

  Followed optionally by:           RUN    - Submit and connect                

   C - Code Coverage                SEtup  - Setup work datasets               

   T - Code Coverage, plus TDO      SUBmit - Convert selected steps and submit 

   F - System Flow (F, CF or TF)    STatus - Display status of submitted job(s)

                                                                                

 Dataset: 'TSUBAQF.TB7500.TESTING(XPED)'                                       

                                                                               

       PROGRAM     INITSCR  POSTSCR    STEPNAME  PROCNAME  PROCSTEP  EXEC PGM  

 -----------------------------------  -----------------------------------------

 I__   TESTPGM     ________ ________   STEP010                                 

 ******************************* Bottom of data ********************************