Cours NetRexx

Initiation L'informatique en réseau avec Java et NetRexx en PDF


Télécharger Initiation L'informatique en réseau avec Java et NetRexx en PDF

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


Initiation L'informatique en réseau avec Java et NetRexx [Eng]

...

Chapitre 1 Introduction

Ce livre rouge présente les nouveaux environnements de programmation NetRexx et Java pour VM / ESA version 2, version 3. Le livre se concentre sur ces domaines:

Déploiement de NetRexx et Java sur VM / ESA

Approche de NetRexx à partir d'un contexte REXX

Développement d'applications VM / ESA en Java et NetRexx

Tout d'abord, nous fournissons une vue d'ensemble de NetRexx, Java et de leurs composants clés. Les implémentations NetRexx et Java sous VM / ESA V2.3 seront également couvertes, ainsi que des détails sur les considérations spécifiques à la machine virtuelle. Nous décrivons également comment installer et configurer NetRexx et Java sur VM / ESA. Cette section contient des informations sur la configuration et la configuration des composants SFS et BFS de VM / ESA, nécessaires à NetRexx et Java. Nous discutons en outre d'un certain nombre d'outils et de techniques utiles développés pendant la résidence pour la gestion de l'environnement de développement et d'exécution de programme de Java et de NetRexx sous le CMS.

Une fois cette base établie, nous fournissons ensuite un guide pour les programmeurs REXX classiques au langage NetRexx et quelques-uns des principes et techniques les plus utiles de la programmation orientée objet. Après cela, nous explorons diverses techniques de programmation NetRexx importantes pour l'environnement CMS, et fournissons de nombreux exemples illustratifs.

Enfin, nous présentons une application VM / ESA complète construite en utilisant NetRexx et Java. L'interface utilisateur graphique côté client et l'application CMS côté serveur sont entièrement codées dans NetRexx et Java L'application présente à l'utilisateur un tableau des données de performance d'un système VM / ESA et permet à l'utilisateur de ¬Å "pointez et cliquez" pour sélectionner différents ensembles de données à afficher. La communication entre le serveur et le client est accomplie en utilisant les interfaces Java natives pour les sockets TCP / IP. Cet exemple d'application, appelé GUIMON, est représenté dans le diagramme suivant:

 Figure 1. GUIMON - L'exemple d'application NetRexx VM / ESA

 Tout au long de la résidence, nous avons utilisé les stations réseau IBM comme postes de travail pour les utilisateurs finaux, à la fois comme terminaux 3270 émulés pour la connexion à VM / ESA et comme plate-forme client pour l'interface utilisateur graphique GUIMON. Ce livre rouge comprend également une discussion détaillée sur la façon de configurer à la fois IBM Network Station et le système de serveur VM / ESA afin d'utiliser efficacement IBM Network Station en tant que plate-forme de développement et d'exécution de programmes NetRexx.

Chapitre 2. Présentation de NetRexx et Java sur VM / ESA

2.1 Java, NetRexx, OpenEdition et le BFS

Java a ses racines dans les systèmes qui prennent en charge un répertoire hiérarchique arborescente arborant le style Unix. Par conséquent, il n'est pas surprenant de constater que Java (et par extension, NetRexx) nécessite l'accès à un système de fichiers hiérarchique pour fonctionner correctement. Un tel magasin de fichiers est fourni par le système de fichiers Byte (BFS), partie intégrante d'OpenEdition VM / ESA. Les fichiers et les répertoires BFS sont stockés dans des pools de fichiers CMS gérés par le système de fichiers partagé (SFS). Ce chapitre explique ce que vous devez savoir sur le BFS afin de pouvoir déployer et utiliser efficacement Java et NetRexx sur VM / ESA.

2.2 Aperçu du SFS

Le système de fichiers partagés (SFS) est le composant de VM / ESA qui fournit un système de fichiers hiérarchisé et géré aux utilisateurs CMS, par opposition au système de fichiers minidisque CMS traditionnel. Certains des avantages de l'utilisation du SFS au lieu du système de fichiers minidisque CMS traditionnel sont:

  • Partage de fichiers READ / WRITE multiples et sûrs;

Meilleure organisation des données dans une arborescence hiérarchique;

Meilleure utilisation de l'espace DASD existant, grâce à l'élimination de l'espace perdu sur les volumes de minidisques;

  • Accès au fichier inter-système, similaire à celui fourni par NFS;
  • Et, bien sûr, la capacité à soutenir le BFS.

Les informations sur les rubriques SFS suivantes sont importantes pour l'installation et le déploiement efficaces d'IBM Network Station, Java et NetRexx. Ces informations peuvent être consultées dans Planification, administration et fonctionnement du pool de fichiers CMS / ESA CMS, SC24-5751; un aperçu est donné ici pour votre commodité.

2.2.1 Serveurs SFS et pools de fichiers

2.2.1.1 Serveurs

Un serveur SFS est une machine virtuelle de service ordinaire, généralement autologuée par le système au moment de l'IPL, qui exécute le moteur de base de données SFS pour gérer les fichiers CMS à l'aide d'un ensemble de contrôles, de journaux et disques de données utilisateur comme illustré à la Figure 2 à la page 4.

Un pool de fichiers est une collection de minidisques gérés par la machine virtuelle du serveur SFS. Le pool de fichiers contient:

Groupes de stockage 2, 3, n: minidisques dans le pool de fichiers contenant les fichiers de données usersâ € ™.

Groupe de stockage de catalogue: le groupe de stockage dans le pool de fichiers qui contient le catalogue et d'autres informations sur les autorisations des utilisateurs et les répertoires des utilisateurs, similaire aux entrées FST (File Status Table) pour un minidisque CMS normal.

Log Minidisks: ensemble de minidisques indépendants contenant des informations de journal; maintenu dans une «méthode de double écriture à sécurité intégrée» permettant aux modifications apportées aux fichiers utilisateur d'être validées ou annulées.

Données de contrôle: mini-carte (s) contenant des informations sur les allocations d'espace DASD et la disponibilité des blocs de données dans le pool de fichiers.

Il est essentiel que les paramètres du pool de fichiers et le nombre et les tailles de minidisques soient correctement définis lors de la construction du pool de fichiers SFS. Vous trouverez des instructions détaillées de planification d'installation et des valeurs de paramètres de configuration suggérées au Chapitre 20, «Paramètres de démarrage du serveur de pool de fichiers», de la planification, de l'administration et du fonctionnement du pool de fichiers CMS / ESA CMS. , SC24-5751, manuel référencé ci-dessus.

Un serveur SFS peut également mettre des pools de fichiers à la disposition des systèmes VM / ESA distants via les services de l'infrastructure inter-système pour les communications (ISFC), le service TSAF (Transparent Service Access Facility) et AVS (APT / VM VTAM Support). Pour plus d'informations sur les fonctionnalités de connectivité VM, reportez-vous à la section Planification, administration et fonctionnement de la connectivité VM / ESA, SC24-5756.

2.2.1.2 Noms de pool de fichiers standard

VM / ESA Version 2 Edition 3 est livré avec un certain nombre de pools de fichiers SFS prêts à être installés par le processus d'installation. Trois de ces pools de fichiers prédéfinis sont:

Pool de fichiers VMSYS SFS pour les ressources système; par exemple, les produits du programme

Pool de fichiers VMSYSU SFS pour les fichiers de données utilisateur généraux et les répertoires

Pool de fichiers du serveur de récupération VMSYSR CRR pour une récupération coordonnée des ressources sur plusieurs pools de fichiers et des performances SFS améliorées

Étant donné que ces pools de fichiers ont tous des noms qui commencent par VMSYS ... ils ne sont pas éligibles pour l'accès aux systèmes VM distants. Voici l'entrée USER DIRECT du serveur de pool de fichiers VMSYSU, VMSERVU, que nous utilisons ici au Centre ITSO de Böblingen pour cette résidence.

UTILISATEUR VMSERVU VMSERVU 32M 32M BG

COMPTE 1 VMSERVU

MACH XC

OPTION MAXCONN 2000 NOMDCFS APPLICATION ACCT QUICKDSP SVMSTAT

PARTAGE REL 1500

XCONFIG ADDRSPACE MAXNUMBER 100 TOTSIZE 8192G PARTAGER

XCONFIG ACCESSLIST ALSIZE 1022

IUCV AUTORISER

IUCV * IDENT RESANY GLOBAL

CMS IPL

POSIXOPT SETIDS AUTORISENT

CONSOLE 009 3215 T MAINT

LECTEUR 00C 2540 LECTEUR *

BOBINE 00D 2540 PUNCH A

BOBINE 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 0645 003 230W01 MR RSERVER WSERVER

MDISK 301 3380 0995 010 230W01 WR RCONTROL WCONTROL

MINIOPT NOMDC

MDISK 302 3380 1005 016 230W01 WR RLOG1 WLOG1

MINIOPT NOMDC

MDISK 303 3380 1021 016 230W01 WR RLOG2 WLOG2

MINIOPT NOMDC



MDISK 304 3380 1037 003 230W01 WR RCATALOG WCATALOG

MDISK 305 3380 1040 007 230W01 WR RDATA WDATA

MDISK 306 3380 0182 138 230W01 WR RDATA WDATA

MDISK 307 3380 0053 008 230W01 WR RCATALOG WCATALOG

MDISK 308 3380 0622 0300 230W02 WR RDATA WDATA

MDISK 309 3380 0923 0020 230W02 WR RCATALOG WCATALOG

Figure 3. Répertoire du pool de fichiers VMSYSU pour le serveur de pool de fichiers VMSYSR, VMSERVR,

UTILISATEUR VMSERVR VMSERVR 32M 32M BG

COMPTE 1 VMSERVR

MACH XA

OPTION MAXCONN 2000 APPLMON ACCT QUICKDSP SVMSTAT

PARTAGE REL 1500

IUCV AUTORISER

IUCV * IDENT RESANY GLOBAL

CMS IPL

CONSOLE 009 3215 T MAINT

LECTEUR 00C 2540 LECTEUR *

BOBINE 00D 2540 PUNCH A

BOBINE 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 0648 002 230W01 MR RSERVER WSERVER

MDISK 301 3380 1047 002 230W01 WR RCONTROL WCONTROL

MINIOPT NOMDC

MDISK 302 3380 1049 001 230W01 WR RLOG1 WLOG1

MINIOPT NOMDC

MDISK 303 3380 1050 001 230W01 WR RLOG2 WLOG2

MINIOPT NOMDC

MDISK 304 3380 1051 002 230W01 WR RCATALOG WCATALOG MINIOPT NOMDC

MDISK 305 3380 1053 001 230W01 WR RDATA WDATA

MINIOPT NOMDC

MDISK 306 3380 1054 002 230W01 WR RCRRLOG1 WCRRLOG1 MINIOPT NOMDC

MDISK 307 3380 1056 002 230W01 WR RCRRLOG2 WCRRLOG2 MINIOPT NOMDC

Figure 4. Répertoire du serveur de pool de fichiers VMSYSR et, enfin, pour le serveur de pool de fichiers VMSYS, VMSERVS:

La quantité d'espace DASD allouée à ces minidisques d'utilisateurs VM est plus que suffisante pour prendre en charge tous les développements Java, NetRexx et IBM Network Station et tester ces documents Redbook. Theyâ €? Sont de bonnes valeurs de départ pour votre site, aussi.

Dans chacune de ces entrées de répertoire USER DIRECT, le minidisque 191 contient le fichier POOLDEF, le minidisque 301 le minidisque du contrôle de pool de fichiers, les minidisques 302 et 303 contiennent les fichiers journaux et minidisk 304 le minidisque du catalogue de pools de fichiers (groupe de stockage 1). . Dans VMSERVU, étant donné que le nombre de fichiers de données utilisateur et de répertoire peut être assez important dans un pool de fichiers, les minidisques 307 et 309 sont également affectés au groupe de stockage du catalogue de pool de fichiers. Tous les autres minidisques définis dans les entrées du répertoire sont alloués pour contenir les fichiers de données utilisateur et les répertoires dans les groupes de stockage 2 à N.

2.2.1.3 Problèmes de sauvegarde et de restauration de SFS

En raison de la quantité et de la valeur des données stockées dans un pool de fichiers SFS / BFS typique d'un site, une attention particulière doit être accordée aux problèmes de sauvegarde et de restauration du pool de fichiers. Nous recommandons que les données utilisateur et les données de contrôle du SFS soient sauvegardées à intervalles réguliers. Vous pouvez utiliser les fonctions de sauvegarde / restauration natives fournies par SFS ou vous pouvez utiliser d'autres techniques de sauvegarde non compatibles avec le pool de fichiers, telles que le programme standard VM / ESA DDR (DASD Dump Restore).

Évidemment, vous pouvez acheter un produit pour gérer les sauvegardes SFS; De telles solutions offrent souvent des fonctions de sauvegarde incrémentielles. Ici, nous ne mentionnons que les méthodes de sauvegarde SFS nativement disponibles dans n'importe quel système VM / ESA.

Si vous choisissez de sauvegarder uniquement le composant de données utilisateur (groupes de stockage 2, 3, ... N) et non le composant de données de contrôle (catalogue, disques de contrôle de pool de fichiers et disque POOLDEF), vous perdez le contrôle disque ou les disques du groupe de stockage 1 (catalogue), vous serez obligé de régénérer votre pool de fichiers et de restaurer chaque groupe de stockage utilisateur. Pour les grandes collections SFS, cela peut être un processus très long. D'un autre côté, si vous sauvegardez uniquement le composant de contrôle et non le composant de données utilisateur, vous perdrez la totalité du pool de fichiers si un disque du SFS est corrompu. Il n'y a aucun moyen de se remettre de cette situation.

L'approche recommandée pour la sauvegarde et la restauration d'un pool de fichiers SFS consiste à utiliser les fonctions SFS BACKUP et RESTORE natives. SFS fournit les commandes d'administration FILEPOOL BACKUP et FILEPOOL RESTORE pour sauvegarder et restaurer les pools de fichiers SFS. Utilisez la commande FILEPOOL BACKUP pour effectuer des sauvegardes des zones de données utilisateur (groupes de stockage 2 à N) et utilisez la commande FILEPOOL CONTROL BACKUP pour effectuer des sauvegardes des disques de contrôle, du groupe de stockage de catalogue 1 et du disque POOLDEF. Une caractéristique importante de l'utilisation de ces commandes est que le pool de fichiers peut toujours être mis à la disposition des utilisateurs finaux (bien qu'en mode lecture seule) pendant la sauvegarde. Une autre fonctionnalité est que les utilisateurs individuels ou les fichiers peuvent être restaurés (à l'aide de la commande FILEPOOL RELOAD). Ces commandes et leurs opérandes sont documentées dans le manuel Planification, administration et opération du pool de fichiers CMS, SC24-5751.

Si vous choisissez d'utiliser une méthode de sauvegarde non compatible avec le pool de fichiers, telle que DDR, vous devez connaître les problèmes suivants:

  • Le pool de fichiers SFS doit être complètement arrêté pendant la sauvegarde; l'utilisateur final ne peut même pas avoir un accès en lecture seule aux données

 · vous devez sauvegarder tous les minidisques du pool de fichiers sur lesquels le pool de fichiers réside en même temps. Vous ne pouvez pas sauvegarder la moitié des minidisques aujourd'hui, démarrez le serveur de pool de fichiers pour les opérations normales, puis sauvegardez les minidisques restants demain.

Un pool de fichiers est une seule entité logique. Les données sur les minidisques du pool de fichiers sont logiquement entrelacées de manière complexe. Sans utiliser les commandes de sauvegarde et de restauration du pool de fichiers SFS natif (ou un produit similaire) qui connaissent les interrelations logiques des données, le pool de fichiers doit être sauvegardé ou restauré en tant qu'unité. Il n'est pas possible de restaurer uniquement une partie du pool de fichiers.

2.3 Aperçu du BFS

Le manuel d'implémentation et d'administration du manuel OpenEdition for VM / ESA, SG24-4747, contient une description exceptionnelle de tout l'environnement OpenEdition. Pour votre commodité, un aperçu plus court est inclus ici.

OpenEdition for VM / ESA fournit un système de fichiers compatible POSIX appelé BFS (Byte File System). Contrairement aux systèmes de fichiers CMS orientés enregistrements classiques, basés sur minidisk et SFS, le BFS considère les fichiers comme une simple collection d'octets. Il n'impose aucune autre structure sur les données stockées dans les fichiers. Le concept POSIX d'un système de fichiers a été dérivé conceptuellement des systèmes de fichiers développés pour les systèmes Unix. Le système BFS a des sémantiques, des conventions de dénomination de fichier et des structures de fichiers différentes de celles des systèmes de fichiers CMS conventionnels.

Le BFS permet de créer et d'utiliser des fichiers dans un format de type Unix. Comme les fichiers du SFS, les fichiers BFS sont stockés dans des pools de fichiers CMS. Un espace fichier BFS peut se trouver dans le même pool de fichiers que les espaces fichier SFS et plusieurs espaces fichier BFS peuvent être inscrits dans le même pool de fichiers.

Les interfaces définies par POSIX pour le langage de programmation «C» sont fournies sous la forme de routines de bibliothèque appelables dans la bibliothèque d'environnement Language Environment fournie par VM / ESA, SCEERUN LOADLIB. Pour les autres environnements et langages de programmation (par exemple, REXX, PL / I, Assembler), l'accès aux fonctions POSIX est assuré par un ensemble de routines Callable Services Library (CSL). OpenEdition for VM / ESA fournit également un ensemble d'étapes de pipeline CMS et un ensemble de sous-commandes OPENVM pour prendre en charge le BFS. Certaines commandes natives du CMS (par exemple, XEDIT) peuvent également prendre en charge l'accès aux fichiers et répertoires BFS à l'aide d'extensions de l'interface du système de fichiers d'enregistrement du CMS.

2.3.1 Terminologie POSIX

Voici les définitions de certains des termes POSIX les plus courants qui apparaissent lors de l'utilisation du BFS.

Nom du chemin Chaîne de caractères identifiant un chemin d'accès à un fichier ou un répertoire. OpenEdition prend en charge les noms de chemin d'une longueur maximale de 1023 caractères.

Nom de chemin relatif Nom de chemin qui identifie le chemin d'accès à un fichier ou un répertoire à partir du répertoire de travail actuel.

Les noms de chemins relatifs ne commencent pas par une barre oblique (/).

Nom de chemin absolu Nom de chemin qui identifie le chemin d'accès à un fichier ou un répertoire à partir de la racine du système de fichiers. Les noms de chemins absolus commencent toujours par une barre oblique (/).



Nom de fichier Chaîne de caractères qui nomme un fichier dans un répertoire. OpenEdition prend en charge les noms de fichiers de 255 caractères maximum.

Répertoire Un fichier spécial contenant des entrées de répertoire.

Les entrées de répertoire doivent être uniques dans un répertoire donné, mais des entrées de répertoire différentes peuvent associer des noms différents au même fichier.

Répertoire en cours (ou de travail) Répertoire associé à un processus (par exemple, le shell) utilisé pour résoudre les noms de chemins relatifs.

Les caractères utilisés dans les noms de fichier et de chemin doivent provenir du jeu de caractères portable POSIX, mais cela n'est pas appliqué par OpenEdition for VM / ESA. Le jeu de caractères portable comprend:

  • Les lettres majuscules A-Z.
  • Les lettres minuscules a-z.
  • Les chiffres 0-9.
  • Les caractères spéciaux point (.), Trait de soulignement (_) et trait d'union (-).

Un nom conforme ne peut pas commencer par un trait d'union. Un nom de fichier POSIX valide peut être: karen.nrx

et son nom de chemin absolu correspondant peut ressembler à ceci: /home/dave/netrexx/examples/karen.nrx

Notez que tout ce qui précède et inclut la dernière barre oblique (/) dans l'exemple ci-dessus fait partie du chemin du répertoire, et tout ce qui suit la dernière barre oblique est le nom du fichier lui-même. Lorsque le répertoire en cours est défini sur / home / dave, le nom de chemin relatif est:

netrexx / examples / karen.nrx

Parce que la barre oblique (/) est le caractère séparateur de chemin, il ne peut pas être utilisé dans un nom de fichier. De plus, comme l'interpréteur shell OpenEdition standard attribue des significations spéciales aux caractères suivants, il n'est pas conseillé de les utiliser dans les noms de fichier ou de répertoire:

(vide) * # / \ <> | & $? () {}

Figure 6. Caractères spéciaux

Rendre les noms de fichiers faciles à retenir. Contrairement à VM / ESA, qui limite les noms de fichiers et les types de fichiers à huit (ou moins) caractères, OpenEdition autorise les noms de fichiers à 255 caractères maximum. Utilisez le point (.) Ou le trait de soulignement (_) pour rendre les noms de fichiers plus lisibles et faciles à retenir; par exemple:

will_jones_birthday_gift_list

Au fil des années, les utilisateurs de systèmes d'exploitation de type Unix ont développé un ensemble de conventions pour classer les répertoires initiaux du répertoire principal ou racine. Le BFS POSIX suit ces conventions telles qu'implémentées par OpenEdition pour VM / ESA, vous devriez donc voir une structure de répertoire de premier niveau ressemblant à ceci:

/ (- le répertoire racine)

bin (contient des commandes exécutables)

dev (support pour les périphériques matériels)

etc (contient des fichiers d'administration, la boîte à outils)

home (contient les répertoires et fichiers utilisateur)

lib (lien symbolique vers les bibliothèques / usr / lib et les bibliothèques partagées)

opt (contient des fichiers d'administration DCE)

tmp (contient les fichiers temporaires du système et les zones de travail)

u (lien symbolique vers / home)

usr (contient les fichiers exécutables du système, les fichiers d'administration, etc.)

var (contient des fichiers journaux, des fichiers de sécurité et de spoule, etc.)

Figure 7. Structure arborescente typique de BFS ROOT

2.3.2 Entrées de répertoire pour l'utilisation de BFS POSIX

Pour qu'un utilisateur VM puisse utiliser le BFS et l'OpenEdition pour VM / ESA Shell et Utilities, certaines instructions de contrôle de répertoire POSIX doivent être ajoutées dans l'entrée du répertoire utilisateur. Ces instructions de contrôle de répertoire sont:

  • POSIXINFO
  • POSIXOPT
  • POSIXGLIST

2.3.2.1 La déclaration POSIXINFO

L'instruction POSIXINFO est probablement la plus importante de ces trois instructions de contrôle. Elle définit les informations de base de données utilisateur POSIX de l'utilisateur, telles que l'ID utilisateur POSIX associé à cet ID utilisateur VM, l'ID groupe POSIX, le répertoire de travail initial, le programme utilisateur initial (shell POSIX) à exécuter et le point de montage du système de fichiers. Par exemple, l'entrée du répertoire SRRES3 de l'ID de machine virtuelle contient l'instruction POSIXINFO suivante:

POSIXINFO UID 0 Personnel GNAME IWDIR / home / dave /

Cela définit l'ID utilisateur POSIX (UID) SRRES3 de l'utilisateur à 0 (zéro), son nom de groupe POSIX (gname) à la portée, et le répertoire BFS de travail initial (iwdir) à / home / dave /. Pour plus d'informations sur les opérandes et la syntaxe de l'instruction POSIXINFO, reportez-vous au manuel SC24-5750, Planification et administration VM / ESA.

2.3.2.2 La déclaration POSIXOPT

L'instruction POSIXOPT spécifie les paramètres d'option liés aux capacités POSIX d'un ID d'utilisateur de machine virtuelle. Les fonctionnalités incluent l'autorisation d'interroger et de définir certaines informations de processus et de base de données POSIX. Par exemple, pour permettre à un ID d'utilisateur de machine virtuelle de définir d'autres valeurs de sécurité POSIX d'utilisateurs et d'interroger d'autres informations de base de données POSIX d'autres utilisateurs, l'instruction POSIXOPT suivante sera placée dans l'utilisateur. Entrée de répertoire ²s:

LES SEJETS DE POSIXOPT PERMETTENT QUERYDB

Pour plus de détails sur les opérandes et la syntaxe de l'instruction POSIXOPT, reportez-vous au manuel SC24-5750, Planification et administration VM / ESA.

2.3.2.3 La déclaration POSIXGLIST

L'instruction POSIXGLIST spécifie les groupes POSIX dont un ID utilisateur est membre. Chaque groupe peut être spécifié soit par l'identifiant du groupe (gid), soit par le nom du groupe (gname). Pour spécifier qu'un ID utilisateur est membre de gid 0 et gnames staff et operations, codez l'instruction POSIXGLIST suivante dans l'entrée du répertoire de l'utilisateur:

POSIXGLIST GID 0 GNAMES opérations du personnel

Pour plus d'informations sur les opérandes et la syntaxe de l'instruction POSIXGLIST, reportez-vous au manuel SC24-5750, Planification et administration VM / ESA.

2.4 Quelques commandes SFS et BFS courantes

Certains lecteurs peuvent être nouveaux dans BFS et même SFS. Par conséquent, les commandes répertoriées dans le tableau 1 peuvent être utiles.

...

Figure 8. Architecture Java

prend en entrée un programme codé en Java (ou, dans notre cas, codé dans NetRexx) et produit une sortie indépendante de la machine et du système d'exploitation appelée Java byte code. Ce code octet, à son tour, est interprété par un programme de machine virtuelle Java pour produire la sortie désirée. Comme il existe maintenant de nombreuses implémentations de la machine virtuelle Java pour de nombreuses machines et systèmes d'exploitation différents, le code octet est devenu indépendant de la machine ou "écrivez une seule fois, exécutez n'importe où".

La machine virtuelle Java qui interprète le code octet Java n'est rien de plus sophistiqué qu'un grand programme "Câ €". La version VM de la machine virtuelle Java est écrite pour se conformer aux normes POSIX. Il suppose que le

le matériel et les logiciels sous-jacents peuvent fournir les services (par exemple, E / S de fichiers, allocation de mémoire et gestion de processus) définis par la norme POSIX. Dans VM / ESA, le support POSIX est fourni par la fonction OpenEdition et par le BFS; ainsi, dans VM, les paquets Java et NetRexx sont installés dans le BFS, en utilisant les fonctionnalités d'OpenEdition.

2.6 Structures de répertoires SFS et BFS

Même si les espaces fichiers SFS et BFS sont gérés par un serveur SFS, il existe des différences d'organisation et d'utilisation.

2.6.1 Un espace de fichier SFS

Avec un SFS, quand un utilisateur final est inscrit, il obtient ce qu'on appelle un «espace fichier». La commande suivante inscrit l'utilisateur KRIS dans le SFS nommé VMSYS, et lui permet d'utiliser jusqu'à 10000 blocs de données 4K.

INSCRIVEZ L'UTILISATEUR KRIS VMSYS (BLOCKS 10000

Les utilisateurs finaux organisent leur espace fichier comme ils le souhaitent. A partir des noms de répertoire, il est clair qui possède quoi. La commande DIRLIST peut être utilisée pour voir les répertoires d'un espace fichier. Par exemple DIRLIST VMSYS: KRIS. pourrait produire:

~ ~

KRIS DIRLIST A0 V 319 Trunc = 319 Taille = 5 Ligne = 1 Col = 1 Alt = 0

Cmd Fm Nom du répertoire

Un VMSYS: KRIS.

- VMSYS: KRIS.BFSLIST_AND_CO

Z VMSYS: KRIS.GUIMON

- VMSYS: KRIS.GUIMON.NEW

- VMSYS: KRIS.NRTOOLS

1 = Aide 2 = Actualiser 3 = Quitter 4 = Trier (fm) 5 = Trier (dir) 6 = Auth.

7 = en arrière 8 = en avant 9 = 10 = 11 = liste de diffusion 12 = curseur



49