04 - System Administration04g - Varie sistemistica

Trasferire oggetti con ObjectConnect ed Enterprise Extender

Last Updated on 22 Ottobre 2021 by Roberto De Pedrini

Spesso è necessario trasferire oggetti (file, programmi, etc.) da un sistema ad un altro per allineare software (tra sistemi in HA, ad esempio) oppure per distribuirlo (tra sistemi di sviluppo, collaudo e produzione). Solitamente questa attività si realizza trasferendo file di salvataggio via FTP ma è anche possibile utilizzare il “vecchio” ObjectConnect con il support dell’Enterprise Extender. Vediamo come.

Enterprise Extender

Enterprise Extender, disponibile da i5/OS V5R4, è il sostituto di IBM per il supporto AnyNet. Viene utilizzato per incapsulare il traffico SNA su un collegamento IP per permettere il flusso del traffico APPN tra sistemi su una rete TCP/IP (evitando così l’uso di speciali router e controller SNA).

ObjectConnect

ObjectConnect è una serie di comandi CL inclusi con il sistema operativo IBM i (5770SS1 opzione 22) per spostare oggetti tra sistemi in modo semplice ed efficiente.

Quando si utilizza un comando ObjectConnect, il sistema sposta l’oggetto direttamente nel sistema di destinazione senza utilizzare file di salvataggio o code di distribuzione. ObjectConnect fornisce prestazioni migliori rispetto ad altri metodi e non richiede spazio su disco aggiuntivo per memorizzare una copia intermedia dell’oggetto che viene spostato.

I comandi ObjectConnect sono strettamente correlati ai comandi di salvataggio e ripristino. I comandi ObjectConnect supportano la maggior parte degli stessi parametri.

Comandi ObjectConnectComandi IBM i di salvataggio e ripristino
Salva/Ripristina file system integrato (SAVRST)Salva (SAV), Ripristina (RST)
Salva/Ripristina oggetto (SAVRSTOBJ)Salva oggetto (SAVOBJ), Ripristina oggetto (RSTOBJ)
Salva/Ripristina oggetto modificato (SAVRSTCHG)Salva oggetto modificato (SAVCHGOBJ), Ripristina oggetto (RSTOBJ)
Salva/Ripristina libreria (SAVRSTLIB)Salva libreria (SAVLIB), Ripristina libreria (RSTLIB)
Salva/Ripristina oggetto libreria documenti (SAVRSTDLO)Salva oggetto libreria documenti (SAVDLO), Ripristina oggetto libreria documenti (RSTDLO)
Salva/Ripristina configurazione (SAVRSTCFG)Salva configurazione (SAVCFG), Ripristina configurazione (RSTCFG)

Fino a IBM i V7R3, ObjectConnect utilizza l’architettura di comunicazione dati SNA per funzionare (anche quando il traffico SNA è incapsulato su un collegamento IP).

Nota. In IBM i V7R4 con PTF SI73777 (“aggiunta del supporto TCP nativo ai comandi CL di ObjectConnect”) ObjectConnect è stato reso compatibile con TCP/IP (nuovo server TCP/IP *OBJC) liberandolo da Enterprise Extender.


Target operating system: da i5/OS V5R4 a IBM i V7R4 (vedere nota precedente).


Attivazione di Enterprise Extender e configurazione della connessione tra sistemi IBM i

Per attivare Enterprise Extender tra due sistemi IBM i è necessario solo configurare gli attributi di rete e creare un controller su ogni sistema.

Modifiche ai valori di sistema (CHGSYSVAL)

Enterprise Extender crea (se non è già presente sul sistema) e utilizza un controller QAPENDxxxx su IBM i quando comunica con i sistemi Enterprise Extender remoti. Crea anche dispositivi APPC sotto questo controller quando la comunicazione viene stabilita per la prima volta. Affinché il sistema crei automaticamente il controller ed i dispositivi necessari la prima volta, è necessario modificare i seguenti valori di sistema:

QAUTOCFG : impostare il valore a “1” (configurazione automatica dei dispositivi attiva):

CHGSYSVAL SYSVAL(QAUTOCFG) VALUE('1')

QAUTORMT : Impostare il valore a “1” (consentire la configurazione automatica dei controller remoti):

CHGSYSVAL SYSVAL(QAUTORMT) VALUE('1')

QAUTOVRT : Impostare il valore a “*NOMAX” (nessun limite al numero di dispositivi virtuali da creare):

CHGSYSVAL SYSVAL(QAUTOVRT) VALUE('*NOMAX')

Nota. Questi valori possono essere ripristinati alle impostazioni originali non appena Enterprise Extender sarà attivo e funzionante.

Configurazione degli attributi di rete (CHGNETA)

Visualizzare gli attributi di rete (DSPNETA) di ciascun sistema e raccogli le seguenti informazioni:

  • ID rete locale (LCLNETID) e nome punto di controllo locale (LCLCPNAME). Questo è il nome completo del punto di controllo (CP). È diviso in due parti. La prima parte è denominata NETID di una rete Systems Network Architecture (SNA) e la seconda parte è il nome CP di questo nodo.
  • Tipo di nodo (NODETYPE). Il tipo di nodo APPN da configurare. In questo scenario, IBM i sarà un nodo finale (End Node) APPN.

Note.

  1. Anche se la funzione APPN Network Node (*NETNODE) è disponibile, IBM i deve essere configurato come APPN End Node (*ENDNODE) o, se devono essere serviti APPN End Node downstream, come APPN Branch Extended Node (*BEXNODE). I nodi di rete APPN devono partecipare alle ricerche Broadcast APPN e agli aggiornamenti del database della topologia e tali ruoli dei nodi devono essere concentrati solo nel backbone APPN.
  2. La modifica del tipo di nodo richiederà di disattivare tutti controller e i dispositivi APPC prima di apportare modifiche.
  • Consenti torre di trasporto HPR (ALWHPRTWR). Abilita il supporto della torre di trasporto HPR per il traffico della sessione APPN.
  • Timer di commutazione del percorso HPR (HPRPTHTMR). I timer del cambio di percorso HPR definiscono per quanto tempo l’endpoint RTP attenderà un cambio di percorso riuscito prima di terminare la pipe HPR.

Per modificare i valori:

CHGNETA LCLNETID(netid) LCLCPNAME(sys_name) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

Note.

  1. I parametri che utilizzano i valori predefiniti sono in corsivo.
  2. La modifica del valore del parametro LCLNETID è facoltativa. E’ possibile lasciare il valore predefinito (“APPN”), oppure è possibile impostare un NETID diverso su entrambi i sistemi (di solito quando i due sistemi appartengono alla stessa organizzazione), oppure puoi impostare un NETID diverso per sistema (di solito quando i due sistemi appartengono a organizzazioni diverse).

Un messaggio CPC0909 (“Attributo di rete &1 modificato in &2 da &3/&4/&5.”) viene inviato per ciascun attributo di rete modificato. La modifica di questi valori non dovrebbe richiedere il riavvio del sistema.

Su SystemA, modificare gli attributi di rete come segue:

CHGNETA LCLNETID(NETIDA) LCLCPNAME(SYSTEMA) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

Su SystemB, modificare gli attributi di rete come segue:

CHGNETA LCLNETID(NETIDB) LCLCPNAME(SYSTEMB) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

Configurazione dei controller APPC (Advanced Peer-to-Peer Communication) (CRTCTLAPPC)

Visualizzare gli attributi di rete (DSPNETA) di ciascun sistema e raccogliere le seguenti informazioni:

  • ID rete locale (LCLNETID)
  • Nome punto di controllo locale (LCLCPNAME)

Visualizzare le interfacce locali per ciascun sistema utilizzando CFGTCP, Opzione 1 o WRKTCPSTS OPTION(*IFC) e selezionare gli indirizzi IP che si desidera utilizzare per questa connessione.

Creare il controller APPC (CRTCTLAPPC):

CRTCTLAPPC CTLD(ctl_name) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('remote_ipa') LCLINTNETA('local_ipa') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(remote_netid) RMTCPNAME(remote_control_point) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('controller_description')

Note.

  1. I parametri che utilizzano i valori predefiniti sono in corsivo.
  2. Gli indirizzi internet locale e remoto sono gli indirizzi IP utilizzati, rispettivamente, dal sistema IBM i locale e dal sistema IBM i remoto per comunicare tramite Enterprise Extender.
  3. Se si desidera utilizzare i nomi host invece degli indirizzi IP, questi nomi host devono essere risolti negli indirizzi IP tramite DNS o tramite voci appropriate nelle tabelle host dei due sistemi aggiungendo la voce host per SystemA alla tabella host di SystemB e vice versa.
  4. Se c’è un firewall NAT tra i due sistemi, LCLINTNETA sarà sempre un indirizzo IP che è stato configurato in CFGTCP Opt 1 e RMTINTNETA sarà l’indirizzo IP pubblico del remoto, non l’indirizzo privato che è stato configurato in CFGTCP Opzione 1.
  5. Quando si utilizza Enterprise Extender su una rete che attraversa i firewall, per stabilire con successo una connessione assicurarsi che le porte UDP da 12000 a 12004 siano aperte tra entrambi gli indirizzi IP in entrambe le direzioni (si consiglia di consentire anche il traffico ICMP ECHO tra i due indirizzi IP per utilizzare il comando ping per testare la connettività). Inoltre, se si trattava di una migrazione da IBM AnyNet ad Enterprise Extender, assicurarsi di rimuovere le voci dell’elenco di configurazione remota dalla configurazione Anynet.
  6. Per approfondire il significato dei parametri vi rimando al manuale IBM (vedi riferimenti a fine post).

Su SystemA, creare un controller APPC verso SystemB:

CRTCTLAPPC CTLD(SYSTEMB) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('b.b.b.b') LCLINTNETA('a.a.a.a') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(NETIDB) RMTCPNAME(SYSTEMB) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('EE to SystemB')

Su SystemB, creare un controller APPC verso SystemA:

CRTCTLAPPC CTLD(SYSTEMA) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('a.a.a.a') LCLINTNETA('b.b.b.b') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(NETIDA) RMTCPNAME(SYSTEMA) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('EE to SystemB')

Su SystemA, attivare il controller APPC:

VRYCFG CFGOBJ(SYSTEMB) CFGTYPE(*CTL) STATUS(*ON)

Il controller APPC passa allo stato “Vary On Pending” (“CPC2609: Completato il comando di attivazione per l’unità di controllo &1.”).

Su SystemB, attivare il controller APPC:

VRYCFG CFGOBJ(SYSTEMA) CFGTYPE(*CTL) STATUS(*ON)

Su entrambi i sistemi, i controller APPC passano allo stato “Varied On” (“CPF5908: L’unità di controllo &1 è stata contattata sulla linea &2.”).

Poiché il controller QAPENDxxxx non verrà creato finché non si avvia una connessione Enterprise Extender tra i due sistemi, su SystemA avviare la sessione pass-through verso SystemB (o viceversa):

STRPASTHR RMTLOCNAME(SYSTEMB) LCLLOCNAME(*NETATR) RMTNETID(NETIDB)

Su entrambi i sistemi, vengono creati un controller APPN virtuale chiamato QAPENDxxxx ed un dispositivo APPC, chiamato come il controller (il dispositivo APPC è collegato al controller APPN appena creato):

CPC2623: Creata la descrizione per l’unità di controllo &1.

CPC2609: Completato il comando di attivazione per l’unità di controllo &1.

CPC2622: Creata la descrizione per l’unità &1.

CPC2605: Completato il comando di attivazione per l’unità &1.

Su SystemA, modificare la descrizione del dispositivo APPC come segue:

CHGDEVAPPC DEVD(SYSTEMB) ONLINE(*YES)

Su SystemB, modificare la descrizione del dispositivo APPC come segue:

CHGDEVAPPC DEVD(SYSTEMA) ONLINE(*YES)

Relazioni tra parametri:

Ora che i sistemi sono connessi con Enterprise Extender vediamo come utilizzare ObjectConnect per trasferire oggetti.

Utilizzo di ObjectConnect per replicare oggetti tra sistemi IBM i

L’utilizzo di FTP per trasferire oggetti come file, programmi, ecc. tra sistemi IBM i risulta un po’ macchinoso perché FTP non è in grado di gestire direttamente gli oggetti. Per poterli trasferire bisogna prima salvarli in un file di salvataggio sul sistema locale (o sorgente), quindi trasferire il file di salvataggio sul sistema remoto (o di destinazione) ed, infine, ripristinare il contenuto del file di salvataggio sul sistema remoto. Come detto in precendenza, il processo non è proprio semplicissimo.

Configurando Enterprise Extender sui sistemi IBM i ed utilizzando ObjectConnect l’attività di trasferimento oggetti diventa molto più semplice perché ora è possibile trasferire oggetti con un solo comando da eseguire sul sistema sorgente.

Vediamo alcuni esempi.

Per trasferire (salvare e ripristinare) oggetti da SystemA a SystemB è possibile utilizzare il comando SAVRSTOBJ su SystemA:

SAVRSTOBJ OBJ(objects) LIB(library) RMTLOCNAME(NETIDB.SYSTEMB) RSTLIB(targetlib)

Allo stesso modo, per trasferire una libreria da SystemB a SystemA è possibile utilizzare il comando SAVRSTLIB su System B:

SAVRSTLIB LIB(library) RMTLOCNAME(NETIDA.SYSTEMA) RSTLIB(targetlib)

Restrizioni.

  1. Il profilo utente utilizzato per eseguire i comandi SAVRST* deve essere definito su entrambi i sistemi coinvolti. Le password dei due profili utente non devo essere necessariamente uguali.
  2. I comandi QSR/SAVRST* vengono rilasciati con autorizzaione *PUBLIC *EXCLUDE quindi il profilo utente utilizzato per eseguirli deve essere esplicitamente autorizzato oppure deve avere l’autorizzazione speciale *ALLOBJ.
  3. Sul sistema di destinazione, il profilo utente deve esser autorizzato ai comandi di ripristino che verrano utilizzati (SAVRST* -> RST*, ad esempio: SAVRSTOBJ -> RSTOBJ, SAVRSTLIB -> RSTLIB, …).
  4. Il profilo utente utilizzato per eseguire i comandi SAVRST* deve avere l’autorizzazione speciale *SAVSYS o avere (a) l’autorità di esistenza degli oggetti per ogni oggetto specificato e (b) l’autorità di lettura per la libreria specificata. Se non avete l’autorità necessaria per un oggetto specificato, tutti gli oggetti tranne quello vengono salvati e ripristinati.
  5. Entrambi i sistemi destinati a partecipare all’operazione di salvataggio e ripristino devono essere collegati alla rete ethernet di interworking o, la stessa rete APPN, o se l’opzione OptiConnect per IBM i deve essere utilizzata, entrambi i sistemi devono essere uniti da OptiConnect per IBM i hardware e software.

Raccomandazioni.

Come sempre in caso di salvataggio e ripristino è necesasrio fare attenzione alle autorizzazioni degli oggetti e delle librerie coinvolte su entrambi i sistemi e al proprietario degli oggetti.

Suggerimento.

Se non si vogliono avere problemi di autorizzazione nel trasferimento di oggetti potete procedere come segue:

  1. Su SystemA, creare il profilo utente che verrà usato per eseguire il trasferimento degli oggetti con autorizzazione speciale *SAVSYS e autorizzarlo ai comandi ObjectConnect SAVRST… da utilizzare:
CRTUSRPRF USRPRF(user) SPCAUT(*SAVSYS)
GRTOBJAUT OBJ(QSR/SAVRST…) OBJTYPE(*CMD) USER(user) AUT(*USE)
  1. Su SystemB, creare lo stesso profilo utente con autorizzazione speciale *SAVSYS ed autorizzarlo ai comandi IBM i di ripristino associati ai comandi ObjectConnect utilizzati sul SystemA.:
CRTUSRPRF USRPRF(user) SPCAUT(*SAVSYS)
GRTOBJAUT OBJ(QSYS/RST…) OBJTYPE(*CMD) USER(user) AUT(*USE)

Riferimenti:

Configurazione di EE (Enterprise Extender) tra due sistemi IBM System i

Funzione ObjectConnect

Modifica attributi di rete (CHGNETA)

Crea Ctl Desc (APPC) (CRTCTLAPPC)

Related Posts
DB2 for i SQL – Stringhe – POSSTR-LOCATE-LOCATE_IN_STRING (IT)

Introduzione Spesso, nelle nostre applicazioni, abbiamo la necessità di lavorare con le stringhe di testo e l'SQL del DB2 può Read more

DB2 for i & SQL – FAQ & Howto (Part. 1) (IT)

Database DB2 e SQL ... forse lo strumento più potente e completo che abbiamo sulla piattaforma IBM i: ecco una Read more

Annuncio IBM i 7.4

Arriva direttamente con l'uovo di Pasqua questo annuncio IBM per le novità della versione IBM i 7.4, versione iNext secondo Read more

Generated Always Columns – Approfondimenti (IT)

Introduzione "Generated Always Column": sono colonne, campi, di una tabella il cui contenuto è controllato direttamente dal sistema ... e Read more

About author

Amministratore sistemi IBM i

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *