IBM DB2 V8 for z/OS Neue Funktionen für AE und Applikationsprogramme

Präsentation zum Thema: "IBM DB2 V8 for z/OS Neue Funktionen für AE und Applikationsprogramme"—  Präsentation transkript:

1 IBM DB2 V8 for z/OS Neue Funktionen für AE und Applikationsprogramme
(*) IBM DB2 V8 for z/OS Neue Funktionen für AE und Applikationsprogramme (DB2-V8_AE_APneu) (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc.

2 3.1 „dynamic scrollable Cursors“ 3.2 SQL/PL Funktionen
Neue AP Funktionen 3.1 „dynamic scrollable Cursors“ 3.2 SQL/PL Funktionen 3.3 STP und Procedure Verbesserungen 3.4 Neue Spezialregister 3.4.1 SET Current Schema 3.4.2 SET Current PACKAGEPATH 3.5 ODBC Verbesserungen 3.6 Implizite RRSAF Verbindungen 3.7 Neue XML Funktionen

3 Neue AP Funktionen 3.1 „dynamic scrollable Cursors“
„Scrollable cursor“, die den Zugriff auf die „the base table“ anders zulassen als eine DTT – ermöglichen das Sichtbarwerden von eigenen und fremden „updates“ und „inserts“ Führt als Default einen „single row FETCH“ aus. DDF Applikationen sollten:: Multi-row FETCH Positioned UPDATE/DELETE for multi-row FETCH verwenden. DB2 V8 introduces dynamic scrollable cursors. A dynamic scrollable cursor does not materialize the result table at any time. Instead, it scrolls directly on the base table and is therefore sensitive to all committed inserts, updates, and deletes. Dynamic scrollable cursors are supported for the index scan and table space scan access paths. DPSIs also support dynamic scrollable cursors. Dynamic scrollable cursors can be used with row-level operations or rowset-level operations. Rowset-level operations are discussed im Kapitel, “Multi-row FETCH and INSERT” DECLARE C1 SENSITIVE DYNAMIC SCROLL CURSOR FOR SELECT C1, C2 FROM T1;

4 Neue AP Funktionen 3.1.1 „Scrollable Cursor“ - Wiederholung
Implizit über „temporary tables“ (Anwendungs-Scope), d.h. Zugriff auf TEMPDB erforderlich Zwei unterschiedliche Typen Insensitive  Keine Verbindung zu Basis-Daten Static Sensitive Implizite Synchronisierung über RID und Re-Evaluierung des WHERE ... Syntax-Erweiterungen für DECLARE und FETCH Neue SQLCODE‘s beim Zugriff auf nicht(mehr) existente „Cursor“-Daten

5 Neue AP Funktionen 3.1.2 Scrollable Cursor Typen
Insensitive scrollable cursor immer „static“ Feste Anzahl „rows“ Nutzung von „Declared temp tables“ Sensitive static scrollable cursor • immer „static“ Sensitive auf Änderungen, aber nicht auf INSERT‘s Sensitive dynamic scrollable cursor • „direct table access“ „live data access“

6 Neue AP Funktionen 3.1.3 Scrollable Cursor - Syntax DECLARE cname
INSENSITIVE STATIC SENSITIVE SCROLL CURSOR ....

7 Neue AP Funktionen 3.1.4 Scrollable Cursor – (Cursordefinitionen)
Read only cursor Not aware of updates or deletes in base table Updatable cursor Aware of own updates or deletes within cursor Other changes to base table not visible to cursor All inserts not recognized Updatable cursor Aware of own updates and deletes within cursor sees all committed updates and deletes All inserts not recognized

8 ACCOUNT- Tabelle Neue AP Funktionen RESULT SET
3.1.5 Öffnen eines „Scrollable Cursor“ ACCOUNT- Tabelle DECLARE curs1 SENSITIVE SCROLL CURSOR WITH HOLD FOR SELECT account, account_name, credit_limit , type FROM account WHERE account = :in_account ..... OPEN curs1 .... Result Set DB2 erzeugt eine TEMP Tabelle der Zugriff ist „exklusiv“ es existiert eine fixe Anzahl „rows“ Tabelle wird zum Zeitpunkt „CLOSE CURSOR“ gelöscht erfordert TEMP DB und vordefinierte TS RESULT SET FETCH...

9 Neue AP Funktionen 3.1.6 Scrollable Cursor – FETCH BEFORE ABSOLUTE 0
Ergebnismenge FIRST ABSOLUTE 1 PRIOR RELATIVE -1 Aktuelle Position CURRENT RELATIVE 0 NEXT RELATIVE +1 LAST ABSOLUTE -1 AFTER

10 Neue AP Funktionen 3. Neue AP Funktionen
Scrollable Cursor – neue Attribute SENSITIVE DYNAMIC Gibt an, dass die Grösse der RT nicht zum Zeitpunkt des OPEN Cursor festgelegt wird Der Cursor ist vollständig sensibel auf Änderungen Alle „committed“ inserts, updates, deletes durch andere AP Prozesse Alle „positioned updates“ und „deletes“ innerhalb des Cursors Alle inserts, updates, deletes durch denselben AP Prozess, aber ausserhalb des Cursors Der FETCH erfolgt gegen die „base table“ da keine temporary result table erstellt wird ASENSITIVE DB2 entscheidet über die „sensitivity of cursor“ Wenn „read-only“... Cursor ist INSENSITIVE wenn das SELECT Statement SENSITIVE nicht erlaubt (UNION, UNION ALL, FOR FETCH ONLY, FOR READ ONLY) Er verhält sich wie ein „insensitive cursor“ Wenn „not read-only“, wird SENSITIVE DYNAMIC für ein Maximum an „sensitivity“ stehen Vorwiegend sinnvoll für Client AP, die sich nicht darum kümmern, ob die Server „sensitivity“ oder „scrollability“ unterstützen SENSITIVE DYNAMIC specifies that the result table of the cursor is dynamic, in that the size of the result table may change after the cursor is opened as rows are inserted into or deleted from the underlying table, and the order of the rows may change. Rows inserted, updated, or deleted with INSERT, UPDATE, and DELETE statements executed by the same application process are immediately visible. Rows inserted, updated, or deleted with INSERT, UPDATE and DELETE statements executed by other application processes are visible once committed. Because the FETCH statements are executed against the base table, no temporary result table is created. The SELECT statement of a cursor that is defined as SENSITIVE DYNAMIC cannot contain an INSERT statement. For client applications that do not care whether or not the server supports the sensitivity or scrollability, you can use the ASENSITIVE option, to let DB2 determine whether the cursor behaves as SENSITIVE DYNAMIC or INSENSITIVE depending on the complexity (updateability) of the associated SELECT statement. If the cursor is specified as ASENSITIVE and is read-only, it behaves as an INSENSITIVE cursor. If the cursor is specified as ASENSITIVE and is not read-only, DB2 provides the maximum allowable sensitivity, which is SENSITIVE DYNAMIC.

11 Neue AP Funktionen 3.1.7 Scrollable Cursor – FETCH Syntax (keine Änderung) FETCH INSENSITIVE SENSITIVE NEXT / PRIOR / FIRST / LAST / CURRENT /BEFORE / AFTER ABSOLUTE integer *) Typ integer oder DECIMAL (18,0) RELATIVE host-variable * FROM cursorname

12 Neue AP Funktionen 3.1.7 Scrollable Cursor – Einflüsse auf FETCHes
INSENSITIVE geht nicht im FETCH Statement (SQLCODE -244) wenn zugehörige Cursor mit SENSITIVE DYNAMIC SCROLL definiert ist Der Cursor als ASENSITIVE deklariert wurde und DB2 die maximale mögliche „sensitivity“ bei SENSITIVE DYNAMIC SCROLL vorgibt Es gibt KEINE "holes" , da es KEINE „temporary result table“ gibt Spezialfall: Wenn FETCH CURRENT oder FETCH RELATIVE +0 gefordert wurde, aberdie „row“ auf die der Cursor positioniert war, gelöscht oder geändert wurde, sodass sie nicht mehr zur Resultatsmenge gehört (SQLCODE +231) Beispiel: bei ISOLATION(CS) und CURRENTDATA(NO) Inserts durch das eigene AP sind unmittelbar sichtbar fremde inserts sind NACH COMMIT sichtbar Die Reihenfolge wird IMMER gepflegt Wenn die „current row“ „updated“, der Cursor vor die „next row“der ursprünglichen Position „positioned“ wurde und es keine „current row“ gibt SQLCODE -244 indicates that the sensitivity option specified on FETCH conflicts with the sensitivity option in effect for cursor cursor-name. If a cursor is declared INSENSITIVE, the FETCH statement can only specify INSENSITIVE or nothing. If a cursor is declared SENSITIVE, the FETCH statement can specify INSENSITIVE, SENSITIVE, or nothing. This is as in DB2 V7. The restriction in DB2 V8 is that the keyword INSENSITIVE is not allowed with the FETCH statements if the associated cursor is either: Declared as SENSITIVE DYNAMIC SCROLL, or Declared ASENSITIVE, and DB2 selects the maximum allowable sensitivity of SENSITIVE DYNAMIC SCROLL for the associated SELECT statement. Since there is no temporary result table, there are no holes except in the case of the current row. An SQLCODE +231 is returned if FETCH CURRENT or FETCH RELATIVE +0 is requested, but the row on which the cursor is positioned has been deleted or the row has been updated so that it no longer meets the selection criteria. This situation can only occur when using ISOLATION (CS) and CURRENTDATA(NO), which allows the row to be retrieved without taking a lock. The order is always maintained. If a column for an ORDER BY clause is updated, then the next FETCH statement behaves as if the updated row were deleted and re-inserted into the result table at its correct location. At the time of a positioned update, the cursor is positioned before the next row of the original location and there is no current row, making the row appear to have moved. If the row is deleted and the next cursor operation is FETCH CURRENT, a warning SQLCODE +231 is raised.

13 Neue AP Funktionen 3.1.8 Locking bei Dynamic Scrollable Cursors
ISOLATION CS ist empfohlen („maximum concurrency“) RR / RS behindern „updates“ durch andere User auf die Tabelle, in diesem Fall sollte man SENSITIVE DYNAMIC vermeiden Lock wird auf die „current row“ gesetzt, da die „base table“ immer direkt zugegriffen wird Wie schon immer wird die ISOLATION UR als BIND Option auf CS angehoben, wenn das SELECT … FOR UPDATE OF… enthält Normalerweise werden, falls der Cursor mit WITH HOLD definiert wurde, die Locks zum Zeitpunkt COMMIT freigegeben, ausser der Parameter DSNZPARM RELCURHL=NO ist gesetzt. „Optimistic locking“ wird bei „static scrollable cursors“ angewendet „Static scrollable cursors“ – keine Locks auf die „base tables“ nach OPEN CURSOR „Check at update time“ KEIN „Optimistic locking“ bei „dynamic scrollable cursors“ (wie bei „non-scrollable cursors“) Positioned UPDATE und DELETE sind IMMER erlaubt, wenn der Cursor nicht „read-only“ und ein „page“- oder „row“- Lock erfolgreich angefordert ist DB2 cannot use optimistic concurrency control for dynamic scrollable cursors, as it is working against the real table. For updateable dynamic scrollable cursors that use ISOLATION(CS), DB2 holds row or page lock on the current row in the base table (DB2 does not use a temporary global table when using dynamic scrollable cursors). The most recently fetched row or page from the base table is locked to maintain data integrity for a positioned update or delete. Optimistic concurrency control - review For packages and plans that contain updateable static scrollable cursors, ISOLATION(CS) lets DB2 use optimistic locking. DB2 can use optimistic concurrency control to shorten the amount of time that locks are held in the following situations: Between consecutive FETCH operations Between FETCH operations and subsequent positioned UPDATE or DELETE operations Optimistic locking control consists of the following steps: 1. When the application opens the static scrollable cursor, DB2 fetches the qualifying rows into the DTT. When doing so, DB2 will try to use lock avoidance to minimize the amount of locking required. 2. When the application requests a positioned update or delete operation on the row, DB2 performs the following steps: a. Finds the corresponding row in the base table. b. Locks the row. c. Re-evaluates the predicate to ensure that the row still qualifies for the result table. d. For columns that are in the result table, compares current values in the row to the values of the row when step 1 was executed. DB2 performs the positioned update or delete operation only if the values match. However, as mentioned at the beginning of this section, optimistic locking cannot be used for dynamic scrollable cursors. Read-only cursors - review If the result table is read-only, the cursor is read-only. The result table is read-only if one or more of the following statements is true about the SELECT statement of the cursor: The first FROM clause identifies or contains any of the following items: – More than one table or view – A catalog table with no updateable columns – A read-only view – A nested table expression – A table function – A system-maintained materialized query table The first SELECT clause specifies the keyword DISTINCT, contains an aggregate function, or uses both. The SELECT statement of the cursor contains an INSERT statement. The outer subselect contains a GROUP BY clause, a HAVING clause, or both clauses. It contains a subquery such that the base object of the outer subselect, and of the subquery, is the same table. Any of the following operators or clauses are specified: – A UNION or UNION ALL operator – An ORDER BY clause (except when the cursor is declared as SENSITIVE STATIC scrollable) – A FOR FETCH ONLY or a FOR READ ONLY clause It is executed with isolation level UR and a FOR UPDATE clause is not specified.

14 Neue AP Funktionen 3.1.9 Scrollable Cursor – FETCH(Beispiele)
Absolute Cursorbewegung: FETCH ... ABSOLUTE + 5 FROM curs1; oder MOVE 5 TO cursor-position FETCH ... ABSOLUTE :cursor-position FROM curs1 Relative Cursorbewegung: FETCH ... RELATIVE - 5 FROM curs1; oder MOVE -5 TO cursor-move FETCH ... RELATIVE :cursor-move FROM curs1 FETCH ... NEXT FROM curs1; Neue FETCH – „keywords“ NEXT, PRIOR, FIRST, LAST, CURRENT, BEFORE, AFTER, ABSOLUTE, RELATIVE

15 Neue AP Funktionen 3.2.5 Dynamic Scrollable Cursor –Beispiele
DECLARE ORDERSCROLL SENSITIVE DYNAMIC SCROLL CURSOR FOR SELECT ORDERNUM, CUSTNAME, ORDERAMT, ORDERDATE FROM ORDERS WHERE ORDERAMT > 1 FOR UPDATE OF COMMENTS; ** Open scrollable cursor OPEN ORDERSCROLL; ** Fetch forward from scrollable cursor ** LOOP-TO-FILL SCREEN DO 3 TIMES FETCH FROM ORDERSCROLL INTO :hv1, :hv2, :hv3, :hv4; END ** Fetch RELATIVE from scrollable cursor ** Skip forward 1 row FETCH RELATIVE +1 FROM ORDERSCROLL INTO :hv1, :hv2, :hv3, :hv4; ** Skip backward 5 rows FETCH RELATIVE -5 FROM ORDERSCROLL INTO :hv1, :hv2, :hv3, :hv4; This visual shows some SQL statements using dynamic scrollable cursors that you can embed in your programs. Cursor positioning and serialization At OPEN CURSOR time, the cursor is positioned before the first row. After FETCH, the fetched row becomes the current row and the cursor is positioned on this row. At this point, the UPDATE or DELETE WHERE CURRENT OF statement operates on the current row under the existing rules of positioned updates and deletes. When FETCH returns an EOF condition (SQLCODE +100), the cursor is positioned after the last row if the scroll number is positive (or FETCH NEXT is executed), and the cursor is positioned before the first row if the scroll number is negative (or FETCH PRIOR is executed). With an updateable dynamic scrollable cursor, the most recently fetched row from the base table remains locked in order to maintain its position for a positioned UPDATE or positioned DELETE (in case FOR UPDATE OF is specified on the cursor definition).

16 Neue AP Funktionen 3.1.9 Dynamic Scrollable Cursor –Beispiele (Cont‘ned) ** Fetch ABSOLUTE from scrollable cursor ** Re-read the third row FETCH ABSOLUTE + 3 FROM ORDERSCROLL INTO :hv1, :hv2, :hv3, :hv4; ** Fetch RELATIVE from scrollable cursor ** Read the third row from the current position FETCH SENSITIVE RELATIVE +3 FROM ORDERSCROLL INTO :hv1, :hv2, :hv3, :hv4; ** Execute a positioned UPDATE through scrollable cursor ** Update the current row UPDATE ORDERS SET COMMENTS = "Expedite" WHERE CURRENT OF ORDERSCROLL; ** Close the scrollable cursor CLOSE ORDERSCROLL; The visual shows some SQL statements using dynamic scrollable cursors that you can embed in your programs. Note that when you declare the cursor as dynamic scrollable, and SQLCODE +100 is returned, you can continue to FETCH rows. However, once end of file is reached, FETCH NEXT will always give +100; that is, once you get SQLCODE +100, do not expect to see rows inserted after the last successful fetch (prior) to +100, and similarly for FETCH PREVIOUS. Once you get a +100, if you want to continue fetching, you need to reposition via FETCH FIRST/LAST, etc.

17 Neue AP Funktionen Cursor Typ Result Table
Dynamic Scrollable Cursor – ein Vergleich Cursor Typ Result Table Eigene Än-derungen sichtbar ? Fremd-Än-derungen sichtbar ? Update-Fähigkeit Non-Scrollable (SQL mit JOIN, Sort usw.) Non-Scrollable INSENSITIVE SCROLL SENSITIVE STATIC SCROLL DYNAMIC SCROLL No Yes Keine INSERT‘s Fixed, workfile no workfile, „base table access“ Fixed, declared temp table No declared temp table, „base table access“ The visual shows some SQL statements using dynamic scrollable cursors that you can embed in your programs. Note that when you declare the cursor as dynamic scrollable, and SQLCODE +100 is returned, you can continue to FETCH rows. However, once end of file is reached, FETCH NEXT will always give +100; that is, once you get SQLCODE +100, do not expect to see rows inserted after the last successful fetch (prior) to +100, and similarly for FETCH PREVIOUS. Once you get a +100, if you want to continue fetching, you need to reposition via FETCH FIRST/LAST, etc.

18 „Scrollable cursor“ sind erlaubt:
Neue AP Funktionen Dynamic Scrollable Cursor – ein Vergleich „Scrollable cursor“ sind erlaubt: „Scrollable cursor“ sind nicht erlaubt für: „static“ und „dynamic“ OS/390 compiled programs compiled stored procedures (inklusive „SQL stored procedures“) ODBC   SPUFI und QMF REXX Programme Java Programme „client“ Programme mit DB2 Connect

19 Neue AP Funktionen 3.2 SQL/PL Funktionen für STP‘s Vorteil .....
Verbessert die Nutzbarkeit und „power“ der „SQL procedure language“ (PSM) DB2 Family Kompatibilität Konform zu den SQL Standards V8 Verbesserungen Neue SQL „procedure statements“ zur Übergabe von STATUS Informationen von der SQL Procedure an die rufende Applikation RETURN Statement SIGNAL/RESIGNAL Unterstützung GET DIAGNOSTICS ITERATE Verbesserte LOB und Variablen Unterstützung mit V8 SQL Statement Limit Erweiterung auf 2MB Integrierter „debugger“ DB2 Version 8 introduces many enhancements to SQL stored procedures, sometimes called PSM (Persistent Stored Modules). Numerous enhancements were introduced to enhance DB2 Family compatibility and conformance to the SQL standards. This will help people to port existing SQL stored procedures to the zSeries platform. These enhancements are discussed in more detail in the following sections: RETURN statement SIGNAL/RESIGNAL support GET DIAGNOSTICS support ITERATE statement support Enhanced LOB and variable support Long SQL statements (up to 2 MB) Support for using the integrated debugger with SQL stored procedures

20 Neue AP Funktionen 3.2 SQL/PL Funktionen für STP‘s - RETURN
Für eine SQL Procedur wird ein Statuswert im INTEGER Format an die aufrufende Applikation zurückgegeben Der „caller ´kann diesen Wert erhalten über: RETURN_STATUS aus GET DIAGNOSTICS Direkt aus der SQLCA in SQLERRD[0] Return des „value parameter markers“ in der „escape Klausel“ der CALL Syntax in CLI oder ODBC Applikationen Zusätzliche GET DIAGNOSTICS Information MESSAGE_TEXT Klausel enthält den aktuellen Meldungstext MESSAGE_LENGTH Klausel enthält die Länge der aktellen Meldung Für SQL „scalar functions“, wird das Resultat der Funktion (V7) zurückgeliefert DB2 Version 8 introduces many enhancements to SQL stored procedures, sometimes called PSM (Persistent Stored Modules). Numerous enhancements were introduced to enhance DB2 Family compatibility and conformance to the SQL standards. This will help people to port existing SQL stored procedures to the zSeries platform. These enhancements are discussed in more detail in the following sections: RETURN statement SIGNAL/RESIGNAL support GET DIAGNOSTICS support ITERATE statement support Enhanced LOB and variable support Long SQL statements (up to 2 MB) Support for using the integrated debugger with SQL stored procedures Return Value = 0 wenn erfolgreich, und -2 wenn nicht BEGIN .... GOTO FEHLER; SUCCESS: RETURN; FEHLER: RETURN -2 END;

21 Neue AP Funktionen 3.2 SQL/PL Funktionen für STP‘s – SIGNAL/RESIGNAL
DECLARE EXIT HANDLER FOR SQLSTATE VALUE ‘23503’ SIGNAL SQLSTATE ‘75001’ SET MESSAGE_TEXT = ‘Customer is unknown’; INSERT INTO ORDERS (....) VALUES (....); CREATE PROCEDURE SUBMIT_ORDER (IN ONUM INTEGER, IN CNUM INTEGER, IN PNUM INTEGER, IN QNUM INTEGER) LANGUAGE SQL MODIFIES SQL DATA BEGIN DECLARE EXIT HANDLER FOR SQLSTATE VALUE '23503' SIGNAL SQLSTATE '75002' SET MESSAGE_TEXT = 'Customer number is not known'; INSERT INTO ORDERS (ORDERNO, CUSTNO, PARTNO, QUANTITY) VALUES (ONUM, CNUM, PNUM, QNUM); END Sample usage of the SIGNAL statement In the figure above, we provide a small example of the usage of the SIGNAL statement. Assume that a PK-FK relationship exists between ORDERS and CUSTOMERS. SQLSTATE indicates that there is no entry in the PK table (customers) for the FK table (ORDERS) row that we are inserting. Instead of returning SQLSTATE 23503, we return an SQLSTATE 75002, and a helpful message, “Customer number is not known”. Note: The SQLSTATE ‘value’ can be both an sqlstate-string-constant, as in the visual above, or an SQL variable-name, declared within the compound-statement. The value of the SQL variable has to be a valid 5-byte SQLSTATE.

22 Neue AP Funktionen 3.2 SQL/PL Funktionen für STP‘s – SIGNAL/RESIGNAL
CREATE PROCEDURE divide ( IN numerator INTEGER, IN denominator INTEGER, OUT divide_result INTEGER) LANGUAGE SQL CONTAINS SQL BEGIN DECLARE overflow CONDITION FOR SQLSTATE '22003'; DECLARE EXIT HANDLER FOR overflow RESIGNAL SQLSTATE '22375'; IF denominator = 0 THEN SIGNAL overflow; ELSE SET divide_result = numerator / denominator; END IF; END The RESIGNAL statement is (only) used inside a handler. It can be used to change a previously encountered SQLSTATE into a new one (that is more meaningful in the context, or is specific to a certain product).You can use the RESIGNAL command within the body of an handler as shown in Example. Example Using RESIGNAL DECLARE OVERFLOW CONDITION FOR SQLSTATE VALUE ‘22003’; DECLARE EXIT HANDLER FOR OVERFLOW RESIGNAL SQLSTATE ‘22375’ SET MESSAGE_TEXT ‘Attempt to divide by zero’; Note that when you use RESIGNAL (or SIGNAL) to set the SQLSTATE, the value of SQLCODE returned to the invoking application is a constant (you cannot set it) based on the class code (first 2 bytes) of the SQLSTATE: Class code 00 is not allowed Class code 00 or 01 causes SQLCODE +438 All other class codes cause SQLCODE -438 As with the SIGNAL statement, you can also provide a message text. The provided message text is returned in the SQLCA SQLERRMC field (up to 70 bytes), or the full message can be obtained by using the MESSAGE_TEXT clause on the GET DIAGNOSTICS statement. Benutzt, um innerhalb eines Handlers eine „exception“ erneut anzuzeigen Erzeugt einen „error/warning“ mit einem vorgegebenen SQLSTATE und einem optionalen Meldungstext SQLSTATE kann einen eigenen Wert enthalten (Klasse '01' oder '02‚) Ein optionaler MESSAGE_TEXT ist erlaubt

23 Neue AP Funktionen 3.2 SQL/PL Funktionen für STP‘s – SIGNAL/RESIGNAL
ITERATE Statement nun auch in DB2 for z/OS (V8) möglich Already supported in DB2 for iSeries and DB2 for LUW Das ITERATE Statement veranlasst das Programm an den Beginn eines „labeled loop“ zurückzukehren Das label muss ein FOR, LOOP, REPEAT oder WHILE Statement markieren ITERATE ist ab jetzt ein „reserved word“ in SQL Statements Beispiel: ins_loop: LOOP FETCH hv_dept... IF hv_dept ^='D11' THEN ITERATE ins_loop; ELSEIF ... CREATE PROCEDURE ITERATOR () LANGUAGE SQL MODIFIES SQL DATA BEGIN DECLARE v_dept CHAR(3); DECLARE v_deptname VARCHAR(29); DECLARE v_admdept CHAR(3); DECLARE at_end INTEGER DEFAULT 0; DECLARE not_found CONDITION FOR SQLSTATE ; DECLARE c1 CURSOR FOR SELECT deptno,deptname,admrdept FROM department ORDER BY deptno; DECLARE CONTINUE HANDLER FOR not_found SET at_end = 1; OPEN c1; ins_loop: LOOP FETCH c1 INTO v_dept, v_deptname, v_admdept; IF at_end = 1 THEN LEAVE ins_loop; ELSEIF v_dept = 'D11' THEN ITERATE ins_loop; END IF; INSERT INTO department (deptno,deptname,admrdept) VALUES('NEW', v_deptname, v_admdept); END LOOP; CLOSE c1; END

24 Neue AP Funktionen 3.3 Stored Procedures und UDF Verbesserungen
Angabe der maximalen Anzahl von Fehlern für eine STP Granulare Kontrolle über STP‘s und UDF‘s Fehlermanagement User kann für jede „stored procedure“ oder „user-defined function“ festlegen, wie oft eine Routine Fehler haben kann, bevor sie gestoppt wird Festgelegt auf „routine level“, anstatt auf „subsystem level“ (MAX ABEND COUNT - DSNZPARM STORMXAB) Spezifiziert beim CREATE/ALTER FUNCTION/PROCEDURs (STOP AFTER SYSTEM DEFAULT FAILURES, STOP AFTER n FAILURES, CONTINUE AFTER FAILURE Nicht für originäre und „SQL scalar UDFs“ Besseres WLM Ressource Management für „stored routines“ Besseres „resource management“ durch Ausnutzen der Möglichkeiten des z/OS „workload managers“ WLM entscheidet selbst über die Ressourcennnutzung und empfiehlt Änderungen in der „task“-Anzahl für den SPAS TCBs werden aufgrund dieser WLM-Empfehlungen hinzugefügt/entfernt Attach eines neuen TCB ist billiger als einen neuen „address space“ zu starten MAXTCB definiert hierzu das Maximum Empfehlung: Angabe einer hohen Zahl in MAXTCB und WLM erledigt den Rest Specify maximum failures at stored routine level In V7, you have a DB2 DSNZPARM called STORMXAB that allows you to specify the number of times a stored procedure or an invocation of a user-defined function is allowed to terminate abnormally, after which SQL CALL statements for the stored procedure or user-defined function are rejected. As it is a DSNZPARM, the value applies to all stored routines. In V8, you can specify that a stored routine is to be put in a stopped state after some number of failures, at the stored routine level. Next we list the SQL statement options you can use to do this. STOP AFTER nn FAILURES Specifies that this routine should be placed in a stopped state after nn failures. The value nn should be an integer from 1 to STOP AFTER SYSTEM DEFAULT FAILURES Specifies that this routine should be placed in a stopped state after the number of failures indicated by the system parameter MAX ABEND COUNT (DSNZPARM STORMXAB). This is the default. CONTINUE AFTER FAILURE Specifies that this routine should not be placed in a stopped state after any failure. These options must not be specified for SQL functions, or sourced functions (SQLSTATE 42849, SQLCODE ). To support this enhancement, a new column MAX_FAILURE is added to the SYSIBM.SYSROUTINES catalog table, where: nn Specifies the allowable failures for this routine before it is stopped. The value nn can be an integer from 1 to -1 Indicates that the DB2 DSNZPARM STORMXAB is used. 0 (zero) If zero is specified, the routine will never be stopped.

25 3. Neue AP Funktionen 3.3 Stored Procedures – Verbesserungen(Was bleibt) „scrollable cursor“ in STP‘s sind immer READ-ONLY Können aber dennoch STATIC SENSITIVE definiert werden . main() { EXEC SQL BEGIN DECLARE SECTION; char hv_account[30]; char hv_acctname[30]; EXEC SQL END DECLARE SECTION; static volatile SQL TYPE IS RESULT_SET_LOCATOR *CRTPROCS_rs_loc; EXEC SQL CALL SET_CURSOR_ACCOUNT_C1('P'); if (sqlca.sqlcode != 0) prt_sqlc(); EXEC SQL ASSOCIATE LOCATOR( :CRTPROCS_rs_loc ) WITH PROCEDURE PAOLOR2.CRTPROCS; EXEC SQL ALLOCATE C1 CURSOR FOR RESULT SET :CRTPROCS_rs_loc; EXEC SQL FETCH C1 INTO :hv_account, :hv_account_name; EXEC SQL CLOSE C1; #pragma linkage(cfunc, fetchable) #include <stdlib.h> void cfunc(char parm1[2]) { EXEC SQL BEGIN DECLARE SECTION; char hv_type[2]; EXEC SQL END DECLARE SECTION; strcpy(parm1, hv_type); EXEC SQL DECLARE C1 INSENSITIVE SCROLL CURSOR WITH HOLD WITH RETURN FOR SELECT ACCOUNT, ACCOUNT_NAME FROM ACCOUNT WHERE TYPE = :hv_type FOR UPDATE OF ACCOUNT_NAME; OPEN C1; } Stored procedure

26 3. Neue AP Funktionen 3.3 Stored Procedures und UDF Verbesserungen
LANGUAGE COMPJAVA stored procedures COMPJAVA nutzt HPJ (High Performance Java compiler) VA Java unterstützt keine „compiled Java link library files“ mehr No longer supported in V8 Stattdessen Nutzung der LANGUAGE JAVA Mit besserer Performance Unterdrücken von DB2-gesteuerten „stored procedures“ Kein CREATE von neuen „DB2-established stored procedures“ in V8 Nach Entfernen der 'NO WLM ENVIRONMENT' Option SQLCODE -199 Bestehende „DB2-established stored procs“ laufen weiter Nach ALTER PROC auf „WLM-managed“ kein ALTER zurück mehr Empfehlung: Migration aller „stored procs“ auf „WLM managed“ In this section we discuss two changes that may affect your existing stored procedures. In V8: COMPJAVA stored procedures are no longer supported You cannot create new DB2-established stored procedures, or alter stored procedures to become DB2-established stored procedures. 8.2.1 LANGUAGE COMPJAVA stored procedures no longer supported As the HPJ (High Performance Java) compiler is no longer supported, DB2 can no longer support LANGUAGE COMPJAVA stored procedures, and V8 does not allow you to run or create LANGUAGE COMPJAVA stored procedures. 8.2.2 Deprecation of DB2-established stored procedures DB2 Version 8 removed the “NO WLM ENVIRONMENT” option on the CREATE PROCEDURE statement. This means that you can no longer create any new DB2-established (sometimes also called DB2-managed) stored procedures in V8. However, if you have existing DB2-established stored procedures, they continue to run in V8. You just cannot create any new ones (or alter WLM-managed stored procedures back to DB2-managed). Therefore the recommendation is to convert to WLM-managed stored procedures as soon as possible.

27 3. Neue AP Funktionen 3.4 Neue Spezialregister
Client information die jeweilige connection über sqleseti, Java, RRS SIGNON CURRENT CLIENT_ACCTNG -- „accounting string“ CURRENT CLIENT_APPLNAME -- „application name“ CURRENT CLIENT_USERID -- „client user ID“ CURRENT CLIENT_WRKSTNNAME -- „workstation name“ Spezialregister für MQT‘s CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION CURRENT REFRESH AGE Spezialregister für Applikationen CURRENT PACKAGE PATH CURRENT SCHEMA Four new special registers are added. These special registers are CURRENT CLIENT_ACCTNG, CURRENT CLIENT_APPLNAME, CURRENT CLIENT_USERID, and CURRENT CLIENT_WRKSTNNAME. The information is provided through a number of application programming interfaces. These special registers were also added to DB2 for Linux, UNIX, and Windows V8, and so provide for DB2 family compatibility. For more information about the CURRENT PACKAGE PATH special register, see “CURRENT PACKAGE PATH special register”. Another new special register is CURRENT SCHEMA. The CURRENT SCHEMA, or equivalently CURRENT_SCHEMA, special register specifies the schema name used to qualify unqualified database object references in dynamically prepared SQL statements. The data type is VARCHAR(128). The usage of CURRENT SCHEMA is described in more detail in “SET [CURRENT] SCHEMA”.

28 3. Neue AP Funktionen 3.4.1 SET CURRENT PACKAGESET
Problem: CURRENT SQLID als impliziter Qualifier für „dynamic SQL“ CURRENT SQLID betrifft u.a. die „authorization“: CURRENT SQLID muß für „dynamic“ CREATE, ALTER, GRANT REVOKE authorisiert werden CURRENT SQLID muß eine „primary / secondary auth ID“ sein (außer bei SYSADM / SYSCTRL) Static SQL nutzt deshalb die BIND Option „QUALIFIER“ gilt für „unqualified SQL“ Lösung: SET SCHEMA / CURRENT SCHEMA Spezialregister für „dyn SQL“ CURRENT SCHEMA ist ein Spezialregister mit VARCHAR(128) und demselben Wert wie CURRENT SQLID zum Zeitpunkt der Initialisierung Verlangt SET SCHEMA zum Ändern Kann jeden beliebigen Wert annnehmen (nicht begrenzt auf „primary /secondary auth ID“ wie CURRENT SQLID) Customers often run applications with different qualifiers in effect for unqualified names, without having to have separate copies of the application code itself. They then deploy theapplication in different environments (sometimes on the same DB2 subsystem) without have to change any of the application code. With DB2 for z/OS and OS/390 V7, an application can be coded without qualifiers for objectnames (also known as unqualified SQL), and an implicit qualifier will be used for unqualified names. For static SQL statements, the DB2 QUALIFIER option for BIND can be used, to specify theimplicit qualifier for unqualified object names (except for those contexts which use the SQL PATH to resolve the name of an object). The QUALIFIER bind option affects the implicit qualification of unqualified object names. If the QUALIFIER bind option is not specified, the OWNER of the plan or package is used as the implicit object qualifier for static SQL statements. For dynamic SQL statements, the CURRENT SQLID special register can be used to specify the implicit qualifier for unqualified object names (except for those contexts which use the SQL PATH to resolve the name of an object). However, unlike the QUALIFIER bind option, the use of the CURRENT SQLID special register has other effects, as it is also used for authorization checking on dynamic CREATE, ALTER, GRANT, and REVOKE statements, and the value is also used as the owner (or definer) of objects created with dynamic CREATE statements. The current (V7) support for specifying an implicit qualifier for dynamic SQL statements (CURRENT SQLID) is not quite the same as the support for static SQL statements (the QUALIFIER bind option). The bundling of qualification of object name with the authorization checking, and ownership of objects is not an ideal solution for dynamic SQL statements. Again DB2 for z/OS Version 8 comes to the rescue. V8 introduces a new SET (CURRENT) SCHEMA SQL statement, and a new special register CURRENT SCHEMA. It is only used to qualify object names in unqualified dynamic SQL statements (when DYNAMICRULES(RUN) are in effect, the default). The CURRENT SCHEMA special register is initialized with the value of the CURRENT SQLID at initialization time. You can then change it in your application using the SET SCHEMA SQL statement. You can set the CURRENT SCHEMA special register to any valid string (as long as the string you provide is a VARCHAR(128)). This is different from changing the CURRENT SQLID. There you have to specify you your primary authorization ID or one of your secondary authorization IDs (unless you are SYSADM or SYSCTRL). The CURRENT SCHEMA special register is only used for qualifying unqualified SQL in your program, nothing else. Setting the CURRENT SCHEMA special register does not affect any other special register. Therefore, the CURRENT SCHEMA is not to be included in the SQL path that is used to resolve the schema name for unqualified references to function, procedures, and user-defined types in dynamic SQL statements. To include the current schema value in the SQL path, whenever the SET SCHEMA statement is issued, also issue the SET PATH statement including the schema name from the SET SCHEMA statement. When the name of the object to be created is specified as an unqualified name, in case of a dynamic CREATE statement, the value of CURRENT SCHEMA must be the same as the CURRENT SQLID special register. Otherwise an SQLCODE is issued,

29 3. Neue AP Funktionen 3.4.2 SET CURRENT PACKAGEPATH Wozu ? .....
Zur Auflösung von „packages“ (collection) Bedeutet für Applikationen, dass sie eine „collection list“ für den DB-Server spezifizieren können, nach der eine Suchreihenfolge vorgegeben ist (ähnlich zu PKLIST im BIND PLAN) DB Server können die Liste durchsuchen und das erste „package“, das den gesuchten Namen aufweist benutzen Kontrolle für Anwendungsprogramme, die nicht unter einem DB2 Plan laufen Vorteile ..... Vermindern des „network traffic“ und Verbesserung der „CPU/elapsed time“ für AP Ermöglicht die Implementierung von „nested procedures“, „user-defined functions“ ohne Rücksicht auf das rufende „runtime environment“ und erlaubt die Spezifikation mehrerer „collections“ Einfacherer „switch“ zwischen JDBC und SQLJ CURRENT PACKAGE PATH is a new special register in DB2 V8. It it used when DB2 is looking for a matching package (same name, version number as in the invoking program) to load. Today, plans have the possibility of specifying a search sequence of collections for DB2 to look in to find a matching package, via the PKLIST BIND option. Today in V7, there is no PKLIST option for applications that do not run under a DB2 plan. With the CURRENT PACKAGE PATH special register, DB2 V8 introduces a way for the application to specify a list of collections for DB2 to look for a certain package. This enhancement is especially important for SQLJ applications to provide a list of collections to look for a matching package. The advantage of the CURRENT PACKAGE PATH is that it contains a list of collections. This is in contrast to the CURRENT PACKAGESET special register that can only contain the name of a single collection. In the case where the package is not found in that collection, the application has to change the CURRENT PACKAGESET special register and try again. By using CURRENT PACKAGE PATH, you can specify a list of collections for DB2 to look in to find the package. Only after all collections have been searched unsuccessfully, is an SQLCODE -805 returned. This can be especially important in a distributed environment where every time you need to change the CURRENT PACKAGESET special register, it requires a trip across the wire. Because the CURRENT PACKAGE PATH can contain a list of collections, only a single trip is required.

30 3. Neue AP Funktionen 3.4.2 SET CURRENT PACKAGEPATH
USER, CURRENT PACKAGE PATH, und CURRENT PATH können nur EINMAL angegeben werden Man beachte, dass man den bestehenden CURRENT PACKAGE PATH angeben kann und zusätzliche „collections“ vorn / hinten anfügen kann SET :oldCPP = CURRENT PACKAGE PATH; SET CURRENT PACKAGE PATH = CURRENT PACKAGE PATH, prodcoll ; CALL PRODSP (:hv1, :hv2); SET CURRENT PACKAGE PATH = :oldCPP; The SET CURRENT PACKAGE PATH statement assigns a value to the CURRENT PACKAGE PATH special register. The statements must be embedded in an application. It is an executable statement that cannot be dynamically prepared. The CURRENT PACKAGE PATH is a VARCHAR(4096) value. No validation that the collections exist is made at the time that the CURRENT PACKAGE PATH special register is set. For example, a collection ID that is misspelled is not detected, and this could affect the way subsequent SQL operates. At package execution time, authorization to the specific package is checked, and if this authorization check fails, the next collection is checked. The SET CURRENT PACKAGE PATH statement is executed by the database server to which the application is currently connected, and is therefore classified as a non-local SET statement in DRDA. The SET CURRENT PACKAGE PATH statement requires a new level of DRDA support: If the application is connected to the local server when the SET CURRENT PACKAGE PATH statement is issued, the CURRENT PACKAGE PATH special register at the local server is set. Otherwise, when the application is connected to a remote server when the SET CURRENT PACKAGE PATH is issued, the CURRENT PACKAGE PATH special register at the remote server is set.

31 3. Neue AP Funktionen 3.4.2 SET CURRENT PACKAGEPATH - Beispiele
CURRENT PACKAGE PATH and stored procedures and UDFs When a stored procedure calls another program, DB2 determines to which collection the called program’s package belongs, in one of the following ways: If the stored procedure executes SET CURRENT PACKAGE PATH, the called program’s package comes from the list of collections in the CURRENT PACKAGE PATH special register. For example, if CURRENT PACKAGE PATH contains the list COLL1, COLL2, COLL3, COLL4, then DB2 searches for the first package (in the order of the list) that exists in these collections. If the stored procedure does not execute SET CURRENT PACKAGE PATH and instead executes SET CURRENT PACKAGESET, the called program’s package comes from the collection that is specified in the CURRENT PACKAGESET special register. If the stored procedure does not execute SET CURRENT PACKAGE PATH or SET CURRENT PACKAGESET: – If the stored procedure definition contains NO COLLID, DB2 uses the collection ID of the package that contains the SQL statement CALL. – If the stored procedure definition contains COLLID collection-id, DB2 uses collection-id.

32 Neue AP Funktionen 3.5 Neue ODBC Funktionen
Gemeint ist ODBC für Programme unter UNIX System Services on z/OS (USS) Userid und Passwort Authentikation („validation“, nicht nur „syntax checking“) beim SQLConnect und SQLDriverConnect ODBC Unterstützung für lange Namen (auch in den INI-Files) ODBC Unterstützung für SQL Statements bis zu 2 MB SQLCancel() Support ODBC Unicode Support Update, insert, delete und fetch von Unicode Daten durch ODBC Applikationsvariable Unicode Strings innerhalb des „ODBC application programming interface“ (ermöglicht Unicode SQL Statements in der ODBC-Applikation)

33 Neue AP Funktionen 3.6 RRSAF Funktionen
Ermöglicht RRSAF Applikationen „implicit connections“ auf DB2 for z/OS zu erkennen und zu nutzen Ähnlich dem „implicit connection support“ in CAF Heute gibt es ausschließlich „explicit RRSAF connections“ Man muß IDENTIFY, CREATE THREAD, SIGNON absetzen, um eine „database connection“ aufbauen zu können Ebenso: TERMINATE THREAD - TERMINATE IDENTIFY um sie zu beenden V8 implicit RRSAF connection eine SQL Statement und IFI Calls reichen aus RRSAF baut die „connection“ auf Der verwendete Subsystem Name hängt ab von der SSID in DSNHDECP Der Planname hängt ab vom DBRM, das den ersten SQL Call absetzt Die „Authorization ID“ ist die des „address space“ oder ACEE (falls vorhanden) With this enhancement, DB2 applications using RRSAF (RRS attach facility) can make implicit connections to DB2, simply by including SQL statements or IFI calls. RRSAF will make the required connection to DB2. Comparing with CAF A CAF (call attach facility) application can use two ways to connect to DB2, using an explicit, or an implicit connection. When using an explicit connection, you issue a CONNECT and OPEN to connect to the DB2. To disconnect, you issue a CLOSE and DISCONNECT. When using an implicit connection, a CAF application just issues SQL statements or IFI calls. CAF establishes the implicit connection to DB2 using default values for subsystem name (from DSNHDECP) and plan name (DBRM name associated with the first SQL call). In V7, a RRSAF application can only use explicit connections. It issues an IDENTIFY, optionally a SIGNON, and a CREATE THREAD. To end a connection explicitly, you use TERMINATE THREAD, TERMINATE IDENTIFY. This enhancement changes RRSAF to allow the application to implicitly connect, just by issuing SQL statements or IFI calls (similar to CAF). When an implicit connect is requested, RRSAF will issue an IDENTIFY and CREATE THREAD using default values for the subsystem name and the plan name. The default value for the subsystem name is the name specified by the SSID parameter in DSNHDECP. RRSAF uses the installation default DSNHDECP, unless your own DSNHDECP is in a library provided in a STEPLIB or JOBLIB concatenation, or in the link list. In a data sharing group, the default subsystem name is the group attachment name. The default value for the plan name will be the name of the database request module (DBRM) associated with the module making the (first) SQL call. If your program can make its first SQL call from different modules with different DBRMs, then you cannot use a default plan name. You must use an explicit call using the CREATE THREAD function. The authorization ID is set from the 7-byte user ID associated with the address space, unless an authorized function has built an ACEE for the address space. If an authorized function has built an ACEE, DB2 passes the 8-byte user ID from the ACEE. If your application includes both SQL and IFI calls, you must issue at least one SQL call before you issue any IFI calls. This ensures that your application uses the correct plan, as described above for the plan name. As before, you must make sure the RRSAF language interface load module, DSNRLI is available.

34 Neue AP Funktionen 3.7 Neue XML Funktionen
For the past few years, XML has been increasingly become the de facto data format on the Internet, on corporate intranets, and for data exchange. In DB2 UDB for OS/390 and z/OS V7, if you need to create XML data from traditional relational databases (this is called XML publishing or XML composition), you must create your own application that converts the DB2 data to the XML format, or use DB2 XML Extender. DB2 V8 provides you with an additional option. DB2 V8 contains a set of brand new built-in functions to help with XML publishing. These DB2 built-in functions reduce your application development efforts in generating XML data from relational data with high performance, and enable the development of lightweight applications. This set of built-in functions are part of a set of extensions to the SQL language, called SQL/XML. SQL/XML is an emerging standard, and is part of the ANSI and ISO SQL standard, describing the ways the database language SQL can be used in conjunction with XML. The definition of SQL/XML is driven in part by the SQLX Group, of which IBM is a very active member. The SQL/XML publishing functions are built-in DB2 functions. They run inside the DB2 address spaces, unlike external user-defined functions (UDFs) that run in a WLM managed address space outside of DB2, like the ones used by DB2 XML Extender. The fact that the XML publishing functions are built into the DB2 engine gives them better performance. In addition, much extra work has been done inside the DB2 engine, for example, to make the tagging as efficient as possible. Seven new built-in functions related to XML publishing can be used with DB2 V8: Cast function: – XML2CLOB Scalar functions: – XMLELEMENT – XMLATTRIBUTES – XMLFOREST – XMLCONCAT – XMLNAMESPACES Aggregate function: – XMLAGG Refer to the subsequent pages within this chapter for more information about how to use the new XML functions. The visual above shows the power of the SQL/XML functions. The XML query statement to generate this HTML table is shown in Example 5-9. Example...... Note that we use SQL/XML to generate the HTML tags necessary to be able to display the result of the query as an HTML table.

35 Neue AP Funktionen 3.7 Neue XML Funktionen
Sieben neue „built-in functions“ für XML „publishing“ gibt es in DB2 V8: Cast Funktion: – XML2CLOB Scalare Functionen: – XMLELEMENT – XMLATTRIBUTES – XMLFOREST – XMLCONCAT – XMLNAMESPACES Aggregate Funktion: – XMLAGG

36 Neue AP Funktionen 3.7 Neue XML Funktionen - Complex XML query example
SELECT VARCHAR( XML2CLOB( XMLElement(NAME "TABLE", XMLATTRIBUTES('1' as "border"), XMLElement(NAME CAPTION, 'Department-Employee Table'), XMLElement(NAME TR, XMLFOREST('Dept No' as TH, 'Dept Name' as TH, 'Emp No' as TH, 'Emp Name' as TH, 'Phone' as TH) ), XMLAGG( XMLCONCAT( XMLELEMENT(NAME TR, XMLELEMENT(NAME TD, XMLATTRIBUTES( X.CNT+1 as "rowspan"), D.DEPTNO), XMLELEMENT(NAME TD, D.DEPTNAME) ), ( SELECT XMLAGG(XMLElement(NAME TR, XMLForest(EMPNO as TD, FIRSTNME || ' ' || LASTNAME as TD, PHONENO as TD) ) ) FROM DSN8810.EMP E WHERE E.WORKDEPT = D.DEPTNO ) ) ) ) ) ) FROM DSN8810.DEPT D, (SELECT WORKDEPT, COUNT(*) FROM DSN8810.EMP GROUP BY WORKDEPT) X(DEPTNO, CNT) WHERE D.DEPTNO = X.DEPTNO AND D.DEPTNO IN ('A00', 'C01') Note that we use SQL/XML to generate the HTML tags necessary to be able to display the result of the query as an HTML table. These SQL/XML functions can be used instead of the XML publishing functions that are provided by DB2 XML Extender. The DB2 XML Extender publishing functions will still be available for you to use, but the SQL/XML functions provide more flexibility, and as they are built into the DB2 engine, they are likely to provide better performance. SQL/XML publishing functions can only be used to generate XML documents (or fragments) from data that is stored in relational tables. They cannot be used to store XML data in DB2 tables. For those functions, you need to use DB2 XML Extender’s XML collection and XML column functionality. The same is true for XML transformation functions. SQL/XML is not intended to be used for transformation. Again, you can use DB2 XML Extender for that purpose. As before, DB2 XML Extender ships as part of DB2 at no extra charge. Note: These SQL/XML functions do not require the XML Toolkit for z/OS.

37 Neue AP Funktionen 3.7 Neue XML Funktionen - XMLELEMENT
SELECT E.EMPNO,XML2CLOB( XMLELEMENT ( NAME "EMP", E.FIRSTNME||' '||E.LASTNAME ) ) AS "RESULT" FROM DSN8810.EMP E; EMPNO RESULT <EMP>CHRISTINE HAAS</EMP> <EMP>MICHAEL THOMPSON</EMP> <EMP>SALLY KWAN</EMP> <EMP>JOHN GEYER</EMP> The visual shows the syntax and a usage example of the XMLELEMENT built-in function. The XMLELEMENT function returns an XML element from one or more arguments. The arguments can be: An element name An optional collection of attributes Zero or more arguments that make up the element’s content. The result type is the transient XML data type. Let us now take a look at the components of the XMLELEMENT function: NAME: NAME keyword marks the identifier that is supplied to XMLELEMENT for the element name. XML-element-name: Specifies an identifier that is used as the XML element name. (No mapping is applied to this identifier.) XML-namespaces: Specifies the XML namespace for the XML element. See the XMLNAMESPACES function later in the chapter for details. XML-attributes: Specifies the attributes for the XML element. See the XMLATTRIBUTES function below. XML-element-content: Specifies an expression making up the XML element content. The expression cannot be: – A ROWID – A character string defined with the FOR BIT DATA attribute – A BLOB – A distinct type sourced on these types If the result of the expression is an SQL value, it is mapped to the XML value according to the mapping rules from an SQL value to an XML value ( “Mappings from SQL to XML”). If multiple XML-element-contents are specified, their XML values are concatenated to form the content of the XML element. If the result of an expression is a null value, it is not included in the concatenation result. If all the results of the arguments are the null value, then the result of XMLELEMENT is an element with empty content. The result of the XMLELEMENT function cannot be null. Refer to the SELECT statement shown on the visual for a short and simple example of the use of the XML2CLOB and XMLELEMENT function. As you can see in the SQL statement above, the XMLELEMENT function is used to create an element called EMP, which contains the concatenation of the contents of columns FIRSTNME and LASTNAME.

38 Neue AP Funktionen 3.7 Neue XML Funktionen - XMLATTRIBUTES
SELECT E.EMPNO,XML2CLOB( XMLELEMENT ( NAME "EMP", XMLATTRIBUTES( E.EMPNO, E.FIRSTNME||' '|| E.LASTNAME AS "NAME") ) ) AS "RESULT" FROM DSN8810.EMP E; EMPNO RESULT <EMP EMPNO="000010" NAME="CHRISTINE HAAS"></EMP> <EMP EMPNO="000020" NAME="MICHAEL THOMPSON"></EMP> <EMP EMPNO="000030" NAME="SALLY KWAN"></EMP> This function constructs XML attributes from the arguments. It can only be used as the second argument to the XMLELEMENT function. XML-attribute-value: Specifies the value of the attribute. This expression cannot be: – A ROWID – A character string defined with the FOR BIT DATA attribute – A BLOB – A distinct type sourced on these types, or XML The result of the expression is mapped to an XML value according to the mapping rules from an SQL value to an XML value. If the value is null, the corresponding XML attribute is not included in the XML element. AS XML-attribute-name: Specifies an identifier that is used as the attribute name. (No mapping is applied to map the identifier to an XML name.) If XML-attribute-name is not specified, the expression for XML-attribute-value must be a column name, and the attribute name will be created from the column name using the fully escaped mapping from a column name to an XML attribute name. Refer to the visual above for the syntax diagram and a usage sample. As you can see, XMLATTRIBUTES adds the attributes EMPNO and NAME (which is a combination of FIRSTNAME and LASTNAME) to the XML element <EMP>

39 Neue AP Funktionen 3.8 Development Center Funktionalität
Weiterentwicklung des „Stored Procedure Builder“ Unterstützung einer bestimmten Menge von Servern der DB2 Familie Aus der Sicht des „mainframe“ kann man hier „stored procedures“ definieren Verbesserter z/OS „support“ mit speziellen SQL IDs („package owner“, „build owner“, „secondary ID“ und „advanced build options“) Unterstützung und Entwicklung von SQL und JAVA „stored procedures“ auf dem zSeries Rechner Unterstützung zum Ansehen von „live database tables, views, triggers, stored procedures und user-defined functions und mehr.... The DB2 Development Center (DC), included in the V8.1 UDB Application Development Client (ADC) component, is the follow-on product to the DB2 Stored Procedure Builder (SPB) in the DB2 V7.2 UDB Application Development Client. Development Center supports the entire family of DB2 servers using the DRDA architecture. It communicates with the DB2 UDB V8.1 distributed servers (Linux, UNIX, and Windows), DB2 UDB for OS/390 V6 and V7 and DB2 UDB for z/OS V8, as well as currently supported DB2 UDB releases on iSeries. From a mainframe perspective, the tool can be used to build stored procedures. Development Center supports creating SQL stored procedures on all supported versions of DB2 for OS/390 and z/OS (currently V6, V7, and V8). Java stored procedures can be created with Development Center on DB2 V7 and V8. The Development Center Online Help is an excellent source for additional information on the Development Center.

40 3.1 „dynamic scrollable Cursors“ 3.2 SQL/PL Funktionen
3. Neue AP Funktionen 3.1 „dynamic scrollable Cursors“ 3.2 SQL/PL Funktionen 3.3 STP und Procedure Verbesserungen 3.4 Neue Spezialregister 3.4.1 SET Current Schema 3.4.2 SET Current PACKAGEPATH 3.5 ODBC Verbesserungen 3.6 Implizite RRSAF Verbindungen 3.7 Neue XML Funktionen