Dates nulles

contient des champs de dates potentiellement nulles, comment
manipuler ces champs dans un programme RPG IV ? Il faut tout d’abord compiler
le programme ou le module en utilisant l’option ALWNULL(*USRCTL). Depuis la V4R2,
on peut définir ALWNULL en carte H. Dans les versions précédentes, il fallait
définir l’option comme paramètre de la commande CRTBNDRPG (Create Bound RPG Program)
ou CRTRPGMOD (Create RPG Module). Il est judicieux d’ajouter un commentaire au
début des programmes RPG antérieurs à  la V4R2, pour signaler aux autres programmeurs
la nécessité de compiler avec cette option.

Ensuite, pour indiquer si un champ date est null, utilisez la fonction intégrée
RPG IV %NullInd, appelée parfois indicateur null. En dépit de son nom, %NullInd
n’est pas vraiment un indicateur mais une fonction, donc on ne peut pas l’utiliser
pour conditionner directement la sortie. Pour indiquer une valeur nulle, utilisez
soit une opération Eval :

Eval %NullInd(ENDDAT) = *On

soit une opération Move :

Move *On %NullInd(ENDDAT)

Pour déterminer si un champ contient une valeur nulle, vérifiez simplement si
l’indicateur null est actif (on) :

If %NullInd(ENDDAT) = *On

Pour écrire un champ de date nulle dans un fichier en RPG, il n’est pas nécessaire
de transférer des zéros ou d’autres valeurs dans le champ. Activez simplement
l’indicateur null du champ, puis écrivez le format d’enregistrement contenant
le champ :

Eval %NullInd(ENDDAT) = *On

Write Record

RPG et les fichiers écran

Comme la plupart des données proviennent d’une saisie utilisateur, voyons comment
écrire un programme RPG pour qu’il accepte des dates nulles en provenance d’un
fichier écran. Les fichiers écran acceptent des champs de type de données date
depuis la V4R2. Pour les versions antérieures, les programmeurs doivent définir
les champs dates avec l’ancienne méthode, en tant que décimal zoné, et utiliser
la convention de date selon laquelle la saisie de zéros (ou aucune saisie) signifie
que la date doit être nulle.

Pour l’exemple suivant, supposons que XXEDAT est une date de fichier écran définie
comme un champ de six caractères, sans décimales, comme illustré sur la figure
4 et que ENDDAT est un champ de date potentiellement nulle dans un fichier. Notre
utilisateur tape une date et appuie sur Entrée. La figure 5 présente le code RPG
IV chargé de traiter l’entrée. Notons à  nouveau que si la date doit être nulle,
il n’est pas nécessaire de transférer des données dans le champ de date du fichier.
Il suffit d’utiliser la fonction intégrée %NullInd sur le champ, avant d’écrire
l’enregistrement (comme en A).

Si vous n’êtes pas habitué au RPG IV, deux autres lignes de la figure 5 méritent
une attention spéciale. Premièrement, en B, le code opération Test avec une extension
D vérifie si le champ spécifié en Facteur 2 (XXEDAT) est une date valide dans
le format indiqué dans Facteur 1 (*MDY, ou mmddyy) et, si ce n’est pas
le cas, active l’indicateur dans la colonne Lo. Cette ligne unique remplace tout
le code de validation de date nécessaire auparavant pour vérifier le 31 juin,
une année bissextile, et autres particularités ou anomalies de dates.

Ensuite, en C, le code opération Move transfère la date numérique indiquée dans
Facteur 2 (XXEDAT) dans le champ de type date défini dans le résultat (ENDDAT),
d’après le format indiqué dans Facteur 1 (*MDY). Comme la date entrée ne contient
pas de siècle, le système utilise la fenêtre IBM standard, de 1940 à  2039, pour
en déterminer un. Si on essaye de déplacer une date invalide, le programme émet
le message « RNQ0112 Date, Time or Timestamp value is not valid (C G D F) » ; donc
il faut absolument valider les dates avant de les déplacer.