Partager via

ALLOUER

Le ALLOCATE verbe est émis par le programme de transaction appelant (TP). Il alloue une session entre l’unité logique locale (LU) et l’unité logique partenaire et (conjointement avec RECEIVE_ALLOCATE) établit une conversation entre le TP appelant et le TP appelé. Une fois que ce verbe s’exécute correctement, APPC génère un identificateur de conversation (conv_id). Le conv_id est un paramètre requis pour tous les autres verbes de conversation APPC.

La structure suivante décrit le bloc de contrôle de verbe utilisé par le verbe ALLOCATE .

Syntaxe

  
struct allocate {  
    unsigned short   opcode;  
    unsigned char    opext;  
    unsigned char    reserv2;  
    unsigned short   primary_rc;  
    unsigned long    secondary_rc;  
    unsigned char    tp_id[8];  
    unsigned long    conv_id;  
    unsigned char    conv_type;  
    unsigned char    synclevel;  
    unsigned char    reserv3[2];  
    unsigned char    rtn_ctl;  
    unsigned char    reserv4;  
    unsigned long    conv_group_id;  
    unsigned long    sense_data;  
    unsigned char    plu_alias[8];  
    unsigned char    mode_name[8];  
    unsigned char    tp_name[64];  
    unsigned char    security;  
    unsigned char    reserv5[11];  
    unsigned char    pwd[10];  
    unsigned char    user_id[10];  
    unsigned short   pip_dlen;  
    unsigned char FAR * pip_dptr;  
    unsigned char    reserv7;  
    unsigned char    fqplu_name[17];  
    unsigned char    reserv8[8];  
    unsigned long    proxy_user;  
    unsigned long    proxy_domain;  
    unsigned char    reserv9[16];  
};

Membres

Opcode
Paramètre fourni. Spécifie le code d'opération du verbe AP_B_ALLOCATE.

opext
Paramètre fourni. Spécifie l’extension d’opération de verbe, AP_BASIC_CONVERSATION. Si le bit AP_EXTD_VCB est défini, cela indique qu’une version étendue du bloc de contrôle verbe est utilisée. Dans ce cas, la structure ALLOCATE inclut la prise en charge des points de synchronisation ou la prise en charge des fonctionnalités proxy privilégiées.

réserver2
Champ réservé.

primary_rc
Paramètre retourné. Spécifie le code de retour principal défini par APPC à l’achèvement du verbe. Les codes de retour valides varient en fonction du verbe APPC émis. Consultez les codes de retour pour obtenir des codes d’erreur valides pour ce verbe.

secondary_rc
Paramètre retourné. Spécifie le code de retour secondaire défini par APPC à l’achèvement du verbe. Les codes de retour valides varient en fonction du verbe APPC émis. Consultez les codes de retour pour obtenir des codes d’erreur valides pour ce verbe.

tp_id
Paramètre fourni. Identifie le TP local. La valeur de ce paramètre a été retournée par TP_STARTED.

conv_id
Paramètre retourné. Identifie la conversation établie entre les deux TPS.

conv_type
Paramètre fourni. Utilisé uniquement par ALLOCATE pour spécifier le type de conversation à allouer et est AP_BASIC_CONVERSATION ou AP_MAPPED_CONVERSATION.

Si ALLOCATE établit une conversation mappée, le TP local doit émettre des verbes de conversation de base et fournir sa propre couche de mappage pour convertir les enregistrements de données en enregistrements logiques et les enregistrements logiques en enregistrements de données. Le tp partenaire peut émettre des verbes de conversation de base et fournir la couche de mappage, ou utiliser des verbes mappés de conversation (si le tp partenaire utilise une implémentation d’APPC qui prend en charge les verbes de conversation mappés). Pour plus d’informations, consultez vos manuels IBM SNA.

synclevel
Paramètre fourni. Spécifie le niveau de synchronisation de la conversation. Il détermine si les FOURNISSEURS peuvent demander la confirmation de la réception des données et confirmer la réception des données.

  • AP_NONE spécifie que le traitement de confirmation ne sera pas utilisé dans cette conversation.

  • AP_CONFIRM_SYNC_LEVEL spécifie que les TPS peuvent utiliser le traitement de confirmation dans cette conversation.

  • AP_SYNCPT spécifie que les TPS peuvent utiliser le traitement de confirmation du point de synchronisation niveau 2 dans cette conversation.

    réserver3
    Champ réservé.

    rtn_ctl
    Paramètre fourni. Spécifie quand l’unité logique locale, agissant sur une demande de session du TP local, doit retourner le contrôle au tp local. Pour plus d’informations sur les sessions, consultez À propos des programmes de transaction.

  • AP_IMMEDIATE spécifie que l’unité logique alloue une session contention-gagnant, si une session est immédiatement disponible et retourne le contrôle au TP.

  • AP_WHEN_SESSION_ALLOCATED spécifie que l’unité logique ne retourne pas le contrôle au TP tant qu’elle n’alloue pas une session ou rencontre l’une des erreurs documentées dans les codes de retour de cette rubrique. (Si la limite de session est égale à zéro, la lu retourne immédiatement le contrôle.) Si une session n’est pas disponible, le tp attend un.

  • AP_WHEN_SESSION_FREE spécifie que l’unité logique alloue une session contention-winner ou contention-loser, si une session est disponible ou peut être activée, et retourne le contrôle au TP. Si une erreur se produit, (comme documenté dans les codes de retour de cette rubrique), l’appel retourne immédiatement avec l’erreur dans les champs primary_rc et secondary_rc .

  • AP_WHEN_CONWINNER_ALLOCATED spécifie que l’unité logique ne retourne pas le contrôle tant qu’elle n’attribue pas de session au gagnant de la contention ou ne rencontre l’une des erreurs figurant dans les codes de retour de cette section. (Si la limite de session est égale à zéro, la lu retourne immédiatement le contrôle.) Si une session n’est pas disponible, le tp attend un.

  • AP_WHEN_CONV_GROUP_ALLOCATED spécifie que la LU ne retourne pas le contrôle au TP tant qu'elle n'alloue pas la session spécifiée par conv_group_id ou rencontre l'une des erreurs mentionnées dans les codes de retour de cette rubrique. Si une session n’est pas disponible, le TP attend qu’il devienne gratuit.

Remarque

AP_IMMEDIATE est la seule valeur de rtn_ctl qui n’entraîne jamais le démarrage d’une nouvelle session. Pour les valeurs autres que AP_IMMEDIATE, si une session appropriée n’est pas immédiatement disponible, Host Integration Server tente de démarrer une session. Cela entraîne l’activation de la connexion à la demande.

réserver4
Champ réservé.

conv_group_id
Paramètre fourni/retourné. Spécifie l’identificateur du groupe de conversations à partir duquel la session doit être allouée. La conv_group_id n’est requise que si rtn_ctl est définie sur WHEN_CONV_GROUP_ALLOC. Lorsquertn_ctl spécifie une valeur différente et que la primary_rc est AP_OK, il s’agit d’une valeur retournée.

sense_data
Paramètre retourné. Indique une erreur d’allocation (nouvelle tentative ou nouvelle tentative) et contient des données de sens.

plu_alias
Paramètre fourni. Spécifie l’alias par lequel l’unité logique partenaire est connue du TP local.

Le plu_alias doit correspondre au nom d’une lu partenaire établie pendant la configuration.

Le paramètre est une chaîne de caractères ASCII de 8 octets. Il peut se composer des caractères ASCII suivants :

  • Lettres majuscules

  • Chiffres 0 à 9

  • Espaces

  • Caractères spéciaux $, #, %et @

    Le premier caractère de cette chaîne ne peut pas être un espace.

    Si la valeur de ce paramètre est inférieure à huit octets, placez-la à droite avec des espaces ASCII (0x20).

    Si vous souhaitez spécifier l’unité logique partenaire avec le paramètre fqplu_name , remplissez ce paramètre avec des zéros binaires.

    Pour un utilisateur ou un groupe utilisant des TPS, 5250 émulateurs et/ou des applications APPC, l’administrateur système peut attribuer des unités logiques locales et distantes par défaut. Dans ce cas, le champ est vide ou null et les unités logiques par défaut sont accessibles lorsque l’utilisateur ou le membre du groupe démarre un programme APPC. Pour plus d’informations sur les unités logiques par défaut, consultez l’aide de Microsoft Host Integration Server.

    mode_name
    Paramètre fourni. Spécifie le nom d’un ensemble de caractéristiques réseau définies pendant la configuration.

    La valeur de mode_name doit correspondre au nom d’un mode associé à l’unité logique partenaire pendant la configuration.

    Le paramètre est une chaîne de caractères EBCDIC de 8 octets. Il peut se composer de caractères à partir du jeu de caractères EBCDIC de type :

  • Lettres majuscules

  • Chiffres 0 à 9

  • Caractères spéciaux $, #et @

    Le premier caractère de la chaîne doit être une lettre majuscule ou un caractère spécial.

    N’utilisez pas SNASVCMG dans une conversation mappée. SNASVCMG est une mode_name réservée utilisée en interne par APPC. L’utilisation de ce nom dans une conversation de base n’est pas recommandée.

    tp_name
    Paramètre fourni. Spécifie le nom du TP appelé. La valeur de tp_name spécifiée par ALLOCATE dans l’appel tp doit correspondre à la valeur de tp_name spécifiée par RECEIVE_ALLOCATE dans le TP appelé.

    Le paramètre est une chaîne de caractères EBCDIC de 64 octets et respecte la casse. Le paramètre tp_name peut se composer des caractères EBCDIC suivants :

  • Lettres majuscules et minuscules

  • Chiffres 0 à 9

  • Caractères spéciaux $, #, @et point (.)

    Si tp_name est inférieur à 64 octets, utilisez des espaces EBCDIC (0x40) pour l’ajouter à droite.

    La convention SNA est qu’un nom tp de service peut avoir jusqu’à quatre caractères. Le premier caractère est un octet hexadécimal entre 0x00 et 0x3F. Les autres caractères proviennent du jeu de caractères AE EBCDIC de type.

    sécurité
    Paramètre fourni. Fournit les informations requises par l’unité logique partenaire pour valider l’accès au TP appelé.

    En fonction de la sécurité de conversation établie pour le TP appelé pendant la configuration, utilisez l’une des valeurs suivantes :

  • AP_NONE pour un TP appelé qui n’utilise aucune sécurité de conversation.

  • AP_PGM pour un TP appelé qui utilise la sécurité des conversations et nécessite donc un identificateur d’utilisateur et un mot de passe. Fournissez ces informations via les paramètres user_id et pwd .

  • AP_PROXY_PGM pour un TP appelé avec un proxy privilégié qui utilise la sécurité des conversations et nécessite donc un identificateur d’utilisateur et un mot de passe. Les pointeurs doivent être configurés pour proxy_user et proxy_domain pour pointer vers des chaînes Unicode contenant le nom d’utilisateur et le nom de domaine de l’utilisateur à emprunter l’identité. L’application n’a pas besoin de définir les champs user_id et pwd .

  • AP_PROXY_SAME pour un TP qui a été appelé à l’aide d’un proxy privilégié avec un identificateur d’utilisateur et un mot de passe valides fournis par le proxy, qui appelle à son tour un autre TP. Les pointeurs doivent être configurés pour proxy_user et proxy_domain pour pointer vers des chaînes Unicode contenant le nom d’utilisateur et le nom de domaine de l’utilisateur à emprunter l’identité. L’application n’a pas besoin de définir les champs user_id et pwd .

    Par exemple, supposons que TP A appelle TP B avec un identificateur d’utilisateur et un mot de passe valides fournis par le proxy privilégié, et TP B appelle à son tour TP C. Si TP B spécifie la valeur AP_PROXY_SAME, APPC envoie l’unité logique pour TP C l’identificateur utilisateur de TP A et un indicateur déjà vérifié. Cet indicateur indique à TP C de ne pas exiger le mot de passe (si TP C est configuré pour accepter un indicateur déjà vérifié).

  • AP_PROXY_STRONG pour un TP appelé avec un proxy privilégié qui utilise la sécurité des conversations et nécessite donc un identificateur d’utilisateur et un mot de passe fournis par le mécanisme de proxy privilégié. Les pointeurs doivent être configurés pour proxy_user et proxy_domain pour pointer vers des chaînes Unicode contenant le nom d’utilisateur et le nom de domaine de l’utilisateur à emprunter l’identité. L’application n’a pas besoin de définir les champs user_id et pwd . AP_PROXY_STRONG diffère de AP_PROXY_PGM dans ce AP_PROXY_STRONG n’autorise pas les mots de passe en texte clair. Si le système distant ne prend pas en charge les mots de passe chiffrés (sécurité de conversation forte), cet appel échoue.

  • AP_SAME pour un TP qui a été appelé avec un identificateur d’utilisateur et un mot de passe valides, qui appelle à son tour un autre TP.

    Par exemple, supposons que TP A appelle TP B avec un identificateur d’utilisateur et un mot de passe valides, et TP B appelle à son tour TP C. Si TP B spécifie la valeur AP_SAME, APPC envoie l’unité logique pour TP C l’identificateur utilisateur de TP A et un indicateur déjà vérifié. Cet indicateur indique à TP C de ne pas exiger le mot de passe (si TP C est configuré pour accepter un indicateur déjà vérifié).

    Lorsque AP_SAME est utilisé dans un verbe ALLOCATE , votre application doit toujours fournir des valeurs pour les paramètres user_id et pwd dans le bloc de contrôle verbe. Selon les propriétés négociées entre le serveur SNA et l’unité logique homologue, le verbe ALLOCATE envoie l’un des trois types de messages d’attachement (FMH-5), dans cet ordre de priorité :

  1. Si les unités logiques ont négocié la sécurité « déjà vérifiée », le message d'attachement envoyé par le serveur SNA n'inclura pas le contenu du champ de paramètre pwd spécifié dans le VCB.

  2. Si les unités logiques ont négocié la sécurité de « vérification persistante », alors l'Attacher envoyé par le serveur SNA inclura le paramètre pwd spécifié dans le VCB, mais uniquement lorsque l'Attacher est le premier pour le paramètre user_id spécifié depuis le début de la session LU-LU, et il omettra le paramètre pwd sur toutes les Attachers suivants (émis par votre application ou toute autre application utilisant ce triplet en mode LU-LU).

  3. Si les unités logiques n'ont pas négocié l'un des points mentionnés ci-dessus, l'attachement envoyé par le serveur SNA omettra les paramètres user_id et pwd sur toutes les attaches.

    Votre application ne peut pas déterminer quel mode de sécurité a été négocié entre les LUs, ni si le verbe ALLOCATE qu'elle émet est le premier pour ce triplet de mode LU-LU. Par conséquent, votre application doit toujours définir les champs de paramètres user_id et pwd dans le VCB lorsque la sécurité est définie sur AP_SAME.

    Pour plus d’informations sur la vérification permanente et la sécurité déjà vérifiée, consultez le Guide des formats SNA, section « Fm Header 5 : Attach (LU 6.2) ».

  • AP_STRONG pour un TP appelé qui utilise la sécurité des conversations et nécessite donc un identificateur d’utilisateur et un mot de passe. Fournissez ces informations via les paramètres user_id et pwd . AP_STRONG diffère de AP_PGM dans cette AP_STRONG n’autorise pas les mots de passe en texte clair. Si le système distant ne prend pas en charge les mots de passe chiffrés (sécurité de conversation forte), cet appel échoue.

    Si la fonctionnalité d’ouverture de session automatique APPC doit être utilisée, la sécurité doit être définie sur AP_PGM. Pour plus d’informations, consultez la section Remarques.

    réserver5
    Champ réservé.

    Pwd
    Paramètre fourni. Spécifie le mot de passe associé à user_id.

    Le paramètre pwd n’est requis que si la sécurité est définie sur AP_PGM ou AP_SAME. Il doit correspondre au mot de passe de user_id qui a été établi pendant la configuration.

    Le paramètre pwd est une chaîne de caractères EBCDIC de 10 octets et respecte la casse. Il peut se composer des caractères EBCDIC suivants :

  • Lettres majuscules et minuscules

  • Chiffres 0 à 9

  • Caractères spéciaux $, #, @et point (.)

    Si le mot de passe est inférieur à 10 octets, utilisez des espaces EBCDIC (0x40) pour le remplir à droite.

    Si la fonctionnalité d’ouverture de session automatique APPC doit être utilisée, la chaîne de caractères pwd doit être codée en dur sur MS$SAME. Pour plus d’informations, consultez la section Remarques.

    user_id
    Paramètre fourni. Spécifie l’identificateur de l’utilisateur requis pour accéder au tp partenaire. Il n’est nécessaire que si le paramètre de sécurité est défini sur AP_PGM ou AP_SAME.

    Le paramètre user_id est une chaîne de caractères EBCDIC de 10 octets et respecte la casse. Il doit correspondre à l’un des identificateurs utilisateur configurés pour le TP partenaire.

    Le paramètre peut se composer des caractères EBCDIC suivants :

  • Lettres majuscules et minuscules

  • Chiffres 0 à 9

  • Caractères spéciaux $, #, @et point (.)

    Si user_id est inférieur à 10 octets, utilisez des espaces EBCDIC (0x40) pour l’ajouter à droite.

    Si la fonctionnalité d’ouverture de session automatique APPC doit être utilisée, la chaîne de caractères user_id doit être codée en dur sur MS$SAME. Pour plus d’informations, consultez la section Remarques.

    pip_dlen
    Paramètre fourni. Spécifie la longueur des paramètres d’initialisation du programme (PIP) à passer au TP partenaire. La plage est comprise entre 0 et 32767.

    pip_dptr
    Paramètre fourni. Spécifie l’adresse de la mémoire tampon contenant des données PIP. Utilisez ce paramètre uniquement si pip_dlen est supérieur à zéro.

    Les données PIP peuvent être constituées de paramètres d’initialisation ou d’informations d’installation environnementale requises par un tp partenaire ou un système d’exploitation distant. Les données PIP doivent suivre le format de flux de données général (GDS). Pour plus d’informations, consultez référence SNA LU6.2 : Protocoles homologues publiés par IBM.

    Pour Windows, la mémoire tampon de données peut résider dans une zone de données statique ou dans une zone allouée globalement. La mémoire tampon de données doit s’adapter entièrement à cette zone.

    réserver7
    Champ réservé.

    fqplu_name
    Paramètre fourni. Spécifie le nom complet de l’unité logique partenaire. Cela doit correspondre au nom complet de l’unité logique locale définie dans le nœud distant. Le paramètre se compose de deux chaînes de caractères EBCDIC de type pour le NETID et le nom lu de l’unité logique partenaire. Les noms sont séparés par un point EBCDIC (.).

    Ce nom doit être fourni si aucune plu_alias n’est spécifiée. Il peut se composer des caractères EBCDIC suivants :

  • Lettres majuscules

  • Chiffres 0 à 9

  • Caractères spéciaux $, #et @

    Si la valeur de ce paramètre est inférieure à 17 octets, remplissez-la à droite avec des espaces EBCDIC (0x40).

    réserver8
    Champ réservé.

    proxy_user
    Paramètre fourni. Spécifie une LPWSTR pointant vers une chaîne Unicode contenant le nom d’utilisateur à emprunter l’identité à l’aide de la fonctionnalité de proxy privilégié. Ce champ ne peut être utilisé que lorsque le bit AP_EXTD_VCB est défini sur le champ opext , indiquant une base de données VCB étendue.

    proxy_domain
    Paramètre fourni. Spécifie une LPWSTR pointant vers une chaîne Unicode contenant le nom de domaine de l’utilisateur à emprunter l’identité à l’aide de la fonctionnalité de proxy privilégié. Ce champ ne peut être utilisé que lorsque le bit AP_EXTD_VCB est défini sur le champ opext , indiquant une base de données VCB étendue.

    réserver9
    Champ réservé.

Codes de retour

AP_OK
Code de retour principal ; le verbe exécuté avec succès.

AP_UNSUCCESSFUL
Code de retour principal ; le paramètre fourni rtn_ctl retour immédiat (AP_IMMEDIATE) spécifié du contrôle au TP, et l’unité logique locale n’a pas eu de session contention-gagnant disponible.

AP_PARAMETER_CHECK
Code de retour principal ; le verbe n’a pas été exécuté en raison d’une erreur de paramètre.

AP_BAD_RETURN_CONTROL (Contrôle de retour invalide)

Code de retour secondaire ; la valeur spécifiée pour rtn_ctl n’était pas valide.

AP_MAUVAIS SÉCURITÉ

Code de retour secondaire ; la valeur spécifiée pour la sécurité n’était pas valide.

AP_BAD_SYNC_LEVEL

Code de retour secondaire ; la valeur spécifiée pour sync_level n’était pas valide.

AP_BAD_TP_ID

Code de retour secondaire ; la valeur spécifiée pour tp_id n’était pas valide.

AP_PIP_LEN_INCORRECT

Code de retour secondaire ; la valeur de pip_dlen a été supérieure à 32767.

Mode partenaire inconnu

Code de retour secondaire ; la valeur spécifiée pour mode_name n’était pas valide.

AP_BAD_PARTNER_LU_ALIAS

Code de retour secondaire ; APPC n’a pas reconnu le partner_lu_alias fourni.

AP_BAD_CONV_TYPE (pour une conversation de base)

Code de retour secondaire ; la valeur spécifiée pour conv_type n’était pas valide.

AP_NO_USE_OF_SNASVCMG (pour une conversation mappée)

Code de retour secondaire ; SNASVCMG n’est pas une valeur valide pour mode_name.

SEGMENT DE DONNÉES NON VALIDE

Code de retour secondaire ; les données PIP étaient plus longues que le segment de données alloué, ou l’adresse de la mémoire tampon de données PIP était incorrecte.

ERREUR_D'ALLOCATION_AP
Code de retour principal ; APPC n’a pas pu allouer une conversation. L’état de la conversation est défini sur RESET.

Ce code peut être retourné par le biais d’un verbe émis après ALLOCATE.

AP_ALLOCATION_FAILURE_NO_RETRY

Code de retour secondaire ; la conversation ne peut pas être allouée en raison d’une condition permanente, telle qu’une erreur de configuration ou une erreur de protocole de session. Pour déterminer l’erreur, l’administrateur système doit examiner le fichier journal des erreurs. Ne réessayez pas l’allocation tant que l’erreur n’a pas été corrigée.

ÉCHEC_ALLOCATION_AP_RELANCER

Code de retour secondaire ; la conversation n’a pas pu être allouée en raison d’une condition temporaire, telle qu’une défaillance de lien. La raison de l’échec est journalisée dans le journal des erreurs système. Réessayez l’allocation.

AP_COMM_SUBSYSTEM_ABENDED
Code de retour principal ; indique l’une des conditions suivantes :

  • Le nœud utilisé par cette conversation a rencontré un ABEND.

  • La connexion entre le tp et le nœud PU 2.1 a été interrompue (erreur LAN).

  • Le SnaBase sur l’ordinateur du TP a rencontré un ABEND.

    L’administrateur système doit examiner le journal des erreurs pour déterminer la raison de l’ABEND.

    AP_COMM_SUBSYSTEM_NOT_LOADED
    Code de retour principal ; un composant requis n’a pas pu être chargé ou arrêté lors du traitement du verbe. Ainsi, la communication n’a pas pu avoir lieu. Contactez l’administrateur système pour obtenir une action corrective.

    Lorsque ce code de retour est utilisé avec ALLOCATE, il peut indiquer qu’aucun système de communication n’est trouvé pour prendre en charge l’unité logique locale. (Par exemple, l’alias lu local spécifié avec TP_STARTED est incorrect ou n’a pas été configuré.) Notez que si lu_alias ou mode_name est inférieur à huit caractères, vous devez vous assurer que ces champs sont remplis d’espaces à droite. Cette erreur est retournée si ces paramètres ne sont pas remplis d’espaces, car aucun nœud n’est disponible pour satisfaire la requête ALLOCATE .

    Lorsque ALLOCATE produit ce code de retour pour le système configuré avec plusieurs nœuds à l’aide d’Host Integration Server, il existe deux codes de retour secondaires comme suit :

    0xF0000001

    Code de retour secondaire ; aucun nœud n’a été démarré.

    0xF0000002

    Code de retour secondaire ; au moins un nœud a été démarré, mais l’unité logique locale (lorsque TP_STARTED est émise) n’est pas configurée sur des nœuds actifs. Le problème peut être l’un des suivants :

  • Le nœud avec l’unité logique locale n’est pas démarré.

  • L’unité logique locale n’est pas configurée.

    AP_INVALID_VERB_SEGMENT
    Code de retour principal ; le VCB s’étend au-delà de la fin du segment de données.

    Taille de la pile AP trop petite
    Code de retour principal ; la taille de la pile de l’application est trop petite pour exécuter le verbe. Augmentez la taille de la pile de votre application.

    AP_CONV_OCCUPÉ
    Code de retour principal ; il ne peut y avoir qu’un seul verbe de conversation en suspens à la fois sur n’importe quelle conversation. Cela peut se produire si le TP local a plusieurs threads et que plusieurs threads émettent des appels APPC à l’aide du même conv_id.

    AP_THREAD_BLOCKING
    Code de retour principal ; le thread appelant est déjà dans un appel bloquant.

    ERREUR_INATTENDUE_DOS
    Code de retour principal ; le système d’exploitation a retourné une erreur à APPC lors du traitement d’un appel APPC à partir du TP local. Le code de retour du système d’exploitation est retourné via le secondary_rc. Il apparaît dans l’ordre d’échange d’octets Intel. Si le problème persiste, consultez l’administrateur système.

Remarques

ALLOCATE peut établir une conversation de base ou mappée.

L’état de la conversation est RESET lorsque le TP émet ce verbe. Une fois l’exécution réussie (primary_rc est AP_OK), l’état passe à SEND. Si le verbe n’est pas exécuté, l’état reste inchangé.

Plusieurs paramètres d’ALLOCATE sont des chaînes EBCDIC ou ASCII. Un TP peut utiliser le verbe de service commun (CSV) CONVERT pour traduire une chaîne d’un jeu de caractères vers l’autre.

Pour envoyer immédiatement la requête ALLOCATION, le TP invoquant peut émettre FLUSH ou CONFIRMER immédiatement après ALLOCATE. Sinon, la requête ALLOCATE s’accumule avec d’autres données dans la mémoire tampon d’envoi de l’unité logique locale jusqu’à ce que la mémoire tampon soit pleine.

En émettant CONFIRM after ALLOCATE, le TP appelant peut déterminer immédiatement si l’allocation a réussi (si synclevel est défini sur AP_CONFIRM_SYNC_LEVEL).

Normalement, la valeur du paramètre mode_name du verbe ALLOCATE doit correspondre au nom d’un mode configuré pour le nœud du TP appelé et associé pendant la configuration avec l’unité logique partenaire.

Si l’un des modes associés à l’unité logique partenaire sur le nœud du TP appelé est un mode implicite, la session établie entre les deux unités logiques est du mode implicite lorsqu’aucun nom de mode associé à l’unité logique partenaire ne correspond à la valeur de mode_name.

Host Integration Server prend en charge une fonctionnalité appelée substitution de mot de passe. Il s’agit d’une fonctionnalité de sécurité prise en charge par le système d’exploitation IBM i qui chiffre tout mot de passe qui circule entre deux nœuds sur un message Attach. Un mot de passe circule sur un Attachement chaque fois qu’une personne appelle un programme de transaction APPC spécifiant un identificateur d’utilisateur et un mot de passe. Par exemple, cela se produit chaque fois que quelqu’un se connecte à un IBM i.

La prise en charge de la substitution de mot de passe est indiquée en définissant le bit 5 en octet 23 de la demande BIND sur 1 (ce qui indique que la substitution de mot de passe est prise en charge). Si le système distant définit ce bit dans la réponse BIND, le serveur SNA chiffre automatiquement le mot de passe de sécurité de conversation LU 6.2 inclus dans le message d’attachement FMH-5. Les applications APPC utilisant Host Integration Server tirent automatiquement parti de cette fonctionnalité en définissant le champ de sécurité du VCB sur AP_PGM ou AP_STRONG dans la requête ALLOCATE .

Si une application APPC souhaite forcer le flux d’un mot de passe chiffré, l’application peut spécifier AP_STRONG pour le champ de sécurité du VCB dans la requête ALLOCATE . Cette option est implémentée comme définie dans IBM i V3R1 et est documentée dans la référence du programmeur IBM i CPI-C comme CM_SECURITY_PROGRAM_STRONG, où le champ LU 6.2 pwd (mot de passe) est chiffré avant qu’il ne circule sur le réseau physique.

Les fonctionnalités de substitution de mot de passe sont actuellement uniquement prises en charge par IBM i V3R1 ou version ultérieure. Si le système distant ne prend pas en charge cette fonctionnalité, le serveur SNA annule la session avec le code logique de 10060006. Les deux nœuds négocient s’ils prennent en charge cette fonctionnalité dans l’échange BIND. Host Integration Server définit un peu dans la liaison, et ajoute également des données aléatoires sur bind pour le chiffrement. Si le nœud distant prend en charge la substitution de mot de passe, il définit le même bit dans la réponse BIND et ajoute des données aléatoires (différentes) pour le déchiffrement.

Host Integration Server prend en charge l’ouverture de session automatique pour les applications APPC. Cette fonctionnalité nécessite une configuration spécifique par l’administrateur réseau : l’application APPC doit être appelée côté RÉSEAU à partir d’un client d’Host Integration Server. Le client doit être connecté à un domaine Windows, mais le client peut s’exécuter sur n’importe quel système d’exploitation pris en charge par les API APPC Host Integration Server.

L’application cliente est codée pour utiliser la sécurité au niveau du programme, avec un nom d’utilisateur APPC codé en dur spécial MS$SAME et mot de passe MS$SAME. Lorsque cette allocation de session passe du client au serveur SNA, le serveur recherche le compte hôte et le mot de passe correspondant au compte Windows sous lequel le client est connecté et remplace les informations du compte hôte dans le message d’attachement APPC qu’il envoie à l’hôte.

Remarque

Il est illégal pour le nœud distant de définir le bit spécifiant la substitution de mot de passe et de ne pas ajouter les données aléatoires.

Selon IBM, il existe des implémentations de la substitution de mot de passe LU 6.2 qui ne prennent pas en charge la substitution de mot de passe, mais qui renvoient le bit de substitution de mot de passe à Host Integration Server, sans spécifier de données aléatoires. Lorsqu’ils effectuent cette opération, le serveur SNA annule la session avec le code de sens 10060006.Ce code de sens est interprété comme suit :

  • 1006 = Champ ou paramètre obligatoire manquant.

  • 0006 = Un sous-champ requis d’un vecteur de contrôle a été omis.

    Host Integration Server doit également consigner un événement 17 (échec d’activation de session APPC : réponse négative BIND envoyée).

    La solution correcte consiste à corriger l’implémentation défaillante. Toutefois, comme solution de contournement à court terme, le paramètre de Registre du service Host Integration Server suivant peut être défini :

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\snaservr\parameters\NOPWDSUB: REG_SZ : OUI

    Lorsque ce paramètre est spécifié dans le Registre, la prise en charge de la substitution de mot de passe est désactivée.

    Plusieurs mises à jour ont été apportées à Host Integration Server pour permettre à une application APPC privilégiée d’ouvrir une conversation APPC à l’aide de la fonctionnalité single Sign-On pour le compte de n’importe quel utilisateur Windows défini. Il s’agit de la fonctionnalité de proxy privilégié. Une extension a été ajoutée au verbe APPC ALLOCATE pour appeler cette fonctionnalité.

    Une application APPC devient privilégiée en étant démarrée dans un compte d’utilisateur Windows membre d’un groupe Windows spécial. Lorsqu’un domaine de sécurité d’hôte est configuré, le Gestionnaire SNA définit un deuxième groupe Windows à utiliser avec les fonctionnalités de sécurité hôte de Host Integration Server. Si le compte d’utilisateur sous lequel le client réel est en cours d’exécution est membre de ce deuxième groupe Windows, le client est privilégié pour lancer une conversation APPC au nom de tout compte d’utilisateur défini dans le cache du compte hôte.

    Les éléments suivants illustrent le fonctionnement de la fonctionnalité de proxy privilégié :

    L’administrateur Host Integration Server crée un domaine de sécurité hôte appelé APP. Le Gestionnaire SNA crée désormais deux groupes Windows. Le premier groupe est appelé APP et le second est appelé APP_PROXY pour cet exemple. Les utilisateurs affectés au groupe APP sont activés pour l’authentification unique. Les utilisateurs affectés au groupe APP_PROXY sont des proxys privilégiés. L’administrateur ajoute l’utilisateur Windows AppcUser au groupe APP_PROXY à l’aide du bouton Utilisateurs de la boîte de dialogue Propriétés du domaine de sécurité hôte dans le Gestionnaire SNA.

    L’administrateur configure ensuite une application APPC sur host Integration Server pour qu’elle s’exécute en tant que service Windows appelé APPCAPP et que ce service a été configuré pour fonctionner sous le compte d’utilisateur AppcUser. Quand APPCAPP s’exécute, il ouvre une session APPC via un verbe ALLOCATE à l’aide du format VCB étendu et spécifie le nom d’utilisateur Windows de l’utilisateur souhaité, UserA (par exemple).

    Le service SNA voit la demande de session provenant d’une connexion membre de l’application de domaine de sécurité hôte. L’interface client/serveur indique au service SNA que le client réel est AppcUser.

    Le service SNA vérifie si AppcUser est membre du groupe APP_PROXY. AppcUser étant membre de APP_PROXY, le service SNA insère le nom d’utilisateur/mot de passe pour UserA dans la commande APPC Attach (FMH-5) et l’envoie au tp partenaire.

    Pour prendre en charge la fonctionnalité de proxy privilégié, l’application APPC doit implémenter la logique de programme suivante :

    L’application APPC doit déterminer l’ID d’utilisateur Windows et le nom de domaine qu’il souhaite emprunter.

    L’application APPC doit définir les paramètres suivants avant d’appeler le verbe ALLOCATE :

    Activez l’utilisation de la structure de bloc de contrôle de verbe ALLOCATE étendue en définissant l’indicateur AP_EXTD_VCB dans le champ opext .

    Définissez la sécurité sur AP_PROXY_SAME, AP_PROXY_PGM ou AP_PROXY_STRONG.

    Configurez les pointeurs pour proxy_user et proxy_domain pour pointer vers des chaînes Unicode contenant le nom d’utilisateur et le nom de domaine de l’utilisateur à emprunter l’identité.

Remarque

L’application n’a pas besoin de configurer les champs user_id et pwd dans la base de données ALLOCATE VCB.

Lorsque l’application APPC effectue les étapes ci-dessus et émet le verbe ALLOCATE , le serveur Host Integration Server effectue une recherche dans le domaine de sécurité hôte pour l’utilisateur Windows spécifié et définit les champs d’ID d’utilisateur et de mot de passe dans le message d’attachement FMH-5 envoyé au système distant.

  • Last updated on