Definizione degli oggetti di sistema per IBM MQ for z/OS

IBM® MQ for z/OS® richiede ulteriori oggetti predefiniti per applicazioni di pubblicazione / sottoscrizione, cluster e controllo del canale e altre funzioni di amministrazione del sistema.

Gli oggetti di sistema richiesti da IBM MQ for z/OS possono essere suddivisi nelle seguenti categorie:

Oggetti di pubblicazione / sottoscrizione

Ci sono diversi oggetti di sistema che è necessario definire prima di poter utilizzare le applicazioni di pubblicazione / sottoscrizione con IBM MQ for z/OS. Le definizioni di esempio vengono fornite con IBM MQ per facilitare la definizione di questi oggetti. Questi campioni sono descritti in CSQ4INSG.

Per utilizzare la pubblicazione / sottoscrizione è necessario definire i seguenti oggetti:

Una coda locale denominata SYSTEM.RETAINED.PUB.QUEUE, utilizzato per conservare una copia di ciascuna pubblicazione conservata nel gestore code. Ogni nome argomento completo potrebbe avere fino a una pubblicazione conservata memorizzata su questa coda. Se le applicazioni utilizzeranno le pubblicazioni conservate su molti argomenti differenti, o se i messaggi di pubblicazione conservati sono messaggi di grandi dimensioni, i requisiti di memoria per questa coda devono essere attentamente pianificati, inclusa l'assegnazione alla propria serie di pagine se i requisiti di memoria sono elevati. Per migliorare le prestazioni, è necessario definire questa coda con un tipo di indice MSGID (come mostrato nella definizione della coda di esempio fornita).
Una coda locale denominata SYSTEM.DURABLE.SUBSCRIBER.QUEUE, utilizzato per conservare una copia persistente delle sottoscrizioni durevoli nel gestore code. Per migliorare le prestazioni, è necessario definire questa coda con un tipo di indice CORRELID (come mostrato nella definizione della coda di esempio fornita).
Una coda locale denominata SYSTEM.DURABLE.MODEL.QUEUE, utilizzato come modello per le sottoscrizioni durevoli gestite.
Una coda locale denominata SYSTEM.NDURABLE.MODEL.QUEUE, utilizzato come modello per le sottoscrizioni non durevoli gestite.
Un elenco nomi denominato SYSTEM.QPUBSUB.QUEUE.NAMELIST, che contiene un elenco di nomi di coda monitorati dall'interfaccia di pubblicazione / sottoscrizione in coda.
Un elenco nomi denominato SYSTEM.QPUBSUB.SUBPOINT.NAMELIST, che contiene un elenco di oggetti argomento utilizzati dall'interfaccia di pubblicazione / sottoscrizione in coda per associare gli oggetti argomento ai punti di sottoscrizione.
Un argomento denominato SYSTEM.BASE.TOPIC, utilizzato come argomento di base per la risoluzione degli attributi.
Un argomento denominato SYSTEM.BROKER.DEFAULT.STREAM, che è lo stream predefinito utilizzato dall'interfaccia di pubblicazione / sottoscrizione in coda.
Un argomento denominato SYSTEM.BROKER.DEFAULT.SUBPOINT, che è il punto di sottoscrizione RFH2 predefinito utilizzato dall'interfaccia di pubblicazione / sottoscrizione in coda.
Un argomento denominato SYSTEM.BROKER.ADMIN.STREAM, che è il flusso admin utilizzato dall'interfaccia di pubblicazione / sottoscrizione accodata.
Una sottoscrizione denominata SYSTEM.DEFAULT.SUB, che è un oggetto sottoscrizione predefinito utilizzato per fornire valori predefiniti sui comandi DEFINE SUB.

Oggetti predefiniti del sistema

Gli oggetti predefiniti del sistema vengono utilizzati per fornire attributi predefiniti quando si definisce un oggetto e non si specifica il nome di un altro oggetto su cui basare la definizione.

I nomi delle definizioni degli oggetti di sistema predefiniti iniziano con i caratteri "SYSTEM.DEFAULT"o"SYSTEM.DEF. " Ad esempio, la coda locale predefinita del sistema è denominata SYSTEM.DEFAULT.LOCAL.QUEUE.

Questi oggetti definiscono i valori predefiniti di sistema per gli attributi di questi oggetti IBM MQ :

Code locali
Code modello
Code alias
Code remote
Processi
Elenchi nomi
Canali
Classi di memoria
Informazioni di autenticazione

Le code condivise sono un tipo speciale di coda locale, quindi quando si definisce una coda condivisa, la definizione si basa sul SISTEMA SYSTEM.DEFAULT.LOCAL.QUEUE. È necessario ricordare di fornire un valore per il nome della struttura CF (Coupling Facility) perché non ne è specificato uno nella definizione predefinita. In alternativa, è possibile definire la propria definizione di coda condivisa predefinita da utilizzare come base per le code condivise in modo che ereditino tutti gli attributi richiesti. È necessario definire una coda condivisa su un gestore code solo nel gruppo di condivisione code.

Oggetti comando di sistema

I nomi degli oggetti comando di sistema iniziano con i caratteri SYSTEM.COMMAND. È necessario definire questi oggetti prima di poter utilizzare le operazioni e i pannelli di controllo di IBM MQ per immettere comandi in un sottosistema IBM MQ .

Esistono due oggetti comando di sistema:

La coda di immissione comandi di sistema è una coda locale in cui i comandi vengono inseriti prima di essere elaborati dal programma di elaborazione comandi IBM MQ . Deve essere denominato SYSTEM.COMMAND.INPUT. Un alias denominato SYSTEM.ADMIN.COMMAND.QUEUE per la compatibilità con IBM MQ for Multiplatformse per l'utilizzo da parte di IBM MQ Console e administrative REST API.
SYSTEM.COMMAND.REPLY.MODEL è una coda modello che definisce la coda di risposta del comando di sistema.

Esistono due oggetti aggiuntivi che possono essere utilizzati da IBM MQ Explorer:

SYSTEM.MQEXPLORER.REPLY.MODEL coda
SYSTEM.ADMIN.SVRCONN

SYSTEM.REST.REPLY.QUEUE è la coda di risposta utilizzata da IBM MQ administrative REST API.

I comandi vengono normalmente inviati utilizzando messaggi non persistenti, quindi entrambi gli oggetti del comando di sistema devono avere l'attributo DEFPSIST (NO) in modo che le applicazioni che li utilizzano (incluse le applicazioni fornite come il programma di utilità e le operazioni e i pannelli di controllo) ricevano messaggi non persistenti per impostazione predefinita. Se si dispone di un'applicazione che utilizza messaggi persistenti per i comandi, impostare l'attributo DEFTYPE (PERMDYN) per la coda di risposta, poiché i messaggi di risposta a tali comandi sono persistenti.

Oggetti di gestione del sistema

I nomi degli oggetti di gestione del sistema iniziano con il carattere SYSTEM.ADMINADMIN.

Esistono sette oggetti di gestione del sistema:

Il SISTEMA SYSTEM.ADMIN.CHANNEL.EVENT
Il SISTEMA SYSTEM.ADMIN.COMMAND.EVENT
Il SISTEMA SYSTEM.ADMIN.CONFIG.EVENT
Il SISTEMA SYSTEM.ADMIN.PERFM.EVENT
Il SISTEMA SYSTEM.ADMIN.QMGR.EVENT
Il SISTEMA SYSTEM.ADMIN.TRACE.ROUTE.QUEUE QUEUE
Il SISTEMA SYSTEM.ADMIN.ACTIVITY.QUEUE QUEUE

Code canali

Per utilizzare l'accodamento distribuito, è necessario definire i seguenti oggetti:

Una coda locale con il nome SYSTEM.CHANNEL.SYNCQ, che viene utilizzato per mantenere i numeri di sequenza e gli identificatori LUWID (logical units of work) dei canali. Per migliorare le prestazioni del canale, è necessario definire questa coda con un tipo di indice MSGID (come mostrato nella definizione della coda di esempio fornita).
Una coda locale con il nome SYSTEM.CHANNEL.INITQ, utilizzato per i comandi del canale.

Non è possibile definirle come code condivise.

Code cluster

Per utilizzare i cluster IBM MQ , è necessario definire i seguenti oggetti:

Una coda locale denominata SYSTEM.CLUSTER.COMMAND.QUEUE, utilizzato per comunicare le modifiche del repository tra i gestori code. I messaggi scritti in questa coda contengono aggiornamenti ai dati del repository da applicare alla copia locale del repository o richieste di dati del repository.
Una coda locale denominata SYSTEM.CLUSTER.REPOSITORY.QUEUE, utilizzato per conservare una copia permanente del repository.
Una coda locale denominata SYSTEM.CLUSTER.TRANSMIT.QUEUE, che è la coda di trasmissione per tutte le destinazioni nel cluster. Per motivi di prestazioni, è necessario definire questa coda con un tipo di indice CORRELID (come mostrato nella definizione della coda di esempio).

Queste code generalmente contengono un numero elevato di messaggi.

Non è possibile definirle come code condivise.

Code del gruppo di condivisione code

Per utilizzare i canali condivisi e l'accodamento all'interno del gruppo, è necessario definire i seguenti oggetti:

Una coda condivisa con il nome SYSTEM.QSG.CHANNEL.SYNCQ, che viene utilizzato per conservare le informazioni di sincronizzazione per i canali condivisi.
Una coda condivisa con il nome SYSTEM.QSG.TRANSMIT.QUEUE, che viene utilizzato come coda di trasmissione per l'accodamento all'interno del gruppo. Se si sta eseguendo in un gruppo di condivisione code, è necessario definire questa coda, anche se non si sta utilizzando l'accodamento all'interno del gruppo.

Classi di memoria

Si consiglia di definire le seguenti sei classi di memoria. È necessario definirne quattro perché sono richiesti da IBM MQ. Le altre definizioni di classe di archiviazione sono consigliate perché sono utilizzate nelle definizioni di coda di esempio.

DEFAULT (obbligatorio): Questa classe di archiviazione viene utilizzata per tutte le code di messaggi che non sono critiche per le prestazioni e che non rientrano in nessuna delle altre classi di archiviazione. È anche la classe di memoria predefinita fornita se non ne viene specificata una durante la definizione di una coda.
NODEFINE (obbligatorio): Questa classe di memoria viene utilizzata se la classe di memoria specificata quando si definisce una coda non è definita.
REMOTO (obbligatorio): Questa classe di archiviazione viene utilizzata principalmente per le code di trasmissione, ossia, le code correlate al sistema con messaggi critici per le prestazioni di breve durata.
SYSLNGLV: Questa classe di memoria è utilizzata per messaggi di lunga durata, critici per le prestazioni.
SISTEMA (obbligatorio): Questa classe di memoria viene utilizzata per le code messaggi relative al sistema, critiche per le prestazioni, ad esempio SYSTEM.CHANNEL.SYNQ e SYSTEM.CLUSTER.* .
SSVOLAT: Questa classe di storage viene utilizzata per messaggi di breve durata, critici per le prestazioni.

È possibile modificare i relativi attributi e aggiungere altre definizioni di classe di memoria come richiesto.

Definizione della coda di messaggi non recapitabili dell'oggetto di sistema

La coda di messaggi non recapitabili viene utilizzata se la destinazione del messaggio non è valida. IBM MQ inserisce tali messaggi in una coda locale denominata coda di messaggi non instradabili. Anche se avere una coda di messaggi non recapitabili non è obbligatorio, è necessario considerarla essenziale, soprattutto se si utilizza l'accodamento distribuito o uno dei bridge IBM MQ .

Non definire la coda di messaggi non recapitabili come coda condivisa. Un inserimento in una coda locale su un gestore code potrebbe essere inserito nella coda dei messaggi non recapitabili. Se la DLQ (dead letter queue) era una coda condivisa, un gestore DLQ (dead letter queue) su un sistema differente potrebbe elaborare il messaggio e inserirlo in una coda con lo stesso nome, ma poiché si trova su un gestore code diverso, potrebbe essere la coda non corretta o avere un profilo di sicurezza diverso. Se la coda non esiste, non sarà possibile rielaborarla.

Se si decide di definire una coda di messaggi non recapitabili, è necessario indicare anche il nome del gestore code. A tale scopo, utilizzare il comando ALTER QMGR DEADQ (nome - coda). Per ulteriori informazioni, consultare Visualizzazione e modifica degli attributi del gestore code.

Coda di trasmissione predefinita

La coda di trasmissione predefinita viene utilizzata quando non è disponibile nessun' altra coda di trasmissione adatta per l'invio di messaggi a un altro gestore code. Se si definisce una coda di trasmissione predefinita, occorre anche definire un canale che serva la coda. In caso contrario, i messaggi che vengono inseriti nella coda di trasmissione predefinita non vengono trasmessi al gestore code remoto e rimangono nella coda.

Se si decide di definire una coda di trasmissione predefinita, è necessario indicare anche il nome del gestore code. A tale scopo, utilizzare il comando ALTER QMGR.

Code interne

Coda dati in sospeso
- Una coda definita per uso interno, SYSTEM.PENDING.DATA.QUEUE, supporta l'utilizzo di sottoscrizioni durevoli in un ambiente di pubblicazione / sottoscrizione JMS .
JMS 2.0 coda di staging ritardo recapito
- Se viene utilizzata la funzionalità di ritardo del recapito fornita da JMS 2.0 , viene utilizzata una coda di staging interna, SYSTEM.DDELAY.LOCAL.QUEUE, deve essere definito. Questa coda viene utilizzata dal gestore code per memorizzare temporaneamente i messaggi inviati con un ritardo di recapito diverso da zero fino a quando il ritardo di recapito non viene completato e il messaggio viene inserito nella relativa destinazione. Una definizione di esempio per questa coda viene fornita, commentata, in CSQ4INSG.
- Quando si definisce SYSTEM.DDELAY.LOCAL.QUEUE , è necessario impostare gli attributi STGCLASS, MAXMSGL e MAXDEPTH per il numero anticipato di messaggi che verranno inviati con ritardo di consegna. Inoltre, quando si definisce SYSTEM.DDELAY.LOCAL.QUEUE QUEUE garantisce che solo il gestore code può inserire messaggi in questa coda. Accertarsi che nessun identificativo utente disponga dell'autorità per inserire i messaggi in questa coda.

Coda di autenticazione canale

Per l'utilizzo interno dell'autenticazione di canale, il SISTEMA SYSTEM.CHLAUTH.DATA.QUEUE QUEUE è obbligatoria. Le definizioni di esempio vengono fornite con IBM MQ per facilitare la definizione di questi oggetti. Questo esempio è descritto in CSQ4INSA, che definisce anche alcune regole predefinite.