COBOL : COMPUTE ROUNDED

Une petite notion de COBOL pour par exemple trouver quelques centimes par ci, quelques centimes par là.

Il s’agit de l’utilisation du paramètre ROUNDED dans l’écriture d’un COMPUTE

Les variables

01 W-NOMBRE1 PIC S9(15)V99 COMP-3.
01 W-NOMBRE2 PIC S9(15)V99 COMP-3.
01 W-MULTIPLICATEUR PIC S9(3)V9(6) COMP-3.
01 W-RESULTAT1 PIC S9(15)V99 COMP-3.
01 W-RESULTAT2 PIC S9(15)V99 COMP-3.
01 W-EDIT9 PIC +ZZZ.ZZZ.ZZZ.ZZZ.ZZ9,99.

Le code d’exemple

DISPLAY '----------ROUNDED DEBUT -------------'
MOVE 123,12 TO W-NOMBRE1
MOVE 567,56 TO W-NOMBRE2
MOVE 456,456789 TO W-MULTIPLICATEUR
MOVE 0 TO W-RESULTAT1
MOVE 0 TO W-RESULTAT2

COMPUTE W-RESULTAT1 ROUNDED = W-NOMBRE1
* W-NOMBRE2
* W-MULTIPLICATEUR

COMPUTE W-RESULTAT2 = W-NOMBRE1
* W-NOMBRE2
* W-MULTIPLICATEUR

MOVE W-RESULTAT1 TO W-EDIT9
DISPLAY 'ROUNDED    : ' W-EDIT9

MOVE W-RESULTAT2 TO W-EDIT9
DISPLAY 'NOT ROUNDED: ' W-EDIT9

MOVE 0 TO W-RESULTAT1
MOVE 0 TO W-RESULTAT2

COMPUTE W-RESULTAT1 ROUNDED = W-NOMBRE1
* W-NOMBRE2
- W-MULTIPLICATEUR

COMPUTE W-RESULTAT2 = W-NOMBRE1
* W-NOMBRE2
- W-MULTIPLICATEUR

MOVE W-RESULTAT1 TO W-EDIT9
DISPLAY 'ROUNDED    : ' W-EDIT9

MOVE W-RESULTAT2 TO W-EDIT9
DISPLAY 'NOT ROUNDED: ' W-EDIT9

DISPLAY '----------ROUNDED FIN -------------'

La sysout

----------ROUNDED DEBUT -------------
ROUNDED    : + 31.896.281,66
NOT ROUNDED: + 31.896.281,65
ROUNDED    : + 69.421,53
NOT ROUNDED: + 69.421,53
----------ROUNDED FIN -------------

Résultats réels

Pour le premier calcul : 31.896.281,6590951

Pour le second : 69421,530411

Conclusion

Comme l’explique la documentation Cobol, ROUNDED arrondi la dernière décimale en l’augmentant de 1 si la décimale suivante en trop dépasse ou est égale à 5. Vrai dans le premier calcul faut dans le second.

Notez que le comportement normal est la troncature des décimaux en trop par rapport à la variable de réception du COMPUTE.

Note de service : HTTPS par Let’s Encrypt

Courant mars, j’annonçais le passage à Let’s Encrypt pour la gestion des certificats. Je donnais rendez-vous aux lecteurs aujourd’hui 26 mai pour la vérification du renouvellement automatique du certificat.

Il se trouve que le certificat a été renouvelé bien avant puisque la période de validité actuelle s’étend du 27 avril 2017 au 26 juillet 2017. J’en déduis donc que la « mise à jour » du certificat peut intervenir dans les 30 jours précédents son expiration.

Installation d’un package npm depuis un dépôt GitLab

Pour utiliser un dépôt hébergé sur sa propre instance GitLab, rien de bien compliquer, si ce n’est le protocole à utiliser : git+https et pas juste https (ou git+http au lieu de http).

Ce qui nous donne pour la branche master d’un projet :

{
  ...
  "dependencies": {
    "mon-projet": "git+https://<mon-domaine-gitlab>/<user>/<mon-projet>#master",
    ...
  }
}

Illustration pour récupérer une configuration eslint sous forme de module dans son dépôt propre :

{
  ...
  "devDependencies": {
    "eslint-config-unicoda": "git+https://gitlab.unicoda.com/vvision/javascript-convention#master",
    ...
  }
}

Let’s Encrypt. Enfin!

Cela fait pratiquement une éternité dans le monde de l’informatique que l’initiative Let’s Encrypt a été lancé. Je dois dire que si l’idée me plaisait beaucoup, au moment où les premières annonces avaient été faites, j’ai longtemps répugné à m’y mettre. Jusqu’à présent, j’utilisais StartSSL pour établir mes différents certificats. Avec quelques limitations bien sûr, un certificat par sous-domaine, génération d’une demande de certificat sur le serveur, transfert des infos vers StartSSL, récupération du certificat, transfert des fichiers sur le serveur et redémarrage d’Apache. De nombreuses opérations manuelles donc, mais une fois la procédure en place, c’est relativement rapide et les certificats ainsi générés sont valables un an. Pas de nécessité donc de mettre en place des certificats Let’s Encrypt, même si j’ai suivi les expérimentations des uns et des autres avec intérêt, et gardé en marque-page certains articles sur le sujet.

Tout allait bien dans le meilleur des mondes, jusqu’à la sortie de Firefox 51. En effet, à partir de cette version, Firefox (et Chrome aussi) arrête de faire confiance aux certificats signés par StartSSL après la date du 21 octobre 2016. Il se trouve, que deux de mes sous-domaines étaient concernés. Je me suis donc (re)plongé dans la documentation de certbot, pour découvrir l’outil et effectuer mes premiers tests.

L’ensemble a plutôt bien évolué par rapport à ce dont je me souvenais. Après plusieurs relectures et quelques tests, j’ai abouti à une procédure qui me convient. J’effectue donc la première demande de certificat manuellement, en conservant pour le moment l’isolation des sous-domaines qui m’avait été imposées par StartSSL. Je conserve ainsi une certaine liberté si je décide de migrer un service d’un serveur vers un autre. Je suis également arrivé à la configuration commune suivante, que je déploie à l’emplacement attendu par certbot, à savoir /etc/letsencrypt/cli.ini :

# Certbot Config

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# Register with the specified e-mail address
email = <e-mail>

# Use the standalone authenticator on port 80
authenticator = standalone
preferred-challenges = http-01

De cette manière, la demande d’un nouveau certificat pour un domaine reste concise, il n’est plus nécessaire de renseigner tous les paramètres du fichier de configuration et on obtient donc par exemple :

certbot-auto certonly -d www.unicoda.com

Une fois le certificat généré, les lignes suivantes sont nécessaires du côté d’Apache :

SSLCertificateFile /etc/letsencrypt/live/<domaine>/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<domaine>/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/<domaine>/chain.pem

Redémarrage d’Apache que l’on avait arrêté le temps d’effectuer la procédure de demande de certificat et ça y est le navigateur affiche un fabuleux « Vérifié par : Let’s Encrypt ».

Du côté du renouvellement, je vais passer par la crontab pour qu’une vérification quotidienne des certificats soit effectuées. Le programme certbot s’occupant d’arrêter puis de redémarrer Apache :

certbot-auto renew --quiet --pre-hook "service apache2 stop" --post-hook "service apache2 start"

En théorie, le renouvellement automatique est donc en place, et le moment venu, les anciens certificats devraient être remplacés par des nouveaux sans que cela ne bouleverse (trop) le fonctionnement du site. Comme nous ne sommes jamais à l’abri d’une erreur de configuration malgré les nombreuses vérifications effectuées, et que je ne pourrais en être sûr qu’une fois les nouveaux certificats en place, je vous donne rendez-vous aux alentours du 26 mai 2017, date d’expiration du premier certificat Let’s Encrypt pour www.unicoda.com. Normalement, l’opération devrait être transparente pour tous, et je me réveillerais donc un matin (beau de préférence) avec un certificat tout neuf, sans avoir rien eu à faire.

Il ne reste plus qu’à patienter.