Opzioni (MQLONG)

Se le richieste MQGET sono inibite o MQGET diventano inibite durante l'attesa, l'attesa viene annullata. La chiamata viene completata con MQCC_FAILED e il codice motivo MQRC_GET_INHIBITED, indipendentemente dal fatto che ci siano messaggi adatti sulla coda.

È possibile utilizzare MQGMO_WAIT con le opzioni MQGMO_BROWSE_FIRST o MQGMO_BROWSE_NEXT .

Se diverse applicazioni sono in attesa sulla stessa coda condivisa, le seguenti regole selezionano quale applicazione viene attivata quando arriva un messaggio appropriato:

1. Richieste get - wait specifiche che possono essere soddisfatte solo da determinati messaggi, ad esempio, quelli con uno specifico MsgId o CorrelId (o entrambi).
2. Richieste get - wait generali che possono essere soddisfatte da qualsiasi messaggio.

MQGMO_WAIT viene ignorato se specificato con MQGMO_BROWSE_MSG_UNDER_CURSOR o MQGMO_MSG_UNDER_CURSOR ; non viene generato alcun errore.

Se nessun messaggio che soddisfa i criteri specificati nel descrittore del messaggio è attualmente disponibile, il controllo ritorna all'applicazione senza attendere l'arrivo di un messaggio. I parametri CompCode e Reason sono impostati su MQCC_WARNING e MQRC_SIGNAL_REQUEST_ACCEPTED. Non vengono impostati altri campi di output nel descrittore del messaggio e i parametri di output della chiamata MQGET . Quando un messaggio appropriato arriva più tardi, il segnale viene inviato inviando la BCE.

Il chiamante deve quindi emettere nuovamente la chiamata MQGET per recuperare il messaggio. L'applicazione può attendere questo segnale, utilizzando le funzioni fornite dal sistema operativo.

Se il sistema operativo fornisce un meccanismo di attesa multiplo, è possibile utilizzarlo per attendere l'arrivo di un messaggio su una delle diverse code.

Se viene specificato un WaitInterval diverso da zero, il segnale viene consegnato dopo la scadenza dell'intervallo di attesa. Il Gestore code può anche annullare l'attesa, nel qual caso il segnale viene recapitato.

Più di una chiamata MQGET può impostare un segnale per lo stesso messaggio. L'ordine in cui le applicazioni vengono attivate è lo stesso descritto per MQGMO_WAIT.

Se più di una chiamata MQGET è in attesa dello stesso messaggio, ogni chiamata in attesa viene considerata allo stesso modo. Le chiamate possono includere una combinazione di opzioni di attesa e segnale.

In determinate circostanze, la chiamata MQGET può richiamare un messaggio e può essere consegnato un segnale risultante dall'arrivo dello stesso messaggio. Quando un segnale viene consegnato, un'applicazione deve essere preparata per non rendere disponibile alcun messaggio.

Un gestore code non può avere più di una richiesta di segnale in sospeso.

Per una chiamata MQGET su una coda condivisa e la chiamata è una richiesta di ricerca o un richiamo distruttivo di un messaggio di gruppo, e non è necessario associare né MsgId né CorrelId , il segnale dell'utente ECB viene inviato MQEC_MSG_ARRIVED dopo 200 millisecondi.

Ciò si verifica, anche se un messaggio adatto potrebbe non essere arrivato sulla coda, fino a quando l'intervallo di attesa non è scaduto, quando la coda viene inviata con MQEC_WAIT_INTERVAL_EXPIRED. Quando MQEC_MSG_ARRIVED viene pubblicato, è necessario emettere nuovamente una seconda chiamata MQGET per richiamare il messaggio, se disponibile.

Questa tecnica viene utilizzata per garantire che l'utente venga informato in modo tempestivo dell'arrivo di un messaggio, ma può apparire come un sovraccarico di elaborazione imprevisto quando viene confrontato con una sequenza di chiamata simile su una coda non condivisa.

Questo non è un metodo efficiente di richiamo dei messaggi quando i messaggi vengono aggiunti raramente. Per evitare questo sovraccarico per il caso di esplorazione, specificare MsgId (se non indicizzato o indicizzato da MsgId) o CorrelId (se indicizzato da CorrelId) corrispondente alla chiamata MQGET .

Questa opzione è supportata solo su z/OS .

In z/OS, questa opzione forza anche l'esito negativo della chiamata MQGET se la connessione (per un'applicazione CICS® o IMS ) si trova nello stato di inattività.

È possibile lasciare MQGMO_SYNCPOINT e MQGMO_NO_SYNCPOINT non impostati. In tal caso, l'inclusione della richiesta get nei protocolli UOW è determinata dall'ambiente che esegue il gestore code. Non è determinato dall'ambiente che esegue l'applicazione. Su z/OS, la richiesta get si trova all'interno di un'unità di lavoro. In tutti gli altri ambienti, la richiesta get non si trova all'interno di un'unità di lavoro.

A causa di queste differenze, un'applicazione che si desidera trasferire non deve consentire l'impostazione predefinita di questa opzione; specificare esplicitamente MQGMO_SYNCPOINT o MQGMO_NO_SYNCPOINT .

• Se il messaggio è persistente, il gestore code elabora la chiamata come se l'applicazione avesse specificato MQGMO_SYNCPOINT.
• Se il messaggio non è persistente, il gestore code elabora la chiamata come se l'applicazione avesse specificato MQGMO_NO_SYNCPOINT.

Questa opzione è supportata nei seguenti ambienti: AIX®, HP-UX, z/OS, IBM® i, Solarise Linux®, più IBM MQ MQI clients connessi a questi sistemi.

Questa opzione viene assunta se si specifica MQGMO_BROWSE_FIRST o MQGMO_BROWSE_NEXT.

È possibile lasciare MQGMO_SYNCPOINT e MQGMO_NO_SYNCPOINT non impostati. In tal caso, l'inclusione della richiesta get nei protocolli UOW è determinata dall'ambiente che esegue il gestore code. Non è determinato dall'ambiente che esegue l'applicazione. Su z/OS, la richiesta get si trova all'interno di un'unità di lavoro. In tutti gli altri ambienti, la richiesta get non si trova all'interno di un'unità di lavoro.

A causa di queste differenze, un'applicazione che si desidera trasferire non deve consentire l'impostazione predefinita di questa opzione; specificare esplicitamente MQGMO_SYNCPOINT o MQGMO_NO_SYNCPOINT .

Una chiamata MQGET con MQGMO_BROWSE_FIRST ignora la precedente posizione del cursore di ricerca. Viene richiamato il primo messaggio sulla coda che soddisfa le condizioni specificate nel descrittore del messaggio. Il messaggio rimane nella coda e il cursore di ricerca è posizionato su questo messaggio.

Dopo questa chiamata, il cursore di ricerca viene posizionato sul messaggio che è stato restituito. Il messaggio potrebbe essere rimosso dalla coda prima che venga emessa la successiva chiamata MQGET con MQGMO_BROWSE_NEXT . In questo caso, il cursore di ricerca rimane nella posizione nella coda occupata dal messaggio, anche se tale posizione è ora vuota.

Utilizzare l'opzione MQGMO_MSG_UNDER_CURSOR con una chiamata MQGET non - browse per rimuovere il messaggio dalla coda.

Il cursore di ricerca non viene spostato da una chiamata MQGET non di ricerca, anche se si utilizza lo stesso handle Hobj . Inoltre, non viene spostato da una chiamata MQGET di ricerca che restituisce un codice di completamento di MQCC_FAILEDo un codice motivo di MQRC_TRUNCATED_MSG_FAILED.

Specificare l'opzione MQGMO_LOCK con questa opzione, per bloccare il messaggio visualizzato.

È possibile specificare MQGMO_BROWSE_FIRST con qualsiasi combinazione valida delle opzioni MQGMO_* e MQMO_* che controllano l'elaborazione dei messaggi in gruppi e segmenti di messaggi logici.

Se si specifica MQGMO_LOGICAL_ORDER, i messaggi vengono esaminati in ordine logico. Se si omette tale opzione, i messaggi vengono visualizzati in ordine fisico. Se si specifica MQGMO_BROWSE_FIRST, è possibile passare tra ordine logico e ordine fisico. Le chiamate MQGET successive che utilizzano MQGMO_BROWSE_NEXT sfogliano la coda nello stesso ordine della chiamata più recente che ha specificato MQGMO_BROWSE_FIRST per l'handle di coda.

Il gestore code conserva due serie di informazioni di gruppi e segmenti per le chiamate MQGET . Le informazioni sul gruppo e sul segmento per le chiamate di esplorazione vengono conservate separatamente dalle informazioni per le chiamate che rimuovono i messaggi dalla coda. Se si specifica MQGMO_BROWSE_FIRST, il gestore code ignora le informazioni sul gruppo e sul segmento per la ricerca. Esegue la scansione della coda come se non ci fossero gruppi correnti e messaggi logici correnti. Se la chiamata MQGET ha esito positivo, codice di completamento MQCC_OK o MQCC_WARNING, le informazioni sul gruppo e sul segmento per la ricerca sono impostate su quelle del messaggio restituito. Se la chiamata ha esito negativo, le informazioni sul gruppo e sul segmento rimangono le stesse che erano prima della chiamata.

Il messaggio puntato dal cursore di ricerca è quello che è stato richiamato per ultimo utilizzando l'opzione MQGMO_BROWSE_FIRST o MQGMO_BROWSE_NEXT .

Se MQGMO_COMPLETE_MSG viene specificato con MQGMO_MSG_UNDER_CURSOR, il cursore di esplorazione deve identificare un messaggio il cui campo Offset in MQMD è zero. Se questa condizione non viene soddisfatta, la chiamata ha esito negativo con codice di errore MQRC_INVALID_MSG_UNDER_CURSOR.

Il messaggio non viene rimosso dalla coda.

Il contrassegno di livello cooperativo è in aggiunta a qualsiasi contrassegno di livello handle che potrebbe essere stato impostato.

Il messaggio non viene rimosso dalla coda.

Se il messaggio è già contrassegnato e l'opzione MQGMO_UNMARKED_BROWSE_MSG non è specificata, la chiamata ha esito negativo con MQCC_FAILED e codice motivo MQRC_MSG_MARKED_BROWSE_CO_OP.

L'uso di MQGMO_UNMARK_BROWSE_CO_OP è valido solo con un handle restituito da una chiamata riuscita a MQOPEN con opzione MQOO_CO_OP. Il MQGET ha esito positivo anche se il messaggio non è considerato contrassegnato dalla serie di handle cooperante.

La chiamata ha esito positivo anche se il messaggio non è contrassegnato per questo handle.

• MQGMO_BROWSE_FIRST
• MQGMO_BROWSE_NEXT
• MQGMO_BROWSE_MSG_UNDER_CURSOR

Il messaggio bloccato è sempre quello sotto il cursore di ricerca. Il messaggio può essere rimosso dalla coda da una chiamata MQGET successiva che specifica l'opzione MQGMO_MSG_UNDER_CURSOR . Anche altre chiamate MQGET che utilizzano l'handle della coda possono rimuovere il messaggio (ad esempio, una chiamata che specifica l'identificativo del messaggio bloccato).

Se la chiamata restituisce il codice di completamento MQCC_FAILEDo MQCC_WARNING con codice motivo MQRC_TRUNCATED_MSG_FAILED, non viene bloccato alcun messaggio.

MQGMO_LOCK non è possibile quando si utilizza un IBM MQ client su HP Integrity NonStop Server in un gestore code z/OS quando è coordinato da TMF.

I parametri MsgDesc, BufferLength, Buffere DataLength non vengono controllati o modificati se si specifica MQGMO_UNLOCK. Nessun messaggio viene restituito in Buffer.

Non è richiesta alcuna opzione di apertura speciale per specificare MQGMO_UNLOCK (anche se MQOO_BROWSE è necessario per emettere la richiesta di blocco in primo luogo).

• Quando si sfogliano i messaggi, il cursore di esplorazione viene avanzato al messaggio restituito.
• Quando si rimuovono i messaggi, il messaggio restituito viene rimosso dalla coda.
• Se non si verifica alcun altro errore, viene restituito il codice motivo MQRC_TRUNCATED_MSG_ACCEPTED.

• Quando si sfogliano i messaggi, il cursore di esplorazione non è avanzato.
• Quando si rimuovono i messaggi, il messaggio non viene rimosso dalla coda.
• Se non si verifica alcun altro errore, viene restituito il codice di errore MQRC_TRUNCATED_MSG_FAILED .

Consultare il campo Format descritto in MQMD - Descrittore messaggi per un elenco di nomi formato per cui il gestore code esegue la conversione.

Un messaggio logico che è stato segmentato è costituito da due o più messaggi fisici che hanno lo stesso identificativo di gruppo non null, campo GroupId in MQMD. Hanno lo stesso numero di sequenza del messaggio, campo MsgSeqNumber in MQMD. I segmenti sono distinti da valori differenti per l'offset del segmento, campo Offset in MQMD. L'offset del segmento è l'offset dei dati nel messaggio fisico dall'inizio dei dati nel messaggio logico. Poiché ogni segmento è un messaggio fisico, i segmenti in un messaggio logico di solito hanno identificativi di messaggio differenti.

Un messaggio logico che non è stato segmentato, ma per cui la segmentazione è stata consentita dall'applicazione di invio, ha anche un identificativo di gruppo non null. In questo caso, esiste un solo messaggio fisico con tale identificativo di gruppo se il messaggio logico non appartiene a un gruppo di messaggi. I messaggi logici, per i quali la segmentazione è stata inibita dall'applicazione di invio, hanno un identificativo di gruppo null, MQGI_NONE, a meno che il messaggio logico non appartenga a un gruppo di messaggi.

Se MQGMO_LOGICAL_ORDER viene specificato per le chiamate MQGET successive per lo stesso handle della coda, i messaggi nei gruppi vengono restituiti nell'ordine dei relativi numeri di sequenza dei messaggi. I segmenti dei messaggi logici vengono restituiti nell'ordine fornito dagli offset dei segmenti. Questo ordine potrebbe essere diverso dall'ordine in cui tali messaggi e segmenti si verificano nella coda.

Per restituire i messaggi nell'ordine richiesto, il gestore code conserva le informazioni sul gruppo e sul segmento tra le chiamate MQGET successive. Le informazioni sul gruppo e sul segmento identificano il gruppo di messaggi corrente e il messaggio logico corrente per l'handle della coda. Identifica inoltre la posizione corrente all'interno del gruppo e del messaggio logico e se i messaggi vengono richiamati all'interno di un'unità di lavoro. Poiché il gestore code conserva queste informazioni, l'applicazione non deve impostare le informazioni sul gruppo e sul segmento prima di ogni chiamata MQGET . In particolare, significa che l'applicazione non deve impostare i campi GroupId, MsgSeqNumbere Offset in MQMD. Tuttavia, l'applicazione deve impostare correttamente l'opzione MQGMO_SYNCPOINT o MQGMO_NO_SYNCPOINT su ogni chiamata.

Se sulla coda sono presenti più gruppi di messaggi idonei per la restituzione, i gruppi vengono restituiti nell'ordine determinato dalla posizione sulla coda del primo segmento del primo messaggio logico in ciascun gruppo. Vale a dire, i messaggi fisici che hanno un numero di sequenza di messaggi pari a 1 e gli offset pari a 0, determinano l'ordine in cui vengono restituiti i gruppi idonei.

Quando si specifica MQGMO_LOGICAL_ORDER , l' MQGMO fornito nella chiamata MQGET non deve essere minore di MQGMO_VERSION_2e l' MQMD non deve essere minore di MQMD_VERSION_2. Se questa condizione non viene soddisfatta, la chiamata ha esito negativo con il codice di errore MQRC_WRONG_GMO_VERSION o MQRC_WRONG_MD_VERSION, come appropriato.

Se MQGMO_LOGICAL_ORDER non è specificato per chiamate successive MQGET per l'handle della coda, i messaggi vengono restituiti indipendentemente dal fatto che appartengano a gruppi di messaggi o se siano segmenti di messaggi logici. Ciò significa che i messaggi o i segmenti di un particolare gruppo o messaggio logico potrebbero essere restituiti fuori ordine o mescolati con messaggi o segmenti di altri gruppi o messaggi logici o con messaggi che non sono in gruppi e non sono segmenti. In questa situazione, i messaggi particolari restituiti da chiamate MQGET successive sono controllati dalle opzioni MQMO_* specificate su tali chiamate (per i dettagli su queste opzioni, consultare il campo MatchOptions descritto in MQGMO - Get - message options ).

Questa è la tecnica che può essere utilizzata per riavviare un gruppo di messaggi o un messaggio logico nel mezzo, dopo che si è verificato un errore di sistema. Quando il sistema viene riavviato, l'applicazione può impostare i campi GroupId, MsgSeqNumber, Offsete MatchOptions sui valori appropriati, quindi emettere la chiamata MQGET con MQGMO_SYNCPOINT o MQGMO_NO_SYNCPOINT impostati, ma senza specificare MQGMO_LOGICAL_ORDER. Se questa chiamata ha esito positivo, il gestore code conserva le informazioni sul gruppo e sul segmento e le successive chiamate MQGET che utilizzano tale handle di coda possono specificare MQGMO_LOGICAL_ORDER come normale.

Le applicazioni che desiderano richiamare i messaggi e i segmenti in ordine logico sono consigliabili per specificare MQGMO_LOGICAL_ORDER, poiché questa è l'opzione più semplice da utilizzare. Questa opzione allevia l'applicazione della necessità di gestire le informazioni sul gruppo e sul segmento, poiché il gestore code gestisce tali informazioni. Tuttavia, le applicazioni specializzate potrebbero richiedere un controllo maggiore rispetto a quello fornito dall'opzione MQGMO_LOGICAL_ORDER e ciò può essere ottenuto non specificando tale opzione. L'applicazione deve quindi verificare che i campi MsgId, CorrelId, GroupId, MsgSeqNumbere Offset in MQMDe le opzioni MQMO_* in MatchOptions in MQGMOsiano impostati correttamente, prima di ogni chiamata MQGET .

Ad esempio, un'applicazione che desidera inoltrare i messaggi fisici che riceve, indipendentemente dal fatto che tali messaggi si trovino in gruppi o segmenti di messaggi logici, non deve specificare MQGMO_LOGICAL_ORDER. In una rete complessa con più percorsi tra i gestori code di invio e di ricezione, i messaggi fisici potrebbero arrivare fuori ordine. Specificando né MQGMO_LOGICAL_ORDER, né il MQPMO_LOGICAL_ORDER corrispondente nella chiamata MQPUT, l'applicazione di inoltro può recuperare e inoltrare ogni messaggio fisico non appena arriva, senza dover attendere il successivo in ordine logico.

Per utilizzare questa opzione, l'applicazione deve fornire un buffer abbastanza grande da contenere il messaggio completo oppure specificare l'opzione MQGMO_ACCEPT_TRUNCATED_MSG .

Se la coda contiene messaggi segmentati con alcuni dei segmenti mancanti (forse perché sono stati ritardati nella rete e non sono ancora arrivati), specificando MQGMO_COMPLETE_MSG si impedisce il richiamo dei segmenti appartenenti a messaggi logici incompleti. Tuttavia, tali segmenti di messaggi contribuiscono ancora al valore dell'attributo della coda CurrentQDepth ; ciò significa che potrebbero non essere presenti messaggi logici richiamabili, anche se CurrentQDepth è maggiore di zero.

Per i messaggi non persistenti , il gestore code non richiede un'unità di lavoro disponibile per eseguire il riassemblaggio.

Ogni messaggio fisico che è un segmento ha il proprio descrittore di messaggi. Per i segmenti che costituiscono un singolo messaggio logico, la maggior parte dei campi nel descrittore del messaggio sono gli stessi per tutti i segmenti nel messaggio logico; di solito sono solo i campi MsgId, Offsete MsgFlags che differiscono tra i segmenti nel messaggio logico. Tuttavia, se un segmento viene posizionato su una coda di messaggi non recapitabili in un gestore code intermedio, il gestore DLQ richiama il messaggio specificando l'opzione MQGMO_CONVERT e ciò può causare la modifica della serie di caratteri o della codifica del segmento. Se il gestore DLQ invia correttamente il segmento nel suo percorso, il segmento potrebbe avere una serie di caratteri o una codifica diversa dagli altri segmenti nel messaggio logico quando il segmento arriva al gestore code di destinazione.

Un messaggio logico costituito da segmenti in cui i campi di CodedCharSetId e Encoding differiscono non può essere riassemblato dal gestore code in un singolo messaggio logico. Invece, il gestore code riassembla e restituisce i primi segmenti consecutivi all'inizio del messaggio logico che hanno gli stessi identificativi e codifiche della serie di caratteri e la chiamata MQGET viene completata con il codice di completamento MQCC_WARNING e il codice motivo MQRC_INCONSISTENT_CCSIDS o MQRC_INCONSISTENT_ENCODINGS, come appropriato. Ciò si verifica indipendentemente dal fatto che MQGMO_CONVERT sia specificato o meno. Per richiamare i rimanenti segmenti, l'applicazione deve emettere nuovamente la chiamata MQGET senza l'opzione MQGMO_COMPLETE_MSG , richiamando i segmenti uno alla volta. MQGMO_LOGICAL_ORDER può essere utilizzato per richiamare i rimanenti segmenti in ordine.

Un'applicazione che inserisce segmenti può anche impostare altri campi nel descrittore del messaggio su valori che differiscono tra i segmenti. Tuttavia, non vi è alcun vantaggio se l'applicazione ricevente utilizza MQGMO_COMPLETE_MSG per richiamare il messaggio logico. Quando il gestore code riassembla un messaggio logico, restituisce nel descrittore del messaggio i valori del descrittore del messaggio per il primo segmento; l'unica eccezione è il campo MsgFlags , impostato dal gestore code per indicare che il messaggio riassemblato è l'unico segmento.

Se MQGMO_COMPLETE_MSG è specificato per un messaggio di report, il gestore code esegue un'elaborazione speciale. Il gestore code controlla la coda per vedere se tutti i messaggi di report di quel tipo relativi ai diversi segmenti nel messaggio logico sono presenti nella coda. Se lo sono, possono essere richiamati come un singolo messaggio specificando MQGMO_COMPLETE_MSG. Affinché ciò sia possibile, i messaggi di report devono essere generati da un gestore code o da un MCA che supporta la segmentazione oppure l'applicazione di origine deve richiedere almeno 100 byte di dati del messaggio (ovvero, è necessario specificare le opzioni MQRO_*_WITH_DATA o MQRO_*_WITH_FULL_DATA appropriate). Se per un segmento è presente meno dell'intera quantità di dati dell'applicazione, i byte mancanti vengono sostituiti da valori null nel messaggio di report restituito.

Se MQGMO_COMPLETE_MSG viene specificato con MQGMO_MSG_UNDER_CURSOR o MQGMO_BROWSE_MSG_UNDER_CURSOR, il cursore di esplorazione deve essere posizionato su un messaggio il cui campo Offset in MQMD ha un valore pari a 0. Se questa condizione non viene soddisfatta, la chiamata ha esito negativo con codice di errore MQRC_INVALID_MSG_UNDER_CURSOR.

MQGMO_COMPLETE_MSG implica MQGMO_ALL_SEGMENTS_AVAILABLE, che quindi non deve essere specificato.

Il corretto completamento di una chiamata MQGET specificando MQGMO_ALL_MSGS_AVAILABLE significa che, al momento dell'emissione della chiamata MQGET , tutti i messaggi nel gruppo si trovavano nella coda. Tuttavia, tenere presente che altre applicazioni possono ancora rimuovere i messaggi dal gruppo (il gruppo non è bloccato per l'applicazione che richiama il primo messaggio nel gruppo).

Se si omette questa opzione, i messaggi appartenenti ai gruppi possono essere richiamati anche quando il gruppo è incompleto.

MQGMO_ALL_MSGS_AVAILABLE implica MQGMO_ALL_SEGMENTS_AVAILABLE, che quindi non deve essere specificato.

Se questa opzione non viene specificata, i segmenti del messaggio possono essere richiamati anche quando il messaggio logico è incompleto.

Mentre sia MQGMO_COMPLETE_MSG che MQGMO_ALL_SEGMENTS_AVAILABLE richiedono che tutti i segmenti siano disponibili prima che possano essere richiamati, il primo restituisce il messaggio completo, mentre il secondo consente ai segmenti di essere richiamati uno per uno.

Se MQGMO_ALL_SEGMENTS_AVAILABLE è specificato per un messaggio di report, il gestore code controlla la coda per verificare se esiste almeno un messaggio di report per ciascuno dei segmenti che costituiscono il messaggio logico completo. In tal caso, viene soddisfatta la condizione MQGMO_ALL_SEGMENTS_AVAILABLE . Tuttavia, il gestore code non controlla il tipo dei messaggi di report presenti, pertanto potrebbe esserci una combinazione di tipi di report nei messaggi di report relativi ai segmenti del messaggio logico. Di conseguenza, l'esito positivo di MQGMO_ALL_SEGMENTS_AVAILABLE non implica che MQGMO_COMPLETE_MSG avrà esito positivo. Se è una combinazione di tipi di report presenti per i segmenti di un determinato messaggio logico, tali messaggi di report devono essere richiamati uno per uno.

Le proprietà del messaggio, eccetto quelle contenute nel descrittore del messaggio (o estensione), devono essere rappresentate come definito dall'attributo della coda PropertyControl . Se viene fornito un MsgHandle , questa opzione viene ignorata e le proprietà del messaggio sono disponibili tramite MsgHandle, a meno che il valore dell'attributo della coda PropertyControl non sia MQPROP_FORCE_MQRFH2.

Questa è l'azione predefinita se non vengono specificate opzioni della proprietà.

Le proprietà del messaggio devono essere rese disponibili attraverso MsgHandle. Se non viene fornita alcuna gestione messaggio, la chiamata non riesce con codice d'errore MQRC_HMSG_ERROR.

Non verrà richiamata alcuna proprietà del messaggio, ad eccezione di quelle contenute nel descrittore del messaggio (o estensione). Se è stato fornito un MsgHandle, verrà ignorato.

Le proprietà del messaggio, eccetto quelle contenute nel descrittore del messaggio (o estensione) devono essere rappresentate utilizzando intestazioni MQRFH2. Ciò fornisce la compatibilit ... con la versione precedente per le applicazioni che prevedono di recuperare le propriet ... ma non possono essere modificate per utilizzare gli handle dei messaggi. Se è stato fornito un MsgHandle, verrà ignorato.