Previous | Table of Contents | Next |
Listing 8.5 pending.sql reports on any pending distributed transactions.
SET PAGESIZE 999; SET FEEDBACK OFF; SET WRAP ON; COLUMN local_tran_id format a22 HEADING 'Local Txn Id' COLUMN global_tran_id format a50 HEADING 'Global Txn Id' COLUMN state format a16 HEADING 'State' COLUMN mixed format a5 HEADING 'Mixed' COLUMN advice format a5 HEADING 'Advice' SELECT local_tran_id,global_tran_id,state,mixed,advice FROM dba_2pc_pending ORDER BY local_tran_id;
On systems running SQL*Net version 2, the session script can be used to query the number of dedicated and shared servers on the system. For example, Listing 8.6 shows an SQL*Plus script to view all sessions.
Listing 8.6 session.sql displays all connected sessions.
SET ECHO OFF; SET TERMOUT ON; SET LINESIZE 80; SET PAGESIZE 60; SET NEWPAGE 0; TTITLE "dbname Database|UNIX/Oracle Sessions"; SPOOL /tmp/session SET HEADING OFF; SELECT 'Sessions on database '||substr(name,1,8) FROM v$database; SET HEADING ON; SELECT substr(b.serial#,1,5) ser#, substr(b.machine,1,6) box, substr(b.username,1,10) username, substr(b.osuser,1,8) os_user, substr(b.program,1,30) program FROM v$session b, v$process a WHERE b.paddr = a.addr AND type='USER' ORDER BY spid; TTITLE OFF; SET HEADING OFF; SELECT 'To kill, enter SQLPLUS> ALTER SYSTEM KILL SESSION', ''''||'SID, SER#'||''''||';' from dual; SPOOL OFF; [oracle]ram2: sqlx session Wed Sep 14 Page 1 ram2db Database Sessions for SQL*Net SERVER Oracle user O/S User Machine Program --------- ----------- -------- ------ ------------------------------ DEDICATED SYS oracle ram2 sqldba@ram2 (Pipe Two-Task) DEDICATED OPS$REDDY reddy ram2 runform30@ram2 (Pipe Two-Task) DEDICATED GLINT lkorneke ram2 sqlplus@ram2 (Pipe Two-Task) DEDICATED OPS$ORACLE oracle clt2 sqlplus@clt2 (TNS interface) DEDICATED OPS$JOKE joke ram2 ? @ram2 (TCP Two-Task) DEDICATED OPS$WWRIGHT wwright ram2 runmenu50@ram2 (Pipe Two-Task) DEDICATED OPS$ORACLE oracle ensc sqlplus@ensc (TCP Two-Task) DEDICATED SECTION125 OraUser C:\PB3\PBSYS030.DLL DEDICATED OPS$ORACLE oracle ram2 sqlplus@ram2 (Pipe Two-Task) DEDICATED OPS$JSTARR jstarr ram2 sqlforms30@ram2 (Pipe Two-Task) DEDICATED OPS$WWRIGHT wwright ram2 RUN_USEX@ram2 (Pipe Two-Task) 12 rows selected.
Here we see each of the four types of SQL*Net connections:
While we can only gloss over the high points, sophisticated tools such as SQL*Net 2.0 require a great deal of knowledge and skill to use effectively. As systems continue to evolve into complex distributed networks, inter-database communications will become even more complex, requiring even more sophisticated tools. While object-orientation promises to make interdatabase communications simple, the DBA in the trenches will continue to struggle with implementing everyday distributed database communications.
A great deal of interest in database connectivity has resulted from the proliferation of companies that are choosing diverse database platforms. Database designers are working actively to develop bridges between the divergent database systems, and many tools are becoming available to assist with multidatabase connectivity.
We currently have three classes of methods for database connectivity:
This very exciting area of technology is explored in detail in Chapter 9. Fortunately, we have some very simple ways to begin working with multiple databases. One start at database connectivity can be achieved in the batch environment. By embedding database commands from two databases into a single COBOL program, compile procedures can be developed to separately precompile each set of database statements, creating a single program which concurrently accesses two different databases. (See Figure 8.6.)
Figure 8.6 Interdatabase communications with mainframes.
In this example, a COBOL program was created to read DB2 tables and dynamically store them into an CA-IDMS database. The statements for DB2 and CA-IDMS remain as they would in a single database program, but a special compile procedure is set up to precompile each set of statements separately. The trick is to invoke the DB2 precompiler before the CA-IDMS pre-compiler. Because all DB2 commands are bracketed with EXEC-SQL .... END-EXEC, all DB2 commands will be processed before the CA-IDMS pre-compiler begins its job. Listing 8.7 shows some JCL that works well for compiling a COBOL program to simultaneously access DB2 and CA-IDMS.
Listing 8.7 A COBOL compiler.
//DB2IDMSC PROC PROGRAM=,SYSTEM=PROD,DICT=LCPDICT //*************************************************************** //* THIS IS THE IDMS/DB2 COBOL COMPILER (BATCH IDMS/DB2 COBOL) //*************************************************************** //DB2 EXEC PGM=DSNHPC,PARM='HOST(COBOL),APOST,APOSTSQL,NOSOURCE,NOXREF' //*************************************************************** //DBRMLIB DD DSN=DB2.LCP.DBRMLIB(&PROGRAM),DISP=SHR //SYSCIN DD DSN=&&DSNHOUT,DISP=(MOD,PASS),UNIT=SYSDA, // SPACE=(800,(50,50)) //SYSLIB DD DSN=DB2.LCP.DCLGNLIB,SUBSYS=LAM //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(800,(50,50),,,ROUND),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(50,50),,,ROUND),UNIT=SYSDA //*************************************************************** //DMLC EXEC PGM=IDMSDMLC,REGION=1024K,PARM='DBNAME=&DICT',COND=(4,LT) //*************************************************************** //STEPLIB DD DSN=LCP.IDMS.&SYSTEM..PRODLIB,DISP=SHR // DD DSN=LCP.IDMS.&SYSTEM..CDMSLIB,DISP=SHR //SYSLST DD DUMMY //SYSPRINT DD SYSOUT=* //SYSCTL DD DSN=LCP.IDMS.&SYSTEM..SYSCTL,DISP=SHR //SYSJRNL DD DUMMY //SYSPCH DD DSN=&&WRK1WORK,UNIT=SYSDA,DISP=(NEW,PASS), // DCB=BLKSIZE=800,SPACE=(CYL,(5,1)) //SYSIPT DD DSN=&&DSNHOUT,DISP=(OLD,DELETE,DELETE) //*************************************************************** //COMP EXEC PGM=IKFCBL00,COND=(4,LT), // PARM='&CPARM,&PAYPR,STA,LIB,DMAP,CLIST,APOST,NOSXREF,BUF=28672' //*************************************************************** //STEPLIB DD DSN=SYS1.VSCOLIB,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSDA, // SPACE=(800,(50,50),RLSE) //SYSLIB DD DSN=ISD.COBOL.TEST.COPYLIB,DISP=SHR // DD DSN=ISD.COBOL.COPYLIB,DISP=SHR //SYSUT1 DD SPACE=(800,(50,50),RLSE),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(50,50),RLSE),UNIT=SYSDA //SYSUT3 DD SPACE=(800,(50,50),RLSE),UNIT=SYSDA //SYSUT4 DD SPACE=(800,(50,50),RLSE),UNIT=SYSDA //SYSIN DD DSN=&&WRK1WORK,DISP=(OLD,DELETE,DELETE) //*************************************************************** //LKED EXEC PGM=IEWL,PARM='XREF,LIST,&LPARM', // COND=((12,LE,COMP),(4,LT,DB2)) //*************************************************************** //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE) // DD DSN=LCP.IDMS.TEST.PROCLIB(IDMSCOB),DISP=SHR //SYSUT1 DD SPACE=(1024,(50,50)),UNIT=SYSDA //SYSLIB DD DSN=SYS1.DB2.DSNLINK,DISP=SHR // DD DSN=SYS1.VSCOLIB,DISP=SHR // DD DSN=SYS1.VSCLLIB,DISP=SHR // DD DSN=LCP.IDMS.&SYSTEM..CDMSLIB,DISP=SHR //SYSLMOD DD DSN=LCP.IDMS.&SYSTEM..LINKLIB(&PROGRAM),DISP=SHR //LIB DD DSN=LCP.IDMS.&SYSTEM..OBJLIB,DISP=SHR //*************************************************************** //BIND EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=((8,LT),(4,LT,DB2)) //*************************************************************** //SYSTSIN DD DSN=ISD.TEST.PARMCARD(PCRDB21),DISP=SHR //DSNTRACE DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSIN DD DSN=LCP.IDMS.&SYSTEM..LINKLIB(&PROGRAM),DISP=SHR
The execution of the COBOL program is normally achieved by running it under the domain of the DB2 foreground processor. Listing 8.8 shows how the execution JCL for a DB2/IDMS COBOL program would appear.
Listing 8.8 The execution JCL for the COBOL program.
//GOFORIT JOB (CARD) //GOFORIT EXEC PGM=IKJEFT01,DYNAMNBR=20 //*************************************************************** //SYSTSIN DD * DSN SYSTEM (DB2P) RUN PROG (MYCOBOL) - LIB ('MY.LINK.LIB') - PLAN (MYCOBOL) //DSNTRACE DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //STEPLIB DD DSN=MY.IDMS.LIBRARIES,DISP=SHR
Previous | Table of Contents | Next |