Pianificazione di DB2 su z/OS

Questa sezione fa parte dell'attività più ampia di personalizzazione dell'ambiente z/OS ed è importante solo per il componente broker. Gestione configurazione ed il Server nomi utente non richiedono accesso a DB2.

WebSphere Message Broker per z/OS accede alle tabelle DB2 mediante ODBC. Per collegarsi a DB2 mediante ODBC, viene utilizzato il nome dell'ubicazione del sottosistema DB2. Per ulteriori informazioni, consultare la pubblicazione DB2 UDB for OS/390 and z/OS V7 Data Sharing: Planning and Administration.

E' necessario fornire ai seguenti ID utente l'accesso alle risorse DB2:
  • Amministratori di sistema DB2
    1. Creazione di database, gruppi di memorizzazione e spazi di tabella (BIPCRDB).
    2. Rilascio del database (BIPDLDB)
  • Amministratore del database del broker (DBA). Dovrebbe essere l'amministratore WebSphere Message Broker.
    1. Creazione di tabelle ed indici (BIPCRBK)
    2. Creazione di tabelle, rilascio di tabelle e creazione di indici (BIPMGCMP)
  • ID utente dell'attività avviata del broker:
    1. SQL per selezionare, inserire ed eliminare righe dalle tabelle del database del broker e selezione dalle tabelle di sistema DB2.
  • Amministratore WebSphere Message Broker ed altri utenti
    1. SQL per selezionare, inserire ed eliminare righe dalle tabelle del database del broker e selezione dalle tabelle di sistema DB2.

Quando il sistema DB2 viene avviato, dovrebbe essere visualizzato un messaggio simile a DSNL004I AVVIO DDF COMPLETATO. Il nome dell'ubicazione è visualizzato dopo questo messaggio. Quando si personalizza un componente broker su z/OS, viene creato un file dsnaoini denominato BIPDSNAO nel PDSE del broker. Esso contiene le informazioni necessarie per stabilire la connessione ODBC. Per ulteriori informazioni, consultare la pubblicazione DB2 UDB for OS/390 and z/OS V7 ODBC Guide and Reference.

Non utilizzare un nome di origine dati uguale all'ID del sottosistema o dell'ID di condivisione dei dati. Se viene utilizzato lo stesso nome, potrebbero verificarsi problemi relativi alla granulosità delle direttive sulla connessione con il database.

Se si decide di utilizzare lo stesso valore per il nome dell'origine dati e l'ID del sottosistema, è necessario modificare BIPDSNAO nel PDSE del broker in modo che le parole chiave Datasource e Subsystem siano in una sezione.

Per ulteriori informazioni relative alla personalizzazione di tale file, consultare la pubblicazione DB2 UDB for OS/390 and z/OS V7 ODBC Guide and Reference.

Durante la personalizzazione, è possibile specificare il nome del piano da utilizzare oppure utilizzare il DSNACLI predefinito. Se si desidera che il proprio broker acceda a gruppi di condivisione dei dati DB2 diversi dal proprio, il piano DSNACLI deve essere associato in modo particolare. Verificare che l'ubicazione del wildcard sia specificata utilizzando SPUFI ed immettendo il seguente comando:
select * from SYSIBM.SYSPACKLIST where planname ='DSNACLI';
E' necessario eseguire nuovamente l'associazione se la colonna relativa all'ubicazione è vuota e non contiene '*'.

Inoltre, verificare che DSNACLI sia nella tabella SYSIBM.SYSPLAN.

Utilizzando la funzione CACHE DYNAMIC SQL di DB2 le prestazioni miglioreranno sensibilmente, poiché ciò elimina la necessità di elaborare nuovamente le istruzioni DB2. Consultare CACHEDYN=YES nella pubblicazione DB2 UDB for OS/390 and z/OS V7 Installation Guide.

Se il database dell'utente è configurato in modo da utilizzare una virgola come separatore decimale mediante il modulo DSNHDECP, esiste una limitazione. In caso di mancata corrispondenza tra DB2 e le impostazioni della locale dell'ID utente con cui viene eseguito il broker (in particolare LC_NUMERIC), gli aggiornamenti al database dell'utente possono essere imprevedibili. LC_NUMERIC viene impostato mediante l'impostazione LC_ALL nel membro BIPBPROF e quindi nel file di ambiente. Di seguito sono riportate le quattro possibilità:
  • Se DB2 è configurato in modo da utilizzare un punto come punto decimale e LC_NUMERIC è impostato su un valore che indica un punto come punto decimale; gli aggiornamenti al database dell'utente funzionano correttamente.
  • Se DB2 è configurato in modo da utilizzare una virgola come punto decimale e LC_NUMERIC è impostato su un valore che indica una virgola come punto decimale; gli aggiornamenti al database dell'utente funzionano correttamente.
  • Se DB2 è configurato in modo da utilizzare un punto come punto decimale e LC_NUMERIC è impostato su un valore che indica una virgola come punto decimale; gli aggiornamenti al database possono determinare un funzionamento imprevedibile.
  • Se DB2 è configurato in modo da utilizzare una virgola come punto decimale e LC_NUMERIC è impostato su un valore che indica un punto come punto decimale; gli aggiornamenti al database dell'utente possono determinare un funzionamento imprevedibile.

E' possibile utilizzare il meccanismo di sicurezza DB2 oppure, se su z/OS 1.5 e DB2 Versione 8 utilizzare un gestore della sicurezza esterno, come, ad esempio, RACF.

Meccanismo di sicurezza DB2

Il modo più pratico per la gestione dell'accesso alle risorse DB2 di un broker è quello di definire due gruppi RACF e di collegare gli utenti a tali gruppi. Ad esempio, i gruppi RACF MQP1ADM e MQP1USR sono definiti per il broker MQP1BRK nel modo riportato di seguito:
  • Per il gruppo MQP1ADM
    1. Concedere a questo gruppo l'autorizzazione DBADM per il database del broker.
    2. Generalmente, è di proprietà dell'amministratore WebSphere Message Broker; a questo gruppo è necessario aggiungere gli ID utente che devono eseguire BIPCRBK per creare un broker oppure BIPMGCMP per la migrazione di un broker.
  • Per il gruppo MQP1USR
    1. Fornire a questo gruppo l'accesso per la modifica delle righe nelle tabelle del broker e consentire l'accesso select alle tabelle di sistema DB2. Ad esempio:
      GRANT DELETE, INSERT, SELECT, UPDATE            
           ON TABLE                                   
                    DB2_TABLE_OWNER.BSUBSCRIPTIONS  
                   ,DB2_TABLE_OWNER.BPUBLISHERS     
                   ,DB2_TABLE_OWNER.BCLIENTUSER     
                   ,DB2_TABLE_OWNER.BTOPOLOGY       
                   ,DB2_TABLE_OWNER.BNBRCONNECTIONS 
                   ,DB2_TABLE_OWNER.BRETAINEDPUBS   
                   ,DB2_TABLE_OWNER.BACLENTRIES     
                   ,DB2_TABLE_OWNER.BMQPSTOPOLOGY   
                   ,DB2_TABLE_OWNER.BUSERNAME       
                   ,DB2_TABLE_OWNER.BGROUPNAME      
                   ,DB2_TABLE_OWNER.BUSERMEMBERSHIP 
                   ,DB2_TABLE_OWNER.BROKERAA        
                   ,DB2_TABLE_OWNER.BROKERAAEG      
                   ,DB2_TABLE_OWNER.BROKERRESOURCES 
                   ,DB2_TABLE_OWNER.BRMINFO         
                   ,DB2_TABLE_OWNER.BRMRTDINFO      
                   ,DB2_TABLE_OWNER.BRMRTDDEPINFO   
                   ,DB2_TABLE_OWNER.BRMWFDINFO      
                   ,DB2_TABLE_OWNER.BRMPHYSICALRES  
                   ,DB2_TABLE_OWNER.BAGGREGATE      
                   ,DB2_TABLE_OWNER.BMULTICASTTOPICS
           TO MQP1USR;                  
      
      GRANT SELECT
           ON TABLE                                   
                    SYSIBM.SYSTABLES  
                   ,SYSIBM.SYSSYNONYMS     
                   ,SYSIBM.SYSDATABASE
           TO MQP1USR;                  
    2. Collegare l'ID utente dell'attività avviata del broker e l'amministratore WebSphere Message Broker a questo gruppo e collegare tutti gli altri utenti che potrebbero richiedere l'accesso alle tabelle, ad esempio gli utenti che eseguono BIPRELG per eseguire il comando mqsireadlog.
Notare quanto riportato di seguito:
  • Quando si accede alle risorse DB2, viene specificato un CURRENT SQLID come un comando DB2 oppure mediante il membro BIPDSNAO.

    Se tale ID è un gruppo, DB2 verifica se l'ID utente è collegato a questo gruppo e, in questo caso, si eredita l'accesso dal gruppo; se l'ID utente non è contenuto nel gruppo, viene ricevuto il codice SQL -551.

    Se l'ID è contenuto in più gruppi, vengono utilizzate le autorizzazioni maggiori.

  • Per BIPCRDB e BIPDLDB, CURRENT SQLID è specificato come un comando nel JCL. Per tutti gli altri JCL, è specificato in BIPDSNAO.
  • Se non si utilizzano i gruppi per definire le autorizzazioni, ma viene utilizzato un ID utente specifico per definire le autorizzazioni ai singoli ID utente, se l'ID utente che concede le autorizzazioni viene rimosso da DB2, vengono rimosse anche tutte le autorizzazioni da esso concesse. Ciò potrebbe impedire ad altri utenti di effettuare operazioni.
  • Quando il lavoro BIPDLDB rilascia il database DB2 del broker, elimina anche qualsiasi riferimento di Image Copy di cui si dispone correntemente. Se in futuro si ripristina il broker, sarà necessario ripristinare i riferimenti di Image Copy.

Se questo ID è un gruppo, DB2 verifica se l'ID utente è collegato a questo gruppo e, in questo caso, si eredita l'accesso dal gruppo; se l'ID utente non è contenuto nel gruppo, viene ricevuto il codice SQL -551. Se l'ID è contenuto in più gruppi, vengono utilizzate le autorizzazioni maggiori.

Se non si utilizzano i gruppi per definire le autorizzazioni, ma viene utilizzato un ID utente specifico per definire le autorizzazioni ai singoli ID utente, se l'ID utente che concede le autorizzazioni viene rimosso da DB2, vengono rimosse anche tutte le autorizzazioni da esso concesse. Ciò potrebbe impedire ad altri utenti di effettuare operazioni.

Consultare Lavori di programmi di utilità z/OS per ulteriori informazioni relative ai lavori WebSphere Message Broker per z/OS forniti.

Attività correlate
Personalizzazione dell'ambiente z/OS
Riferimenti correlati
Riepilogo dell'accesso richiesto (z/OS)
Personalizzazione di attività e ruoli in z/OS
Associazione di un piano DB2 per l'utilizzo di gruppi di condivisione dei dati su z/OS
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ae22130_