Oracle Transparent Gateway per DRDA

 

Il pacchetto Oracle Transparent Gateway (OTG) for DRDA consente l'accesso a tabelle su un database che supporta il meccanismo di comunicazione DRDA (per esempio DB2) da parte di utenti ed applicazioni che operano in ambiente Oracle. Le applicazioni possono accedere in tal modo a tabelle residenti su altri database, effettuare operazioni di lettura, join, modifiche ai dati, .. con la stessa sintassi e semantica che si avrebbe con un accesso locale ad una base dati Oracle.

Il prodotto e' installabile su una macchina Unix o AS400 e non richiede l'acquisizione di prodotti su MF. E' richiesto un software di rete per la connettivita' verso MF con sessioni LU 6.2.

 

In questo documento sono riportati elementi ed indicazioni per una corretta installazione e configurazione. Negli esempi riportati si fa riferimento ad una specifica installazione del prodotto su un sistema SUN, ... tuttavia le indicazioni possono essere generalizzate per altri ambienti e sistemi.

Questo documento e un estratto di un piu ampio documento contente benchmark, prove di recovery, ... che si e ritenuto inadatto alla pubblicazione. Gia quanto leggerete nel seguito e abbastanza spesso. Buona fortuna.

 

 

Installazione OTG

 

La procedura di installazione e' analoga a quella di altri prodotti Oracle. Non vi sono particolari difficolta' o problemi per un DBA esperto.

Vi sono comunque alcune particolarita' (relative all'ORACLE_HOME, modalita' di relink, ...) che possono ingannare i meno esperti.

 

Configurazione rete, SunLink, VTAM, ...

 

La configurazione e' complessa e richiede competenze specifiche su ambienti molto differenti. La documentazione al riguardo non e' esaustiva. Buona fortuna!

 

La configurazione del software di rete TCP-IP, di Oracle SQL*Net, .. e' del tutto normale e non presenta problemi.

 

La configurazione del VTAM richiede la definizione completa di sessioni LU6.2 tra la macchina Unix ed il DB2. Il numero di sessioni parallele, ... debbono essere definite in accordo al numero massimo di connessioni da Oracle verso DB2.

E' necessario definire l'attivazione automatica di tutte le sessioni da MF (tale configurazione e' stata dedotta sperimentalmente).

 

Sono riportati al termine del documento i principali elementi della configurazione. Si ritiene che tale insieme di file di configurazione possa essere di notevole utilita' per chi deve effettuare nuove installazioni o configurazioni.

 

 

Configurazione DDF

 

La configurazione del DDF consente di utilizzare il database DB2 in modalita' distribuita attraverso il protocollo DRDA.

 

Al fine di controllarne la corretta configurazione e opportuno effettuare un test del DDF fra due database DB2 in DRDA.

Cio' si effettua inserendo nelle opportune tabelle del Communication DataBase (CDB) il nome delle rispettive location e dei rispettivi linkname.

Contemporaneamente debbono essere definiti al VTAM i sottosistemi DB2.

 

Possono verificarsi alcuni problemi. Nel mio particolare caso:

1) The DB2 server site was unable to allocate a database access agent since the max number allowed was zero

La soluzione e' stata quella di aumentare il valore del parametro DB2 MAXDBAT;

2) A distributed database message was truncated during transmission through the network

La soluzione e' stata quella di diminuire il parametro VTAM RUSIZE.

 

Vi auguro di non averne altri o, comunque, di riuscire a capire di che si tratta.

Successivamente le tabelle del CDB sono state aggiornate per consentire l'accesso dal gateway Sun.

Ad ogni modifica di configurazione e' necessario effettuare la ripartenza dei servizi di DDF.

 

 

Configurazione OTG

 

L'esecuzione dello script g4drutl in modalita' di bind per la creazione del package avviene senza problemi (se le precedenti configurazioni sono corrette).

L'esecuzione degli script di creazione tabelle e viste presenta i seguenti problemi:

Alcuni statement contenuti negli script sono falliti, in effetti gli statement giungevano a DB2 troncati della parte iniziale. Il problema e' stato aggirato eliminando blank inutili e rieseguendo gli statement.

Alcuni statement contenuti negli script sono falliti, si trattava di statement che contenevano l'operatore di concatenazione "||". Il problema e' stato aggirato sostituendo l'operatore "||" con l'operatore "concat" che svolge la stessa azione. Il problema e' particolare poiche' l'operatore in questione dovrebbe essere supportato da entrambe i dialetti SQL. (forse CCSID)

Le viste e le tabelle di OTG sono state create su un database DB2 predefinito (modificando gli script di installazione). L'utilizzo di tale database non ha presentato problemi.

 

Architettura e funzionamento del pacchetto OTG

 

Sono stati condotti una serie di test per comprendere il funzionamento di OTG. Si ritiene che quanto descritto nel seguito sia corretto, tuttavia la documentazione ufficiale in proposito e' generica e gli elementi specifici sono stati ricavati sperimentalmente utilizzando strumenti di trace e tirando ad indovinare (!).

 

L'installazione di un gateway OTG e' molto simile a quella di una istanza Oracle. A tutti gli effetti, per le applicazioni Oracle che accedono a tabelle remote l'OTG appare come una normale istanza Oracle.

 

L'accesso ad una tabella remota attiva il processo Unix g4drdrvb con il normale meccanismo SQL*Net (eg. file oratab). Tale processo alloca una sessione SNA se ve ne sono libere (altrementi si mette in attesa infinita).

Stranamente le sessioni debbono essere inizializzate da DB2 (con il parametro VTAM AUTOSES) altrimenti non risultano libere.

Il processo g4drdrvb non termina se non con il termine della connessione del programma chiamante. Tale scelta offre vantaggi prestazionali ma presenta un problema per il numero di sessioni necessarie. Infatti un numero elevato di utenti connessi al DB Oracle locale potrebbero in realta' effettuare solo una operazione di accesso in remoto e quindi risultare connessi in maniera continua (il limite sul numero delle sessioni e' definito su VTAM, DDF e SunLink; la modifica di tali definizioni richiede un certo impegno).

Per ovviare a tale problema e' possibile utilizzare un workaround applicativo.

 

A fronte di una operazione su una tabella remota, l'ottimizzatore Oracle (presente sulla macchina cui e' connessa l'applicazione client) "spezza" lo statement SQL in componenti che riguardano ogni singolo server. Lo statement raggiunge il processo g4drdrvb che lo esamina. Vengono eliminati gli accessi a funzioni non supportate dai server DRDA. Tali funzioni verranno realizzate dal programma g4drdrvb stesso, al server DRDA vengono inviate quindi istruzioni SQL semplificate.

 

Viene richiesta al server remoto la descrizione delle tabelle implicate nell'istruzione SQL. Viene controllato che lo statement non contenga colonne insesistenti, ... in tal caso viene inviato un messaggio di risposta opportuno (senza sottoporre lo statement al server DRDA). La descrizione delle tabelle viene mantenuta come informazione e non e' piu' richiesta nel caso di utilizzi successivi nell'ambito della stessa sessione (bene!).

 

Lo statement SQL viene trasformato come nell'esempio seguente:

SQL> select substr(c2,1,20), c2, c2

from tpmeo

where c1=30

DB2=> select "a1"."c2","a1"."c2","a1"."c2"

from "tpmeo" "a1"

where "a1"."c1"=30

Si notino l'eliminazione della funzione, l'aliasing e la ripetizione delle colonne. Nel caso di uso del carattere "*" per l'indicazione delle colonne questo viene sostituito con l'indicazione esplicita delle colonne corrette.

 

L'esecuzione degli statement su DB2 avviene utilizzando inizialmente il PLAN DISTSERV (di cui non sappiamo nulla, forse e' standard per il DRDA).

Tutti gli statement utente vengono eseguiti in modalita' dinamica utilizzando il PLAN G2DRSQL costruito all'atto della configurazione di OTG.

 

Nel caso di statement DML di modifica ai dati vengono effettuate operazioni sulla tabella ORACLE2PC. Le operazioni avvengono in modalita' statica (bene!) e sono collegate al plan G2DRSQL. La modalita' statica offre migliori prestazioni verso DB2.

 

Le principali operazioni che avvengono tra OTG verso SNA e DB2 sono descritte nel seguito (nell'esempio si ha una connessione, il lancio di una selezione ed il termine della connessione):

 

Attivita' di OTG

Attivita' su MF

Il processo g4drdrvb effettua l'allocate della sessione LU6.2. Viene inviato un messaggio (208 bytes) a MF, tra le altre cose viene inviato il V$SESSION.TERMINAL.

 

 

Viene attivata una sessione verso DB2

Viene effettuata una allocate del PLAN DISTSERV (?)

Viene confermata l'allocazione con un messaggio di risposta (170)

Viene richiesta la descrizione delle tabelle coinvolte nello statement SQL. Il nome della tabella e' in ASCII ().

 

 

Vengono interrogate le tabelle del data-dictionary. Viene inviata la risposta ().

Viene inviato lo statement SQL in ASCII con l'indicazione del plan da utilizzare ().

 

 

Viene allocato il PLAN G2DRSQL (DRDA1 collection).

Viene effettuata la bind dinamica dello statement SQL.

Viene effettuato un explain plan dello statement. Viene inviata la risposta (95).

Viene confermato il lancio dello statement con un messaggio (?) (95)

 

 

Viene effettuata la OPEN e quindi una serie di FETCH

Viene inviata la risposta (in EBCDIC) ()

Viene richiesta la disconnessione (19)

 

 

Sono effettuate una serie di lock/unlock e viene inviata la risposta (63)

 

Ogni scambio di messaggi ha un tempo di elapsed piuttosto lungo (0.3 secondi o un suo multiplo) su cui e' necessario effettuare ulteriori analisi (?). Si ritiene che l'elapsed sia dovuto ad una elevata latenza della rete, sono in corso attivita' di sperimentazione su tale argomento. Gli altri tempi su MF/DB2 (allocazione dei plan, bind dinamici, ..) sono notevolmente inferiori, generalmente dell'ordine di un decimo di secondo. Analogamente avviene su Unix.

Utilizzando la funzione di trace di DB2 tale tempo viene impiegato per effettuare una chiamata ad una macro VTAM.

 

Una istruzione SQL utilizzata una sola volta richiede almeno 5*0.3= 1.5 secondi. Il lancio di uno statement SQL con una sessione SNA gia' attiva e tabelle remote gia' utilizzate richiede almeno 2*0.3= 0.6 secondi.

Naturalmente il tempo puo' essere notevolmente maggiore per elaborazioni complesse. Tuttavia se le selezioni non richiedono pesanti caricamenti di dati (e quindi fetch su linea) DB2 risolve velocemente gli statement.

 

Nel caso in cui vengano effettuate operazioni di modifica su DB2 lo schema dei messaggi presentato non varia in modo significativo.

Nel caso in cui all'interno della stessa transazione vengano effettuate modifice su DB2 e su un database Oracle viene invece utilizzato il protocollo di two phase commit. Si ritiene che le attivita' svolte dai vari attori siano quelle descritte nel seguito:

 

Client

OTG

RDBMS Oracle (n)

DB2

update tpm

 

 

 

 

 

effettua update

 

 

 

risponde ok

 

.. n row updated

 

 

 

update tpmh

 

 

 

 

tratta statement remoto (come descritto nella tabella precedente)

 

 

 

 

 

effettua update

 

 

 

risponde ok

 

invia risposta

 

 

.. n row updated

 

 

 

commit

 

 

 

 

gestisce il commit

 

 

 

invia prepare to commit

 

 

 

 

riceve P2C

 

 

 

risponde OK a P2C

 

 

invia INSERT INTO ORACLE2PC ..

 

 

 

 

 

esegue INSERT ..

 

 

 

risponde ok

 

invia COMMIT a DB2

 

 

 

 

 

esegue COMMIT

 

 

 

risponde

 

invia COMMIT a altri

 

 

 

 

esegue commit

 

 

 

risponde

 

 

invia DELETE FROM ORACLE2PC ..

 

 

 

 

 

esegue DELETE ..

 

 

 

risponde

 

invia COMMIT

 

 

 

 

 

esegue COMMIT

 

 

 

risponde

 

risponde al client

 

 

... commited

 

 

 

 

Il caso presentato e' quello in cui tutte le operazioni si svolgono correttamente. Nel caso di errore in un qualsiasi punto della catena vengono effettuate le necessarie operazioni per mantenere la consistenza tra le diverse basi dati (con COMMIT, ROLLBACK, UPDATE su ORACLE2PC, ..). Sono stati provati alcuni casi d'errore (caduta di SunLink, del DDF, di Oracle, del client in momenti differenti) e non si sono evidenziati problemi.

 

Gli statement SQL verso la tabella ORACLE2PC sono statici e non dinamici. Vengono pertanto svolti con un solo scambio di messaggi sulla linea e richiedono un minore overhead al momento dell'esecuzione.

 

Non e' possibile coinvolgere piu' di un database DRDA per una transazione in 2PC. In una transazione 2PC il server DRDA e' il COMMIT POINT, il server cui e' connesso l'applicazione e' COORDINATOR, possono essere presenti altri server Oracle su cui agisce la transazione in 2PC. La documentazione al riguardo e' molto chiara.

 

L'utilizzo di utenze DB2 e MVS differenti da quella utilizzata per l'installazione funziona correttamente per l'accesso a tabelle remote.

 

E' stato utilizzato il collegamento verso DB2 con diversi prodotti tra cui: SQL*Plus (Oracle), sqlwin, wintalk (Gupta), SMARTDBA, ... non sono stati riscontrati problemi (se non la necessita' di evitare i costrutti SQL non permessi verso il database remoto, cosa che con tali prodotti e' possibile, anche se non semplice in tutti i casi).

 

 

Utilizzo dell'SQL con Oracle TG for DRDA

 

Il linguaggio SQL implementato da Oracle e da DB2 differisce in alcuni punti. Nel seguito sono riportati alcuni elementi per un corretto uso del linguaggio SQL da Oracle verso DB2 utilizzando il prodotto Transparent Gateway for DRDA.

 

Sono state condotte prove che hanno determinato o verificato quanto segue:

Connessione: la connessione diretta al database via DRDA non e' possibile, puo' avvenire solo tramite un comando di utilita' o con un database link. Quindi non si e' mai "connessi" al database DRDA ma semplicemente si utilizzano alcune tabelle su tale server residenti

Il comando di utilita' g4drutl consente di lanciare comandi in SQL-DB2 direttamente. Sono consentiti tutti gli statement SQL-DB2 validi. L'utilizzo della funzione e' previsto per sole attivita' di gestione/amministrazione.

L'utilizzo di un database link consente l'utilizzo di SQL-Oracle verso il database DRDA. L'utilizzo dei db link e dei sinonimi rende trasparente l'accesso in lettura e scrittura ai dati DB2 agli utenti ed alle applicazioni Oracle.

SQL: i dialetti Oracle e DB2 differiscono, gli utenti e le applicazioni Oracle debbono utilizzarli correttamente, OTG effettua le necessarie conversioni tra i due linguaggi

Il trattamento dei datatype e' differente, si faccia riferimento alla documentazione di OTG per una trattazione completa (quanto indicato sulla documentazione e' corretto e completo) seguono alcune brevi indicazioni. I "date" Oracle vengono troncati vs DB2 e debbono essere esplicitamente dichiarati all'OTG (mediante la funzione to_date()). I "time" e "timestamp" debbono essere trattati come stringhe con il fomato "hh:mi:ss" e "hh:mi:ss.mmmm....".

Poiche' si utilizzano db link non e' consentita alcuna operazione di DDL verso il database remoto.

Le funzioni SQL specifiche del dialetto Oracle sono utilizzabili negli statement di SELECT senza problemi sia nella clausola SELECT che nella clausola WHERE. Deve essere tenuto conto nella scrittura degli statement che la funzione Oracle viene risolta dall'OTG e quindi tutti i dati delle colonne estratte debbono essere trasferiti.

Le funzioni SQL specifiche del dialetto Oracle non sono utilizzabili in INSERT, UPDATE e DELETE (neppure nella clausola WHERE e senza bind variables), errore ORA-2070.

L'artimetica sulle date non e' supportata.

Le funzioni UID, USER e ROWID non sono supportate (la funzione USER ha in realta' un comportamento differente).

La clausola CONNECT BY non e' supportata.

Il trattamento dei timeout su lock e dei deadlock e' differente tra DB2 ed Oracle. In entrambe le situazioni OTG restituisce un errore ORA-02063, sqlcode=-913 (unsuccessful execution caused by deadlock or timeout.). Un database Oracle e' invece in grado di distiguere tra le due situazioni. In caso di lock, pone in attesa infinita se non si utilizza la clausola NO WAIT. In caso di deadlock il blocco viene determinato immediatamente e non dopo un timeout.

Non sono consentiti lock su tabelle remote (statement di LOCK TABLE).

Naturalmente non sono utilizzabili funzioni SQL specifiche del dialetto DB2.

select for update ha un comportamento strano (ovvero non pone alcun lock!).

 

Sono state inoltre effettuate prove sui seguenti argomenti:

statement SQL complessi, joins remoti, .. (ok)

row length, numero di colonne, .. (ok, raggiunto il limite SQL*Plus)

describe (funziona ma richiede molto, molto tempo alla prima attivazione)

alter session close database link (funziona ma solo dopo commit). Tale istruzione e' molto utile per limitare il numero di sessioni SNA contemporaneamente aperte vs DB2.

datatypes (ok come documentazione)

test funzioni compatibili, tradotte, post-processate, non supportate (tutto ok con SELECT)

test sulle transazioni: lock, rollback, commits, 2PC (ok, vedi note sopra)

nulls, integrity constraint (ok supportati, naturalmente quelli di DB2)

 

 

Suggerimenti per un adeguato utilizzo in ambienti di produzione

 

Per un corretto e consistente utilizzo del prodotto e' opportuno attenersi alle seguenti indicazioni generali:

Per gli amministratori:

Creare limitati e specifici database link verso DB2 dal nome ora2db2, non utilizzare il nome dei database link nel codice.

Definire uno standard di nomenclatura per l'accesso a tabelle remote. Quale semplice esempio: per indicare il nome delle tabelle remote utilizzare lo stesso nome di tabelle oracle con il suffisso "h".

Creare i sinonimi opportuni.

Utilizzare utenze definite su DB2 e MVS specifiche e con diritti ben definiti e limitati, utilizzare utenze differenti per gruppi di utenti su Oracle differenti.

L'utilizzo, almeno inizialmente, dovra' essere seguito e monitorato continuamente.

Potrebbe essere necessario adottare, acquisire o sviluppare strumenti di gestione specifici. In ogni caso deve essere considerato un maggior onere per la gestione di transazioni distribuite.

L'azione manuale sulle transazioni in dubbio deve essere il piu' possibile evitata.

E' probabilmente opportuno utilizzare un server Oracle intermedio anziche' link simbolici verso il gateway da tutti gli RDBMS Oracle; questo per consentire un piu' semplice monitoraggio degli utenti e delle tabelle accedute.

Per le applicazioni:

Non utilizzare alcun riferimento esplicito ai db link ma utilizzare solo i sinonimi appositamente creati.

Valutare l'eventualita' dell'utilizzo dello statement "alter session close database link" per ridurre il numero di connessioni attive verso il database remoto.

 

Poiche' si utilizzano due linguaggi SQL ed il protocollo di 2PC le applicazioni che sfruttano tale meccanismo debbono essere sviluppate attentamente:

Debbono essere trattati in maniera adeguata i codici d'errore relativi alle disconnessioni remote, alle transazioni in dubbio, ai timeout sui lock e deadlock, ..

Gli algoritmi di ottimizzazione e l'implementazione del linguaggio SQL differiscono tra Oracle e DB2, debbono essere utilizzati statement che siano efficienti verso il database target.

Uno statement non ottimizzato verso il DB2 puo' avere pesanti impatti per tutte le connessioni presenti.

Le modalita' di gestione di lock dei diversi database coinvolti in una transazione differiscono, in particolare il lock a livello di pagina di DB2 puo' portare a situazioni di blocco che non potrebbero verificarsi con Oracle; gli statement verso DB2 debbono pertanto essere costruiti tenendo conto di tale differenza

E' putroppo opportuno ricordare che l'utilizzo del buon senso deve essere applicato anche nell'utilizzo di OTG; per esempio e' opportuno limitare gli accessi in remoto, le transazioni debbono essere il piu' brevi possibile, le istruzioni di modifica debbono essere vicine al COMMIT, ...

Una applicazione "corretta" verso Oracle ha tuttavia un'alta probabilita' di poter essere utilizzata senza modifiche sostanziali verso DB2. I programmi di stress test, creati appositamente per un database Oracle, sono stati eseguiti senza modifiche su DB2.

 

 

 

File di configurazione

 

Nel seguito vengono riportati i principali file di configurazione del sistema. Poiche' sono state effettuate prove su differenti configurazioni dei vari servizi quanto riportato e' solo un esempio completo e funzionante di una configurazione.

 

 

 

Configurazione Oracle

 

 

Tabella di connessione in remoto: oratab

 

a:/usr1/oracle:N

b:/usr1/oracle/product/7.0.16:N:g4drdrv

 

 

File di configurazione di istanza - initb.ora

 

###################################################################

# #

# SAMPLE init.ora file for DB2 #

# #

###################################################################

#LANGUAGE='US'

SET GATEWAY_SID=b

# The following setting of the generic NLS_DATE_FORMAT parameter

# is required by Transparent Gateway for IBM DRDA.

NLS_DATE_FORMAT=YYYY-MM-DD

RESOLVE_BINDS=FALSE

RETRY=0, 1

OPTIMIZE_FILE_OPEN=FALSE

MAX_LOG_SIZE=0

ERRORTAG=ALL

OPEN_CURSORS=50

INIT_CURSORS=5

INCREMENT_CURSORS=2

TRIM_CURSORS=TRUE

D_OPEN_CURSORS=50

D_INIT_CURSORS=3

D_INCREMENT_CURSORS=1

D_TRIM_CURSORS=TRUE

TRACE_LEVEL=255

DB_NAME=b

# The following parameters are specifically for Transparent Gateway

# for IBM DRDA.

# DRDA gateway parms to access DB2 (instance DSN3)

SET DRDA_RDBMS_TYPE=DSN

SET DRDA_CONNECT_PARM=DR2MF

SET DRDA_REMOTE_DB_NAME=LOCDBAT

SET DRDA_PACKAGE_COLLID=DRDA1

SET DRDA_PACKAGE_NAME=G2DRSQL

SET DRDA_PACKAGE_CONSTOKEN=A92617CB3FE54701

SET DRDA_RECOVERY_USERID=XXX

SET DRDA_RECOVERY_PASSWORD=YYY

SET DRDA_FLUSH_CACHE=COMMIT

#

# Be careful changing the DRDA_ISOLATION_LEVEL. It will effect ALL DB2 users !

#

SET DRDA_ISOLATION_LEVEL=CS

#

# DRDA_PACKAGE_OWNER allows you to assign the package owner to be someone other

# than the userid connected when the g4drutl utility is run. THIS USER MUST

# ALSO OWN THE ORACLE2PC table. See the Installation Guide for more

#information. It is currently commented out.

#

#ET DRDA_PACKAGE_OWNER=ORADRDA

 

 

File di configurazione attivazione instanza - initb.gtwboot

 

MODE=DEBUG

# mode can be: STD INFO or DEBUG

LOG_DESTINATION=/usr1/oracle/product/7.0.16/tg4drda/admin/rsslqs.log

#

# Un-comment the following line and fill in the gateway name

APPC_GATEWAY=rsslqs

#

# Un-comment the following line and fill in the side information file name

CPIC_SI=/usr1/oracle/product/7.0.16/tg4drda/admin/DRDACON1

 

 

Script di creazione dei database link

 

create database link ora2drda

connect to XXX identified by YYY

using 'T:gtwtest:b';

create synonym tptesth for otgdb2.tptest@ora2drda;

 

Configurazione UNIX

 

 

Ambiente di Oracle TG4DRDA - .profile

 

# OMISSIS

ORACLE_SID=b

ORACLE_HOME=/usr1/oracle/product/7.0.16

PATH=/usr1/oracle/product/7.0.16/bin:$PATH

MODE=STD

LOG_DESTINATION=/usr1/oracle/product/7.0.16/tg4drda/admin/rsslqs.log

APPC_GATEWAY=rsslqs

CPIC_SI=/usr1/oracle/product/7.0.16/tg4drda/admin/DRDACON1

export ORACLE_SID ORACLE_HOME PATH MODE LOG_DESTINATION APPC_GATEWAY CPIC_SI

 

 

Configurazione CPI-C - DRDACON1

 

# SYM P_LU Mode TP

DR2MF NETAN.DB2AT MTDB2DDF X'07F6C4C2'

 

 

SunLink gateways - /etc/appcs

 

rsslqs SUN0:rsslqs # Gateway di test TokenRing

 

 

SunLink snap2p configuration file - p2p.rsslqs

 

###################################################################

###################### Define Physical Unit RSSLQS ###########

###################################################################

:DEFINE_PU:

pu_name = RSSLQS

network_name = NETAT

contents_id = 01234567

pums_supported = no

:DEFINE_NODE:

pu_name = RSSLQS

node_id = NODELQS

###################################################################

###################### Define Logical Unit RSSLQI01 ###########

###################### session_name = lqi01dzt ###########

###################################################################

:DEFINE_LOCAL_LU:

fql_lu_name = NETAT.RSSLQI01

lu_local_address = 1

lu_name = RSSLQI01

lu_session_limit = 60

:DEFINE_PARTNER_LU:

fql_plu_name = NETAN.DB2AT

u_plu_name = DB2AT

parallel_session = yes

lu_is_dependent = no

initiate_type = INITIATE_ONLY

security_acceptance = NONE

:DEFINE_MODE:

fql_plu_name = NETAN.DB2AT

mode_name = MTDB2DDF

#mode_name = PEER0002

unique_session_name = lqi01dzt

snd_pac_window = 0

rcv_pac_window = 0

snd_max_ru_size = 1536

rcv_max_ru_size = 1536

sync_level = SYNC_CONFIRM

sess_reinit = INIT_OPERATOR

auto_activate_limit = 0

session_limit = 60

min_conwinner_limit = 0

min_conloser_limit = 60

###################################################################

######################Define Data Link Control L961089 #######

###################################################################

:DEFINE_DLC:

dlc_name = L961089

dlc_driver_name = /dev/llc2

port_driver_name = tr0

dlc_type = llc # SDLC data link

npr_timeout = 240

pause_timeout = 2

idle_timeout = 1400

maxdata = 1545

retries = 3

local_sap = 08

full_duplex = no

nrzi = no

multipoint = yes

switched_line = yes

block_number = 017 # MUST be first of xid parameters

id_number = F0002

role = negotiable # or negotiable or primary

tx_rx_capability = alternating # or simultaneous

max_rcv_iframe_size = 7

include_control_point = yes # xid control vector

xtwait = 10

linkid = 0

include_link_station_name = no # xid control vector

#product_set_id = 161101130011f9f4f0f4c3f1f0f1f0f0f0f2f4f1f6f4

# product set id:product identifier (ibm h/w):hw product identifier (serial#)

:DEFINE_ALS:

dlc_name = L961089

pu_name = RSSLQS

als_name = ALSLQS0

remote_mac_addr = 400020200096

remote_sap = 04

:DB_MSG:

db_pc = no

db_mail = no

db_buf = no

db_dev = yes

db_api_verb = no

db_character_set = ebcdic

db_record_size = long

file_mode = create

file_name = /usr1/oracle/log/rsslqs.log

db_tp_info = yes

db_max_trc_sz = 4

 

 

 

 

Configurazione token ring

 

E' stata utilizzata la configurazione token ring riportata in tabella. Il file di riferimento e' /opt/SUNWconn/snacommd/snatemplate.sample.

 

Sono state effettuate alcune prove modificando i parametri ACK_DELAY (2), NOTACK_MAX (6), TX_WINDOW (14), XID_WINDOW (14) senza ottenere significative variazioni delle prestazioni.

 

# N2_VAL

20

# T1_VAL

9

# TPF_VAL

7

# TREJ_VAL

24

# TBUSY_VAL

96

# TILDE_VAL

240

# ACK_DELAY

4

# NOTRACK_MAX

3

# TX_WINDOW

7

# TX_PROBE

0

# MAX_I_LEN

4096

# XID_WINDOW

7

# XID_NDUP

0

# XID_TDUP

0

 

 

Configurazione router

 

La connessione su linea token ring e' composta da due anelli geograficamente distanti (in ambito MAN) connessi con una linea dedicata a 198Kb. Per effettuare la connessione sono stati utilizzati due router CICSO 4000 con configurazioni speculari di cui riportiamo i principali elementi:

 

!

version 10.2

service nagle

no service pad

service password-encryption

!

hostname CISCO_4000

!

buffers big permanent 150

buffers big max-free 200

buffers big min-free 10

buffers large permanent 16

buffers large max-free 20

buffers large min-free 5

enable password 7 080808080800

!

no ip domain-lookup

source-bridge ring-group 5

source-bridge remote-peer 5 interface Serial1 lf 1500

!

interface Ethernet0

description GATEWAYS

ip address 192.192.16.4 255.255.252.0

no ip redirects

media-type 10BaseT

no mop enabled

!

interface Ethernet1

no ip address

shutdown

media-type 10BaseT

!

interface Serial0

description LIBERA

no ip address

ip tcp header-compression

bandwidth 192

shutdown

!

interface Serial1

description CED

ip address 192.192.172.1 255.255.252.0

ip tcp header-compression

bandwidth 192

custom-queue-list 10

!

interface TokenRing0

no ip address

early-token-release

ring-speed 16

source-bridge active 1 1 5

source-bridge spanning

!

router igrp 1

network 192.192.0.0

!

logging buffered

logging 192.192.4.55

queue-list 1 protocol ip 2 tcp 20

queue-list 1 protocol novell 2

queue-list 1 queue 1 limit 100

queue-list 1 queue 3 byte-count 512 limit 5

queue-list 2 protocol novell 2

queue-list 2 protocol ip 2 tcp 20

queue-list 2 queue 1 limit 100

queue-list 2 queue 2 byte-count 512 limit 3

queue-list 3 protocol novell 2

queue-list 3 protocol ip 2 tcp 20

queue-list 3 queue 1 limit 60

queue-list 3 queue 2 byte-count 512 limit 5

queue-list 10 default 2

queue-list 10 protocol rsrb 1

queue-list 10 protocol ip 3 tcp 20

queue-list 10 queue 1 limit 60

queue-list 10 queue 2 limit 60

queue-list 10 queue 3 byte-count 512 limit 10

priority-list 2 default medium

priority-list 2 protocol ip high tcp 23

priority-list 2 protocol ip low tcp 20

priority-list 2 protocol ip low tcp 21

priority-list 2 protocol ip high tcp 2000

priority-list 10 protocol novell low

priority-list 10 protocol ip high tcp 21

priority-list 10 protocol ip low tcp 20

!

snmp-server community public RO

banner motd (router CISCO 4000)

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0

password 7 080808080800

login

line vty 1

password 7 080808080800

login

line vty 2

password 7 080808080800

login

line vty 3

password 7 080808080800

login

line vty 4

password 7 080808080800

login

!

end


 

Configurazione VTAM

 

 

Modetab

 

La tabella di MODETAB e' la seguente:

MTDB2DDF MODETAB

IBMDB2LM MODEENT LOGMODE=IBMDB2LM,

COS=MEDIUM,

SSNDPAC=X'02',

SRCVPAC=X'00',

RUSIZES=X'8787'

IBMRDB MODEENT LOGMODE=IBMRDB,

COS=MEDIUM,

SSNDPAC=X'02',

SRCVPAC=X'00',

RUSIZES=X'8787'

MODEEND

END

 

 

APPLID

 

Il file di APPLID e' il seguente:

VBUILD TYPE=APPL

DB2AT APPL APPC=YES,

AUTH=(ACQ),

AUTOSES=60,

DMINWNL=25,

DMINWNR=25,

DSESLIM=60,

MODETAB=MTDB2DDF,

SECACPT=ALREADYV,

SRBEXIT=YES,

VERIFY=NONE,

VPACING=2

 


 

 

Configurazione DB2 su MF

 

 

File parametri

 

Il file di parametri DB2 utilizzato e' il seguente:

 

DSN6ENV MVS=XA

DSN6SPRM RESTART,

ALL,

ABIND=YES,

AUTH=YES,

BUFFER=(BP0(2000,2000),

BP1(1000,1000),

BP2(0,0),

BP32K(12,12)),

CATALOG=TDTDB230,

DECDIV3=NO,

DEFLTID=IBMUSER,

DSMAX=1000,

EDMPOOL=4462,

IRLMAUT=YES,

IRLMPRC=DBATIRLM,

IRLMSID=IRAT,

IRLMRWT=60,

IRLMSWT=300,

NUMLKTS=1000,

NUMLKUS=10000,

RECALL=YES,

RECALLD=120,

RGFCOLID=DSNRGCOL,

RGFDBNAM=DSNRGFDB,

RGFDEDPL=NO,

RGFDEFLT=ACCEPT,

RGFFULLQ=YES,

RGFINSTL=NO,

RGFNMORT=DSN_REGISTER_OBJT,

RGFNMPRT=DSN_REGISTER_APPL,

SYSADM=ASTE003,

SYSADM2=ASTE006,

SYSOPR1=GOCCS06,

SYSOPR2=GOCCS28

DSN6ARVP ALCUNIT=BLK,

ARCWRTC=(1,3,4),

ARCWTOR=NO,

ARCPFX1=TDTDB230.ARCHLOG1,

ARCPFX2=TDTDB230.ARCHLOG2,

ARCRETN=1,

BLKSIZE=28672,

CATALOG=YES,

COMPACT=NO,

MSVGP=,

MSVGP2=,

PRIQTY=1234,

PROTECT=NO,

QUIESCE=5,

SECQTY=154,

TSTAMP=NO,

UNIT=ROBOT

DSN6LOGP INBUFF=28,

MAXALLC=3,

MAXARCH=500,

OUTBUFF=400,

TWOACTV=NO,

TWOARCH=NO,

WRTHRSH=20

DSN6SYSP AUDITST=NO,

CTHREAD=30,

IDBACK=20,

IDFORE=100,

LOGLOAD=1000,

MAXDBAT=60,

MON=NO,

MONSIZE=8192,

RLF=NO,

RLFTBL=01,

RLFERR=NOLIMIT,

RLFAUTH=SYSIBM,

ROUTCDE=(1),

SMFACCT=*,

SMFSTAT=*,

STATIME=30,

TRACSTR=NO,

TRACTBL=16

DSN6FAC DDF=AUTO,

RLFERRD=NOLIMIT

END

 

 

 

Utenze

 

E' stata creata una utenza XXX con password YYY abilitata all'accesso al DB2 di riferimento e con i diritti di creazione di tabelle sul database prescelto.

 

 

DDF

 

I dati inseriti per un corretto funzionamento del DDF sono i seguenti:

 

Tabella SYSLUNAMES

LUNAME SYSMODENAME USERSECURITY ENCRYPTPSWDS MODESELECT USERNAMES

-------- ----------- ------------ ------------ ---------- ---------

( )

RSSLQI01

Tabella SYSLOCATIONS

LOCATION LOCTYPE LINKNAME LINKATTR

---------------- ------- -------- ---------------------------------------

LOCDBAT RSSLQI01


 

Ambienti e programmi utilizzati per i test

 

Per i test sono stati utilizzati i seguenti programmi ed ambienti:

Software in test: Oracle Transparent Gateway for DRDA v. 3.0.13.1.4

Database di appoggio Unix: Oracle RDBMS 7.1.6.2.0 per SUN Solaris

Server Unix: SUN sparcstation 5 70Mhz, 64Mb RAM, 64Mb swap partition e 64 Mb swap file

Sistema Operativo Unix: Solaris 2.4, revision level 101945-27

Software di comunicazione per SNA: SunLink Peer-to-Peer for SNA 8.0

Database Mainframe: DB2 v. 2.3

Sistema Operativo Mainframe: MVS ESA 4.2

Il collegamento tra la macchina Sun e MF e' stato effettuato con una connessione Token Ring con connessione MAN su una linea 198Kbit

Programma di controllo della base dati Oracle: SMARTDBA 1.0.9(alfa)

 

 



Testo: Oracle Transparent Gateway
Data: 17 Settembre 1997
Versione: 1.1.0
Autore: mail@meo.bogliolo.name