View
1.358
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
May 22, 2008 • 8:00 a.m. – 9:00 a.m.Platform: Cross-platform
John MalloneeHighmark Inc.
Session: F13
My Java App Called Your COBOL DB2 Stored Procedure
2
Objectives
• Objective 1: Learn why and where a COBOL stored procedure makes sense for Java applications.
• Objective 2: Learn the basics of building a COBOL stored procedure.
• Objective 3: Learn the basics of calling a DB2 stored procedure from a Java application.
• Objective 4: Understand the potential challenges.
• Objective 5: Develop a methodology for ongoing support.
3
Progress
DB2
COBOLJava
Why,What
Challenges
Support
4
What and Why
• Review – DB2 Stored Procedures on z/OS
• Business Needs of our project
• Project Overview
• Our Environment
• Decision Process
• Why to use DB2 Stored Procedures
• Why to not use DB2 Stored Procedures
5
Review – COBOL DB2 SP
• External stored procedure – definition and program code are separate
• CREATE PROCEDURE
• SYSIBM.SYSROUTINES, SYSIBM.SYSPARMS
• WLM – Workload Manager
• Address space for stored procedures
• COBOL code – SQL, packages
• Created (global) temporary tables – result sets
• SQL CALL from client application
See IBM Redbook SG24-7083-00
6
Business Need
• New application
• Reuse mainframe COBOL SQL on Java/web application
• Existing subprograms, DB2 packages
• Avoid duplication
• Development
• Maintenance
• Business risk
• Performance
7
Project Overview
• Internal customer billing application
• Web user interface
• Shared SQL
• batch COBOL – z/OS
• online Java/HTML – Linux
• Reuse existing business/database logic
• 16 DB2 Stored Procedures
• 8 read
• 8 insert/update
• Mainframe and Java developers
8
Our Environment
• Mainframe• z/OS version 1.8• Test and production LPAR’s• DB2 version 8 – full function mode• LE COBOL
• Open Systems• DB2 Connect version 8.2 on zLinux• Red Hat Linux – version 3.2.3• WebSphere Application Server 6.0• Java JDK 1.4 – JDBC • Java EE 1.3
9
Why use DB2 SP’s
• SP’s do the job
• Uses existing skills – DB2, COBOL, Java, SQL
• Minimize middleware use
• Minimize COBOL coding
• Intra-application communication – not shared across apps
• Reusable for standards-based SOA with wrappers• See Update at end
• Reusable by any application or tool using DB2/SQL• Application• Query Tool• Reporting Tool
10
Why to Not use DB2 SP’s
• Tied to DB2 as a DBMS
• Not our standard methodology – use of WebSphere MQ
• Not exactly standard for SOA (but pluggable to SOA standards)
• To use DB2 Stored Procedures
We chose…
11
Progress
DB2
COBOLJava
Why,What
Challenges
Support
12
The COBOL/DB2 Side
• Defining the Stored Procedure to DB2 (v. 8)
• Designing the COBOL application• Dynamically called subroutines• Different collection id's• Interface – input/output, messages, errors, result sets
• Coding the COBOL application• PROCEDURE DIVISION USING statement• DECLARE Temporary Table• DECLARE cursor• Data retrieval• Data updates
13
DB2 – Define Stored Proc
CREATE PROCEDURE TST1.GET_LIST ( IN COL_1 CHAR(9), IN COL_2 CHAR(16), OUT RETURN_STATUS CHAR(8), OUT RETURN_MESSAGES VARCHAR(1002), OUT COL_5 DATE ) DYNAMIC RESULT SET 1 LANGUAGE COBOL EXTERNAL NAME MYPROG PARAMETER STYLE GENERAL NOT DETERMINISTIC FENCED
14
DB2 – Define Stored Proc # 2
READS SQL DATA
NO DBINFO
COLLID XXX
WLM ENVIRONMENT XXXXXX
ASUTIME LIMIT 30000
STAY RESIDENT YES
PROGRAM TYPE SUB
SECURITY DB2
COMMIT ON RETURN NO
RUN OPTIONS 'MSGFILE(SYSPRINT,,,,ENQ)';
COBOL doesn’t manage transaction
We varied between test and production
15
COBOL – Design Application
• Load module per stored procedure
• Dynamically called subprograms
• Dynamic load module
• SQL Packages
• Different collection id's
• One per test environment
• One for Production
• Application Interface
• Transaction Management – calling application
16
COBOL – Design Application
• Application Interface
• Input parameters
• Output parameters• Business data• Status – OKAY, NOTFOUND, WARN, ERROR• Error Handling/Messages (multiple occurrences)• Error messages include embedded DB2
messages
• Result set(s)
17
COBOL – Design Application
IMS
Stored Procedure
DynamicSubroutine
DynamicSubroutine
PROCEDURE DIVISION USINGIN, OUT parameters
SQLPackage
SQLPackage
FileDB2
18
COBOL – Code Application
• PROCEDURE DIVISION USING statement
• DECLARE result set cursor – optional
• DECLARE Temporary Table – optional
• SELECT/INSERT/UPDATE data from/to DB2 or obtain from other source
• MOVE data to INOUT/OUTPUT parameters
• INSERT to temporary table (result set) – optional
19
COBOL – Parameters
IDENTIFICATION DIVISION.
PROGRAM-ID. MYPROG.
. . .
PROCEDURE DIVISION USING
VAR-1
VAR-2
RETURN-STATUS
RETURN-MSGS
VAR-5
Input
Output
20
DECLARE Temp Table
DECLARE GLOBAL TEMPORARY TABLE SESSION.XXX_RETURN_LIST
( COL_A CHAR(5) NOT NULL,
COL_B CHAR(10)NOT NULL,
COL_C DATE NOT NULL,
)ON COMMIT DROP TABLE Declare temporary table to store results setTemporary table is
dropped when main application commits
21
DECLARE CURSOR
DECLARE REVIEWLIST CURSOR WITH RETURN FOR
SELECT COL_A
, COL_B
, COL_C
FROM SESSION.XXX_RETURN_LIST
EXEC SQL
OPEN REVIEWLIST
END-EXEC Declare cursor for returned results set
22
INSERT to Temporary Table
INSERT INTO SESSION.XXX_RETURN_LIST
SELECT COL_1
, COL_2
, RETURN_STATUS
, RETURN_MSGS
, COL_5 FROM XXX_TABLE_A
FROM . . .
WHERE . . . Populate results set into temporary table
23
INSERT/UPDATE
• Same structure as stored procedure for data retrieval
• Probably don’t need returned results set (or temporary table or cursor)
• INPUT parameters
• Key(s) for row to UPDATE
• Column data to UPDATE or INSERT
• OUTPUT parameters
• Communicate status (OKAY, WARN, NOTFOUND, ERROR)
• # Rows inserted/updated
24
Progress
DB2
COBOLJava
Why,What
Challenges
Support
25
The Java Side
• Java application design
• Java API’s – JDBC, SQLJ, others
• JDBC Steps
• JDBC Example
• SQLJ Example
26
Java – Application Design
• Java Enterprise Edition application
• HTML screens through JSP pages
• Struts (open source web framework)
• Session Beans for transaction management (EJB)• Handles commits, rollback
• Data Access Objects (DAO) to invoke stored procedure using JDBC
• Reusable objects for error handling
• Debug capabilities for CallableStatement class
• More in Support Hints
27
Java – Application Design
DB2
ActionSession
BeanBusiness
ObjectData
Access
JDBC
DB2 Connect
WLMz/OS
Open systems
28
Java – API’s
• JDBC• Dynamic SQL• Part of Java Standard Edition specification• Dynamic statement caching
• SQLJ• Static SQL• ISO Standard – not part of base Java
specification• DB2 packages – SQL is in the DB2 catalog
• We use JDBC• Others – Hibernate, iBatis, EJB
29
Java – JDBC Steps
• CallableStatement – extension of Statement class
• Step 1 – build CALL string and prepare the call
• Step 2 – set input parameters, register output parameters
• Step 3 – execute and retrieve output parameters
• Step 4 – iterate through any result sets
NOTE: This example does not show the EJB which manages the transaction, issuing commits or rollbacksin the case of failure.
30
JDBC Example Part 1
String procName = “GET_LIST";String procCall = "CALL " + procCollection + "." +
procName + "(?, ?, ?, ?, ?)";CallableStatement cs = conn.prepareCall(procCall);cs.setString(1,keyObject.getField1( ));cs.setString(2,keyObject.getField2( ));cs.registerOutParameter(3, java.sql.Types.CHAR);cs.registerOutParameter(4, java.sql.Types.CHAR);cs.registerOutParameter(5, java.sql.Types.DATE);cs.execute( );someObject.setStatus(cs.getString(3));
31
JDBC Example Part 2
ResultSet rs = cs.getResultSet( );while (rs.next( )) {
MyResult result = new MyResult( );result.setStatus(rs.getString(“RETURN_MSGS"));result.setMessages(rs.getString(“RETURN_MSGS"));result.setDateField(rs.getDate(“COL_5"));
}
if (rs.getMoreResults( )) {rs = cs.getResultSet( );while (rs.next( )) {
… }
}
Iterate through additional result sets if any
32
SQLJ Example
#sql [myConnCtx] {CALL GET_LIST(:IN field1, :IN field2, :OUT status, :OUT messages, :OUT dateField)};
Multiple result sets:http://publib.boulder.ibm.com/infocenter/db2luw/v8/
index.jsp?topic=/com.ibm.db2.udb.doc/ad/ cjvsjmlt.htm
33
Progress
DB2
COBOLJava
Why,What
Challenges
Support
34
Challenges Encountered
• SQL Error Codes – there were many
• Application changes – even when there weren’t any
• Distributed development – Mainframe COBOL vs. Java
• WLM environment
• Miscellaneous
• Client fields (e.g. use in triggers)
• Security – calling from program vs. testing
35
SQL Error Codes
• -805/SQL0805N
• Ensure STAY RESIDENT NO (main)
• STOP/STA procedure for main program change
• Quiesce/resume WLM• pick up load module changes for lower level AI’s
• or wait for WLM recycle
• Migrating to new test environments
36
SQL Error Codes
• -471/SQL0471N – stored procedure is stopped
• – DIS PROCEDURE(TSTn.MY_PROC_NAME) to view status
• – STA PROCEDURE(TSTn.MY_PROC_NAME)
• Use SCOPE(GROUP) for data sharing
• -430/SQL0430N – stored procedure abended
• Correct COBOL program abend
• Repeated instances may cause -471
37
Application Changes
• Don’t always know application changed – “stored procedures aren’t working”
• Making application changes effective
• Use STAY RESIDENT NO for test• Picks up SP load module changes
• Use STAY RESIDENT YES for production for performance
• Must STOP/START procedure on change
• Dynamic subprograms• Not affected by STAY RESIDENT NO/YES• Quiesce/refresh WLM environment for changes
38
Distributed Environment
• COBOL/mainframe vs. Java developers
• Logon to multiple platforms
• View debug info
• Tools on different platforms
• Unit testing tools
• Debug tools
• Release management
• We had lack of mainframe debug tool
• Ownership of different application code
• Same issues as for any cross-platform applications
39
WLM Environment
• WLM address space management/monitoring
• Know the right people to contact
• WLM administrators didn’t have much more experience than the development team
• Dynamic subroutines – changes require WLM quiesce/refresh
• Consider WLM Refresh Stored Procedure (more in Support Hints)
• Stopped procedures – occurred periodically
• Difficult to identify results of stored procedure call
• -STOP/-STA PROC(ALL) – admin access required
40
Progress
DB2
COBOLJava
Why,What
Challenges
Support
41
Support Hints
• Testing (including security)
• Debugging (cross-platform)
• Environment
• Developer skills
• Documentation
• Security
• Where we are today – over one year later
42
Support Hints – Testing
• Stored Procedure tester (HTML/Java)
• Setting input parameters generically
• Obtaining output parameters generically
• Returning list of SP’s
• More details on next slide
• Testing from COBOL
• Stub module to invoke SP
• Generic mainframe tool for calling load module
• Specify parameters/configuration
43
Support Hints – SP Tester
• SELECT NAME, SCHEMA, EXTERNAL_NAME, RESULT_SETS, PARM_COUNT FROM SYSIBM.SYSROUTINES WHERE NAME LIKE ? AND SCHEMA = ?
• INPUT and OUTPUT parameters
• CallableStatement set and get methods
• Identify parameter field types at input time
• Convert entered name mask to all CAPS
• Special characters – view HTML
• Security for SP execution
• Or third party product
44
Support Hints – SP Tester
45
Support Hints – Debugging
• Trace information• DISPLAYs in COBOL• log4j in Java (dynamic setting, multi-server)
• What to DISPLAY/log:• All interface fields (input, output)• Date/time – differentiate between instances• Java and COBOL – show both sides
• Tool for stored procedure program tracing (mainframe)
• Stored Procedure tester• Independent verification – separate from Java/web
application
• Debug capabilities for CallableStatement
46
Support Hints - Environment
• Ability to recycle WLM environment• WLM_REFRESH – IBM Stored Procedure• We use SP Tester to invoke (test only)
• See –STOP/-STA commands above• Looking at the catalog (definitions and other)• WLM view
• Need to know started task name(s)• Indicates whether regions are running, when
they started• JESMSGLG – error messages• SYSOUT – DISPLAY messages
47
Support Hints – Skills
• Mainframe
• COBOL
• WLM – viewing started tasks
• DB2 programming (SQL, binds)
• DB2 commands (STOP, START, DIS)
• Open Systems
• Java/JDBC• CallableStatement• ResultSet
• DB2 SQL, error codes
48
Support Hints – Documents
• DB2• How to create stored procedures• How the WLM works including refreshing, viewing
current and history regions
• COBOL• What comprises the standard interface and what
common fields mean (status, messages)
• Java• How to test stored procedures• How to view results on the mainframe
• Overall• Coding practices – e.g. DISPLAY and logging
49
Support Hints - Security
• SELECT vs. INSERT, UPDATE, DELETE
• Application requirements
• Debugging requirements (e.g. SELECT)
• Test vs. production
• Debugging, unit testing
• Querying
• Secondary authid
• Application id
• Individual users – stored procedure testing
50
Support Hints - Status
• Application in production for almost a year
• Running smoothly
• Maintainable
• Some functionality exposed as web services from Java to another application
• Documentation is a must
• Coding
• Testing
• Errors
• Code changes
51
References
• DB2 Stored Procedures for z/OS - http://www.redbooks.ibm.com/abstracts/sg247083.html
• CREATE PROCEDURE – http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/r0008328.htm
• CREATE GLOBAL TEMPORARY TABLE – http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/ r0003272.htm
• Java CallableStatement (J2SE 1.4.2) – http://java.sun.com/j2se/1.4.2/docs/api/java/sql/CallableStatement.html
52
References (cont’d)
• SQLJ calls to Stored Procedures - http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/ tjvsjcal.htm
• Article on STAY RESIDENT - http://www.db2mag.com/qanda/031103.shtml
53
That’s a Wrap
54
John MalloneeHighmark Inc.
Session F13
My Java App Called Your COBOL DB2 Stored Procedure