ca idms tm sql routines: an overview july 22, 2008 cal j. domingue

CA IDMSTM SQL Routines: An Overview

July 22, 2008

Cal J. Domingue

2 July 22, 2008 CA IDMS SQL Routines: An Overview Copyright © 2008 CA

Legal

This presentation was based on current information and resource allocations as of July 22, 2008 and is subject to change or withdrawal by CA at any time without notice. Notwithstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this presentation remain at CA’s sole discretion. Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA will make such release available (i) for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as part of CA maintenance and support, and in the form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis. In the event of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall govern.


Legal

Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “as is” without warranty of any kind, including without limitation, any implied warranties or merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA is expressly advised of the possibility of such damages.


Abstract

> CA IDMSTM SQL allows you to access your CA IDMSTM/DB network data, as well as SQL databases, directly with SQL. For certain database structures or application needs, utilizing routines may make your implementation more efficient and robust. By using routines, you can also invoke CA IDMS business logic through SQL and SQL based APIs. This is part one of a three-part series covering CA IDMS SQL routines: table procedures, procedures, and functions. This course provides an overview of all three types of routines, including when to consider using them, and how to design and deploy them effectively.


Agenda

> Business Value of CA IDMS Modernization and SOA

> CA IDMS SQL routine overview

> Implementing routines: CrEATE

> Effectively deploying routines

> Review & summary

Business Value of CA IDMS Modernization and SOA


CA IDMS Business Value:Modernization and SOA

> Access CA IDMS mainframe assets

Databases and business logic

Enable Web access, Web services, SOA participation

> Use standard APIs with CA IDMS SQL, CA IDMS Server

SQL, JDBC, ODBC, .NET, Web services …

Partner solutions

> Provide business value benefits

Use current developer skills

Preserve existing data and applications

Deploy on modern platforms: J2EE, .NET

Tie CA IDMS assets into modern enterprise architecture


SOA

Web and Application Servers

Modern Application Architecture

Internet

CA IDMS™Server

CA IDMS data and business logic

Web Applications

CA IDMS SQL Routines

Overview


What is a Routine?

Think PIP

A routine is a user-written Program or dialog which is Invoked directly by the SQL engine when the routine is referenced in SQL DML; the call is managed by PParameters specified either as part of the definition or as part of a standard set of arguments included in the call.

Implications Involves user-written code, must be tested and optimized Code must be written to interface successfully with engine Parameter values have great impact


User-Written Program / Dialog

> Language options are dependent on type of routine COBOL

PL/I

Assembler

CA ADS

> Routine definition specifies the program / dialog name

> Load module with this name invoked directly by SQL engine when it processes SQL DML that references routine


User-Written Program / Dialog (cont.)

> Evaluates and analyzes parameters

> Performs processing Supported under CA IDMS (CV and Batch) Non-terminal Protocol BATCH recommended for maximum portability

> Sets output value and null indicator of parameters

> Sets program parameters SQLSTATE, Message as needed


Invocation of SQL Routines

Three basic types of routines > Table procedure in SELECT, INSERT, UPDATE, DELETE

Can be used the same way as a table or view, i.e. also in join Associated program invoked iteratively until programs sets

SQLSTATE = 02000 or 38nnn Returns or updates zero to many rows

> Procedure through CALL or SELECT Can be used the same way as a table or view, i.e. also in join Associated program/code invoked once per call Returns zero to one row

> Function in value-expression Associated program/code invoked once for each evaluation of the

value-expression containing the function reference Returns a single value or null


Parameters That Manage Invocation

> Included in routine definition Each specifies an SQL datatype Always both input and output Always nullable Can receive default value Control or impact logic executed within the routine Determine which rows are returned

> Standard arguments Usage dependent on type of routine Can impact logic executed within the routine Set by table procedure to indicate iteration should stop Customized error messages


Types of Routines*

> Two categories of routines* Called routines*

– Also called external routines

– Written in CA ADS, Assembler, COBOL or PL/I

SQL routines* (r17) – Also called internal routines

– Definition in catalog specifies language SQL

– Written in SQL language *CA IDMS r17 Terms

> Three types of routines Table procedure Procedure Function

> Each type of routine falls into one or both categories


Types of Routines: Summary

Called Routine - External routines - CA ADS, Assembler, COBOL, PL/I

SQL Routine r17 - Internal routines - LANGUAGE SQL - SQL language

Table Procedure - CREATE TABLE PROCEDURE - Invoked iteratively - 1 to many rows

Yes No

Procedure - CREATE PROCEDURE - Invoked once - 0 to 1 row

Called Procedure SQL Procedure

Function - CREATE FUNCTION - Invoked 1 per expression - Value or null

Called Function SQL Function

> Cross-reference by Type and Category > Chief characteristics noted


When to Use Routines

> Encapsulate complex code

> Standardize common processes

> Utilize existing code (procedure, function)

> Sophisticated security, i.e. row level, external dependencies

> Reduce client/server communication

> Within a single SQL transaction Transparently consolidate data from different databases Access segmented databases


When to Use Routines (Cont…)

> Access non-SQL structures Insert rows in sets and no foreign keys defined Bill of Material Occurs depending on elements Multi-member sets Special, complex processing is required (i.e. REDEFINES,… )

> Use of table procedure for SQL access on network databases is not required for:

Fixed occurs elements Update/Delete of rows in sets and no foreign keys defined

(use ROWID)

> Function Invoke application-specific routines Return a value from available parms


Which Routine to Use When?

Value or

Row(s)?

SQLFunction*

MultipleRows

?

Use SQL

Code*?

Table Procedure

SQLProcedure*

Called Procedure

Rows No No

Yes Yes

Use SQLCode?*

Yes

CalledFunction

No

Value

* Available r17

Implementing Routines: CrEATE

The Steps


Steps to Implement a Routine: CrEATE

>Create statement: define routine in the catalog

>Write the routine COBOL, Assembler, PL/I for any routine CA ADS mapless dialog for function or procedure SQL DML, network DML, neither, or both

>Enable security

>Add program definition to system (DC/UCF)

>Test and debug

>Efficiency check: optimize & tune


Create Statement: Define In The Catalog

> Slight syntax variations by routine type> Type: table procedure, procedure, or function> Schema and name> External name: associates SQL routine with load module> Parameters: name, data type, optional default > Language: only required when LANGUAGE SQL > Protocol: IDMS or ADS > Optional attributes: estimates, system/user mode, work

area, …


Create Table Procedure: Example

CREATE TABLE PROCEDURE DEMOEMPL.TBLPROC

( E_ID UNSIGNED NUMERIC(4),

E_NAME CHARACTER(25),

E_ADDRESS CHARACTER(46) )

EXTERNAL NAME TPROCPGM

ESTIMATED ROWS 1000

ESTIMATED IOS 100

USER MODE

LOCAL WORK AREA 800

GLOBAL WORK AREA 1200 KEY SHR1

TRANSACTION SHARING DEFAULT

DEFAULT DATABASE CURRENT

TIMESTAMP ;


Create Procedure: Example

CREATE PROCEDURE DEMOEMPL.TESTPROC

( E_ID UNSIGNED NUMERIC(4), E_NAME CHARACTER(25),

E_ADDRESS CHARACTER(46) )

EXTERNAL NAME PROCPGM

PROTOCOL IDMS

ESTIMATED ROWS 1000

ESTIMATED IOS 100

USER MODE

LOCAL WORK AREA 800


TRANSACTION SHARING DEFAULT

DEFAULT DATABASE CURRENT; • r17 SQL procedures might include language SQL and SQL language

statements (mode, protocol can default, local work area likely not useful)


Create Function: Example

CREATE FUNCTION DEMOEMPL.FUNCBONUS

( F_EMP_ID DECIMAL(4) )

RETURNS DECIMAL(10)

EXTERNAL NAME FUNBONUS

* LANGUAGE SQL

ESTIMATED ROWS 1000

ESTIMATED IOS 100


TRANSACTION SHARING ON

DEFAULT DATABASE CURRENT

* <SQL Language statements>; *=r17 SQL functions only


Write The Routine

> Must interface successfully with SQL engine Interpret parameters and perform appropriate logic Structured code Structured storage

> Calling arguments One for each parameter specified in the definition One null indicator for each parameter in the definition Additional argument, indicator for value returned by function Common arguments

> Language must match protocol (& language) in definition

> Can use existing code in some situations

> Can use CA ADS code (procedures or functions)


Write The Routine: SQL Engine Interface

> Structured work areas COBOL ‘Linkage Section’ and ‘Procedure Division Using’ Parameters Common structure (next slide) Local & global work areas

> SQLSTATE For table procedures, controls when iteration is stopped For others, indicates result – 00000 if not set otherwise

> Must return expected results Table Procedures: 0-many rows Procedures: 0-1 row Function: value

> Optional case-specific error message


Write The Routine: Common Arguments

77 RESULT-IND PIC S9(4) USAGE COMP SYNC.01 SQLSTATE PIC X(5).77 PROCEDURE-NAME PIC X(18).77 SPECIFIC-NAME PIC X(8).77 MESSAGE-TEXT PIC X(80).01 SQL-COMMAND-CODE PIC S9(8) USAGE COMP SYNC.01 SQL-OP-CODE PIC S9(8) USAGE COMP SYNC.01 INSTANCE-ID PIC S9(8) USAGE COMP SYNC.01 LOCAL-WORK-AREA.01 GLOBAL-WORK-AREA.

SQLSTATE00000 -- Indicates success 01Hxx -- Indicates a warning02000 -- Indicates no more rows38xxx -- Indicates an error


Write The Routine: Work Areas

> COBOL linkage section

> Local work area Separate area for each scan

Preserved over calls within scan (DML)

Database position, input parameters, etc.

> Global work area Shared by procedures and scans in same transaction

Subschema control

Has an associated key

> Specify sizes for above in procedure definition


Enable Security

> Procedures, table procedures Security identical to a table

Grant and revoke

SELECT, INSERT, UPDATE, DELETE, DEFINE privileges

> Functions Grant and revoke

SELECT, DEFINE privileges

To create

– Own the schema in which the function is being defined

– Hold the CREATE privilege on function

To invoke, either own or hold SELECT privilege on function


Add Program Definition to System

> When executing in CA IDMS Central Version

> Not required when coded in CA ADS or SQL

> Example

ADD PROGRAM CAAVLREC

DUMP THRESHOLD IS 0

ERROR THRESHOLD IS 5

ISA SIZE IS 0

LANGUAGE IS COBOL .

> Before sysgen cycle, use dynamic definition for testing

DCMT VARY DYN PRO CAAVLREC COBOL .


Test and Debug Routines

> DISPLAY commands in COBOL, PL/I to print to file (LE/370)

> Invoke in local mode to trace path through logic SYSIDMS parameters

– DMLTRACE=ON

– SQLTRACE=ON

– PROCTRACE=ON (with either above)

“DEBUG” COBOL statements (compile with DEBUG option)

> CV mode testing CA IDMSTM Performance Monitor or other monitor for statistics

WRITE TO LOG or SNAP commands for trace, data structures

DISPLAY commands to trace logic path, show values

> Evaluate logical results


Efficiency: Statistics and Optimization

> For table procedure and procedure

> Statistics provided manually (only) CREATE TABLE PROCEDURE, CREATE PROCEDURE,

CREATE KEY

ESTIMATED ROWS

ESTIMATED IOS

> Very useful in joins with other data sources

> Code efficiency only concern when routine is sole data source

> Verify access path with EXPLAIN


Efficiency: Keys

> Define with CREATE KEY statement> Specifying key columns

KEY estimated values override routine values if all KEY elements specified

Influences join strategy Statistics for KEY used in optimization Using a key in join operations

– Specify in “WHERE” clause– Encourage use by specifying low value for statistics

CREATE KEY EMP1 ON DEMOEMPL.TBLPROC(E_ID)

ESTIMATED ROWS 1 ESTIMATED IOS 1;

Effectively Deploying Routines


Deployment Strategy and Considerations

> Usability reasons

> Performance requirements

> Database access requirements

> When a remote procedure call is required

> To incorporate SQL language (r17)

> Usage of procedures and functions


Usability Reasons to Implement Routines

> Utilize existing code


> Standardize common processes


Performance Requirements

Table procedures and procedures

> Use only when direct SQL access is not adequate

> Highly variable cardinality and statistics




Database Access Requirements

> Table Procedures and Procedures Use direct SQL DML when possible

Use views to simplify complex SQL DML

Use only when direct SQL access is not adequate

> Not required for SQL access to some network structures Fixed occurs elements

Update/Delete rows where no foreign key defined (ROWID)


Database Access Requirements (cont)

> Required for SQL access to some network database structures

BOM: bill of material

Occurs depending on elements

Multi-member sets

Insert rows in sets and no foreign keys defined

Structures requiring special, complex processing (REDEFINES)

Within a single SQL transaction

– Transparently consolidate data from different databases

– Access segmented databases

Access remote data (distributed across nodes)


Usage Considerations for Procedures

> Similar uses as table procedures

> Simpler interface

> Use when returning a single row is adequate

> Use when a remote procedure call is required

> To implement SQL routines (r17) To include SQL commands: DDL, DML, authorization,

session/transaction management, etc.

Very useful for more complex business requirements


Usage Considerations for Functions

> Invoke application-specific routines

> Re-use code and embed it in query

> To derive a value from available parameters

> Must set return value (USER_FUNC)

> Cannot reference a user-defined function within the search condition of a table's check constraint

> SQL functions (r17) To include SQL commands: DDL, DML, authorization,

session/transaction management, etc. Very useful for more complex business requirements


COBOL, PL/I, Assembler Considerations

> Protocol BATCH recommended in program Executes in local mode or within IDMS CV address space

No DC commands allowed

> Avoid statements prohibited in DC/UCF environment DISPLAY statements in COBOL

GETMAIN requests in Assembler

Follow rules in appropriate CA IDMS DML Reference

> Programs should be reentrant or pseudo-reentrant

> Programs should be linked with an AMODE of 31

> Define routine with PROTOCOL IDMS


CA ADS Considerations

> CA ADS mapless dialogs

> Can be used for functions and procedures

> Premap process must conclude with LEAVE ADS command

> Make ADSOOPTI load module available in local mode load libraries

> Definition requirements Protocol ADS

Mode SYSTEM

> Must include work record <schema>.<routine_name> Not read from the dictionary

Automatically constructed when dialog is compiled

Can reference to parameters and null indicators


Error Handling

> Two arguments for managing exception conditions SQLSTATE

Message area (80-byte)

If SQLSTATE warning or error, message returned to caller

> CA IDMS examines returned SQLSTATE value to determine if operation was successful

> Customized SQLSTATE error codes and messages

> If error, changes made by call to routine are rolled out

Session Summary


Definition of Routines

Think PIP

A routine is a user-written Program or dialog which is Invoked directly by the SQL engine when the routine is referenced in SQL DML; the call is managed by PParameters specified either as part of the definition or as part of a standard set of arguments included in the call.


Implement Routines: CrEATE

>Create statement: define routine in the catalog

>Write the routine

>Enable security

>Add program definition to system (DC/UCF)

>Test and debug

>Efficiency check: optimize & tune


Routine Overview

Table Procedure

Procedure Function

DML reference FROM clause FROM clause Value-expr

CALL statement Allowed Yes No

Existing Code No Yes Yes

CA ADS Code (r16) No Allowed Allowed

SQL Code (r17) No SQL Procedure SQL Function

Returns 0-many rows 0-1 rows Value

SQLSTATE Required Optional Optional

Error Message Optional Optional Optional

Local/Global WA Suggested Optional Optional


Use Strategically

> Usability reasons

> Performance requirements

> Database access requirements

> When a remote procedure call is required

> To incorporate SQL language (r17)

> Usage of procedures and functions

> When direct SQL DML access or standard functions don’t meet requirements

> Test and verify results


Frequent Uses

> Utilize existing code (procedure, function)


> Standardize processes

> Access network structures (BOM, occurs depending on, multi-member sets)



> Make data location transparent

> Invoke application-specific routines


For More Information

> Recorded webcasts http://ca.com/us/webcasts/ondemand/default.aspx CA IDMSTM Modernization: CA IDMSTM Table Procedures, Quick Bridge CA IDMSTM Modernization: CA IDMSTM Procedures, Advanced Topics

> support.ca.com CA IDMS knowledge documents Product manuals

– CA IDMS SQL Reference Guide– CA IDMS r17 Release Summary (available at GA)

Technical support > Analyst white paper on CA IDMS modernization and SOA

Leveraging CA IDMS™ Business Value for Innovation See ca.com/idms under Analyst Reports

http://support.ca.com/

http://ca.com/idms


CA WORLD 2008: November 16th – 20th

The Venetian Congress Center and Sands Expo, Las Vegas

> The biggest Mainframe ISV Event in the world in 2008!

> CA IDMS sessions in Mainframe and Multi-Platform Application Development Focus Area

Customer, Partner and CA speakers

Optimization, Modernization, SOA and r17 sessions

> Pre-conference Education EC802SN CA IDMS: Implementing and Maintaining the Database

EC801SN CA IDMS Performance and Tuning

> Networking Opportunities Technical Campground, Birds-of-a-Feather session,

Exhibition Center, Power lunches

> Visit www.caworld.com for more details

http://www.caworld.com/

Questions &

Answers

Thank You for

Attending Today’s Webcast

ca idms tm sql routines: an overview july 22, 2008 cal j. domingue

Documents

ca ca idms business

ca idms server sql

ca maintenance

ca abstract ca idms

ca idms tm sql routines

ca idms business logic

ca software product

ca soa web