Sous-programme

• Traitement (champ PRG)

Code du traitement. Il doit être capitalisé dans le dictionnaire des traitements. 

• Sous-programmes (champ SUBPRG)

sous_programme ou fonction considéré ré-utilisable et par conséquent, à capitaliser dans ce dictionnaire.

• Intitulé (champ ZINTIT)

Intitulé descriptif du sous-programme ou de la fonction.

Doit être le plus clair et précis pour faciliter ensuite, les recherches.

• Code activité (champ CODACT)

Un code activité permet :

• de rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle.
• de signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z.
• de dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau.

Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable.

• Module (champ MODULE)

Que le module soit actif ou inactif, il n'y a aucune incidence sur l'exécution du sous-programme.

• Type (champ TYPASU)

Permet de classer les sous-programmes et fonctions afin d'en faciliter la recherche, et ce, dans le but d' une meilleure ré-utilisabilité.

Les fonctions et sous-programmes sont à classer en fonction de leur objectif :

• Contrôle
• Saisie
• Sélection
• Mise à jour
• Xsl (traitement lié au composant écran)
• Retour d'un statut
• Recherche d'information
• Calcul
• Divers

• champ WA

• Web services (champ WEBS)

Permet de préciser que ce sous-programme ou fonction est générable pour les web services. En fait, aucun traitement n'est livré directement exploitable pour les webs services. Par contre, une fonction de génération des web services est mise à disposition pour les objets et sous-programmes identifiés comme pouvant être générés.

• champ PUBNAM

• Fonction (champ FONCTION)

Case à cocher permettant de faire la distinction des fonctions (appelées par l'instruction Func ) des sous-programmes (appelés par l'instruction Call.)

• Type argument (champ TYPFCT)

Ce champ est à renseigner pour les fonctions. Celles-ci sont à classer en fonction de la nature de leur argument de retour :

• Char
• Intéger
• Decimal
• Date
• etc.

• champ TEXTE

Texte alimentant le paragraphe PRE "présentation", de l'aide sur fiche. Dans la gestion de la documentation, on identifie la fiche aide par :

• type documentation = ASU
• code documentation = traitement_sous-programme

• No (champ NUMLIG2)

• Code (champ PARAM)

Chaque paramètre est identifié par un code de 10 caractères majuscules et chiffres. Il n'y a pas de dictionnaire pour ces paramètres. 

• Intitulé (champ ZINTITPAR)

Intitulé du paramètre du sous-programme ou de la fonction. Doit être le plus clair et précis pour faciliter la compréhension.

• Type (champ TYPPAR)

Nature du paramètre :

• Char : Chaîne de caractères
• Integer : Nombre entier
• Decimal : Nombre décimal
• Date : date
• Libellé : Menu local
• Clob : texte
• Blob : image

• Code structure (champ CODSTR)

• Dim (champ DIME)

Dimension du paramètre

• Type d'argument (champ ADRVAL)

Il indique comment est passé le paramètre.

          par adresse ( une variable est nécessaire pour passer le paramètre. En sortie du sous-programme, la valeur du paramètre éventuellement modifiée est retournée au traitement appelant ).

          par valeur ( le paramètre est passé par une variable ou par constante. En sortie du sous-programme, la valeur du paramètre même si elle est modifiée n'est pas retournée au traitement appelant).

• Toutes langues existantes (champ ALLLAN)

Si cette case est cochée, toutes les langues sont prises en compte pour l'opération.

Si la case n'est pas cochée, on prendra, selon les cas :

• la langue par défaut de l'utilisateur, si aucun code langue n'est saisi.
• la langue saisie par ailleurs sinon.

• Langue (champ LAN)

Permet de définir la langue de génération (quand la case permettant de générer dans toutes les langues n'est pas cochée).

• Tous types (champ ALLTYP)

Si cette case est cochée, tous les types de documentation sont pris en compte pour la génération. Il est à noter que, dans ce cas, on limite la génération aux documentations standard (seules les documentations de code inférieur à X sont prises en compte).

• Type (champ TYPEDOC)

Permet de définir le type de documentation à prendre en compte dans le traitement (quand on n'a pas coché la case pour les prendre tous en compte).

• Codes documentations (champ FUNDEB)

Permet de donner une borne sur les codes à prendre en compte pour la génération de documentation.

• champ FUNFIN

• Génération ADOCUMENT (champ GENDOC)

Ce radio-bouton permet créer/mettre à jour le squelette de la documentation (hiérarchie des paragraphes) à partir des éléments techniques trouvés dans le dictionnaire des données. On peut choisir de reprendre uniquement les documentations existantes ou créer de nouvelles documentations si besoin.

Les liens de documentation sont également pris en compte. Les paragraphes susceptibles d'être créés sont définis dans l'annexe technique correspondante.

• champ GENFIN

Ce radio-bouton permet de générer la documentation finale à partir du contenu des paragraphes de documentation. Cette documentation est créée dans différents sous-répertoires du répertoire défini par le paramètre utilisateur DIRDOC.

Il faut utiliser la génération "Selon code activité" pour obtenir la génération des documentations des fonctions ayant des codes activités >= "X"
La génération "Complète" ne traite que les codes activités standards.

• Uniquement les documentations validées (champ HLPVLD)

Permet de générer le document final uniquement pour les documentations validées.

• Aides sur champs liées aux documentations (champ HLPLNKFLD)

Si cette case est cochée, on traite spécifiquement les aides sur champs relatives aux documentations sur fonction ou objet traitées par ailleurs. Pour savoir quelles sont les aides sur champ à traiter, on explore les écrans associés aux paragraphes de documentation correspondants.

• Autres aides sur champs (champ HLPFLD)

Si cette case est cochée, on crée la documentation finale à partir du contenu des paragraphes de documentation. Cette documentation est créée dans le sous-répertoire FLD du répertoire défini par le paramètre utilisateur DIRDOC.

• Codes aides sur champs (champ HLPDEB)

Permet de donner une borne sur les codes à prendre en compte pour la génération de documentation.

• champ HLPFIN

• Répertoire de génération (champ REPERT)