Archivio

Archive for the ‘DB2 – SQL’ Category

[DB2] – I Tipi di Dati del DB2

28 agosto 2009 Commenti disabilitati

La Tabella seguente mostra i tipi di Dati del DB2 e le corrispondenti clausole PICTURE e USAGE in COBOL

Tipo DB2 PICTURE USAGE Descrizione
CHAR(n) PIC X(n) DISPLAY Caratteri a lunghezza Fissa (EBCDIC). Fino ad un massimo di 254 bytes di caratteri alfanumerici. In COBOL è definito come PIC X(n), dove n è il numero di caratteri della colonna.
es. : 01  COD-CLI  PIC X(10).
VARCHAR(n) PIC X(n) DISPLAY Caratteri a lunghezza variabile (EBCDIC). Un numero variabile di caratteri alfanumerici. Il numero di bytes di caratteri è memorizzato in una Halfword (mezzavoce).
es. : 01 NOTE.
49 NOTE-LUNG  PIC S9(4) COMP.
49 NOTE-TXT     PIC X(2000).
SMALLINT PIC S9(4) COMP o
COMP-4
Un valore intero (Halfword). Valori compresi tra -32.768 e +32.767. Definito in COBOL come PIC S9(4) COMP.
es. : 01 CTR-RIGA    PIC S9(4) COMP. 
INTEGER PIC S9(9) COMP o
COMP-4
Un valore intero (Fullword). Valori compresi tra -2.147.485.648 e +2.147.485.648. Definito in COBOL come PIC S9(9) COMP.
es. : 01 CTR-OPE     PIC S9(4) COMP.
DECIMAL(n,d) PIC S9(i)V9(d) COMP-3 Packed Decimal. Contiene valori decimali (il segno della virgola è implicito). Il valore n indica il numero complessivo di cifre e d quante di quelle sono a destra del segno decimale.
es. : 01 TOT-FATT    PIC S9(7).V99 COMP-3.
L’esempio è la corrispondente dichiarazione di una variabile HOST per una COLONNA definita come : DECIMAL(9,2).
DATE PIC X(10) DISPLAY Una stringa di 10 caratteri. La struttura interna è nella forma : yyyy-mm-dd.
es. : 01 DATA-FATT     PIC X(10).
TIME PIC X(8) DISPLAY Una stringa di 8 caratteri (hh.mm.ss).
es. : 01 ORA-INIZIO     PIC X(8).
TIMESTAMP PIC X(26) DISPLAY Una stringa di 26 caratteri. La struttura interna è : yyyy-mm-dd-hh.mm.ss.mmmmmm
es. : 01 DATA-ORA-INIZIO     PIC X(26)
GRAPHIC PIC G(n) DISPLAY-1 Una Stringa grafica a lunghezza fissa che contiene n word (double-byte) di caratteri. Il valore n deve essere  maggiore di 0 e minore di 128.
VARGRAPHIC PIC G(n) DISPLAY-1 Una Stringa grafica a lunghezza variabile. Il valore massimo della lunghezza, n, deve essere maggiore di 0 e minore di un numero che dipende dalla taglia della pagina del table space. La lunghezza massima è di 16.352.
FLOAT No COMP-1 o
COMP-2
Floating Point (singola o doppia precisione). Singola precisione per n minore di 22, doppia precisione se n è compreso tra 22 e 53. La corrispondente dichiarazione COBOL non include la clausola PIC. Va indicato COMP-1 per la singola precisione, COMP-2 per la doppia precisione.
es. : 01 VALORE-SP  COMP-1.
01 VALORE-DP  COMP-2.
Annunci
Categorie:DB2 - SQL

[DB2] – Cos’è un DBRM, un Plan, ed un Package ?

10 ottobre 2008 4 commenti

Quando si sviluppa un Programma COBOLII ( ambiente MainframeMVS ) che accede al Data Base DB2, si devono effettuare una serie di funzioni che non sono necessarie quando un Programma utilizza solo files di tipo VSAM.

Queste funzioni sono eseguite, in maniera semplificata, attraverso il DB2 Interface – ( DB2I ).

Il DB2I è una serie di pannelli ISPF che consentono la “preparazione” dei programmi COBOL – DB2.

Passi per lo sviluppo di un programma COBOLDB2

1. La Precompilazione DB2

Un programma contenente statements SQL deve essere preventivamente analizzato e modificato prima che possa essere compilato. Il Precompilatore DB2 esegue queste funzioni, ed in particolare :

  • – ricerca ed espande i membri realtivi alle INCLUDE
  • – ricerca gli statements EXEC SQL …. END-EXEC
  • – crea una versione del sorgente modificata, in cui ogni statement SQL è commentato e viene  sostituito da un’istruzione CALL ai moduli di interfaccia di runtime del DB2
  • – estrae tutte le istruzioni SQL dal programma e le inserisce in un modulo chiamato DBRM – (Data Base Request Module)
  • – pone un ‘timestamp’ nel sorgente modificato e nel DBRM affinchè ci sia una “corrispondenza esatta” tra i due
  • – riporta gli esiti della precompilazione (eventuali errori, etc…)

Dopo che la fase di precompilazione è terminata, inizia quella della compilazione. Il compilatore COBOL compila il programma sorgente modificato (dal precompilatore) e produce un modulo oggetto.

Il Linkage Editor “links” (collega) il modulo oggetto (object module) con altri moduli richiesti includendo tutti i moduli necessari per l’interfaccia al DB2; questo produrrà un modulo caricabile (load module) …

… ma prima che il programma possa essere eseguito,  il DB2 deve eseguire la fase di BIND !

 

2. La fase di BIND

Il comando BIND è un tipo di “compilazione” delle istruzioni SQL.

In generale, il comando BIND legge gli statements SQL dai DBRMs e produce un meccanismo per accedere ai dati come indicato dagli statements SQL.

Ci sono due tipi di comandi BIND :

     – BIND PLAN e

     – BIND PACKAGE

 

2.1  Il comando BIND PLAN

Il comando BIND PLAN accetta in INPUT :

  • Uno o più DBRMs prodotti dalla precompilazione
  • Uno o più PACKAGEs prodotti da una precedente BIND PACKAGE
  • … oppure una combinazione di liste di DBRMs e PACKAGEs

 

L’OUTPUT del comando BIND PLAN è un PIANO APPLICATIVO contenente la rappresentazione della logica eseguibile degli accessi ottimizzati ai dati del DB2.

Un PLAN (PIANO APPLICATIVO) è eseguibile solo con un modulo caricabile (load module) corrispondente !

Prima di eseguire un Programma COBOL-DB2, si deve specificare il PLAN corispondente.

 

 

2.2  Il comando BIND PACKAGE

Il comando BIND PACKAGE accetta in INPUT :

  • Un solo DBRM e produce (OUTPUT) un singolo PACKAGE contenente la logica ottimizzata di accesso ai dati.

Successivamente, i PACKAGEs prodotti devono essere collegati in un PLAN (PIANO APPLICATIVO) con il comando BIND PLAN.

Un PACKAGE non è eseguibile e non può essere specificato quando si esegue il programma DB2!

dobbiamo sempre ottenere prima un PLAN (PIANO APPLICATIVO) !

 

Il processo di BIND

La fase di BIND esegue una serie di funzioni per creare i PACKAGEs o i PLANs che accedono ai dati DB2 richiesti, tra cui :

  • – lettura e controllo della sintassi SQL dai DBRMs
  • – controllo delle TABELLE DB2 e delle COLONNE a cui si accede se conformi a quelle presenti nel CATALOGO DB2
  • – validazione delle AUTORIZZAZIONI
  • – ottimizzazione degli statements SQL in “paths” (cammini) più efficienti (DB2 optimizer)

 

 

Al termine di queste due fasi (precompilazione DB2 / compilazione COBOL e BIND) , sono stati prodotti due COMPONENTI (separati)

  • Il PLAN DB2
  • … ed il modulo caricabile linkato (load module); il nostro programma eseguibile 🙂

… ma nessuno dei due è eseguibile senza l’altro!

Quando si esegue un programma contenente istruzioni SQL si deve specificare il PLAN che verrà utilizzato.

 

 

Cos’è un DBRM ?

Spesso si fa confusione con la definizione di DBRM e le sue relazioni ai programmi, plans e packages.

Un DBRM è un modulo contenente gli statements SQL estratti dal programma sorgente ( dal precompilatore ).

Esso è memorizzato come membro di un data set partizionato; non è memorizzato nel Catalogo DB2.

 

Cos’è un PLAN ?

Un PLAN è un modulo eseguibile contenete la logica dei ‘paths’ di accesso (ai dati), prodotti dal DB2 Optimizer.

Esso può essere composto da uno o più DBRMs o PACKAGEs.

 

Cos’è un PACKAGE ?

Un PACKAGE è il prodotto del comando BIND su di un singlo DBRM contenete i ‘paths’ ottimizzati di accesso ai dati (dalla v2.3 del DB2).

Per eseguire un PACKAGE, bisogna prima inserirlo nella lista dei PACKAGEs di un PLAN.

Un PACKAGE non è mai eseguito direttamente, esso è eseguito indirettamente quando verrà eseguito il PLAN che lo contiene.

Un PLAN può consistere di uno o più DBRMs, uno o più PACKAGEs, o combinazioni di DBRMs e PACKAGEs.

 

Ma qual’è la differenza tra un PLAN ed un PACKAGE ?

Prima di andare al supermercato,  in genere,  prepariamo la LISTA dei PRODOTTI da acquistare.

Una volta li, come troviamo un prodotto presente nella nostra LISTA, lo mettiamo nel carrello; arrivati alla cassa, paghiamo 😦 ed inseriamo tutti PRODOTTI acquistati in una BUSTA.

  • I PRODOTTI acquistati, sono i DBRMs
  • … e la BUSTA, è il PLAN (PIANO APPLICATIVO)

Ci possono essere più DBRMs in un PLAN (ci sono più PRODOTTI acquistati nella BUSTA).

… abbiamo effettuato una fase di BIND PLAN indicando come INPUT uno o più DBRMs.

Se invece di prendere i PRODOTTI dallo scaffale e metterli nel carrello segniamo la loro ubicazione sulla nostra LISTA, una volta alla cassa, possiamo consegnare la LISTA al cassiere per il conteggio.

Dopo il conteggio ed il pagamento :(, inseriamo la LISTA dei PRODOTTI acquistati con le relative ubicazioni nella BUSTA, … e non i PRODOTTI !

Il PLAN (la BUSTA) ora contiene la LISTA che fa riferimento alla posizione fisica dei PRODOTTI sugli scaffali.

  • La LISTA dei PRODOTTI con le relative ubicazioni, è la lista dei PACKAGEs

… abbiamo prima effettuato le fasi di BIND PACKAGE indicando in INPUT i DBRMs (ubicazione dei prodotti), e poi la fase di BIND PLAN indicando in INPUT la LISTA dei PACKAGEs. 

 

… dedicato a tutti quei giovani che ancora oggi sono “reclutati” nel mondo dei mainframe.

“Una nuova vita vi attende nelle colonie Extra-Mondo. L’occasione per ricominciare in un Eldorado di buone  occasioni e di avventure, un nuovo clima, divertimenti ricreativi…”
                                              ( Annuncio pubblicitario dall’alto, dal film Blade Runner – Ridley Scott 1982 )

Categorie:DB2 - SQL