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.
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.
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.
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.
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.
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).
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)
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.
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.
a:/usr1/oracle:N
b:/usr1/oracle/product/7.0.16:N:g4drdrv
###################################################################
#
#
# 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
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
create
database link ora2drda
connect to XXX
identified by YYY
using
'T:gtwtest:b';
create synonym tptesth for otgdb2.tptest@ora2drda;
# 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
# SYM P_LU Mode
TP
DR2MF NETAN.DB2AT MTDB2DDF X'07F6C4C2'
rsslqs
SUN0:rsslqs # Gateway di test
TokenRing
###################################################################
###################### 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
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
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
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
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
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
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.
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
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