28 mars 2025

Execution error : error code: 162, Arithmetic overflow or underflow

A l'occasion d'une migration Linux, le projet a recompilé l'application avec une nouvelle version de Microfocus Cobol et de nouvelles options.

A l'occasion de tests batch, le programme de calcul de paie s'interrompt parfois avec l'erreur :

Execution error : file 'JFCALDBI'
error code: 162, pc=0, call=1, seg=0
162     Arithmetic overflow or underflow

Il se trouve qu'un traitement de paie effectue une division par zéro.

En effet les options utilisées avec le nouveau compilateur Visual Cobol sont moins permissives que celles de l'ancien Server Express. 

  • NOCHECK
    • (NO)CHECKDIV qui contrôle  les divisions par zéro
    • (NO)CHECKNUM qui contrôle la numéricité des rubriques
  • BOUND contrôle les débordements de tableau occursés.

L'option NOCHECK désactive les options CHECKNUM et CHECKDIV. 
Avec NOCHECKDIV une division par zéro provoque une erreur bloquante du programme.

Si cela se produit en développement ou recette, il est possible d'activer des traces, repérer le traitement fautif et lui ajouter un contrôle pour ne pas provoquer l'erreur. Problème : si l'arrêt brutal du programme se produit en production, il met en danger l'exploitation des traitements batch.  

Pour débloquer la situation et laisser passer les divisions par zéro et les débordements de tableaux, retirer -C NOCHECK et -C BOUND puis placer les options suivantes dans le fichier adm/cfg/config :

COBFLAGS=-C ASSIGN=EXTERNAL -C SEQUENTIAL=LINE -C NOANIM -C NOCSI -C CHECKDIV -C NOCHECKNUM -C NOSERIAL -C IBMCOMP -C SIGN=EBCDIC -C WRITELOCK -C NOTRUNC -C NOBOUND -C PERFORM-TYPE=MF -C COPYLIST -C NORESEQ -C TRACE -U

Recompiler les programmes.

On supprime NOCHECK que l'on décompose en CHECKDIV et NOCHECKNUM.
On remplace BOUND par NOBOUND.

Attention toutefois : si le programme semble se dérouler normalement, une division par zéro donne "an undefined result" ... Quand au débordement de tableau, il écrase les variables définies au delà.

27 mars 2025

Migration, évolution de mksh, comportement de la commandes de test

Les commandes de test avec les opérateurs AND et OR suivants [ condition1 -a condition2 ] et  [ condition1 -o condition2 ] peuvent ne pas être interprétées de la même manière en fonction de la version de mksh.

Avec l'ancienne machine :

hr9@srv001:/home/adm/hr9> echo "$KSH_VERSION"
@(#)MIRBSD KSH R39 2009/08/01
hr9@srv001:/home/adm/hr9> VAR1=""
hr9@srv001:/home/adm/hr9> VAR2=""
hr9@srv001:/home/adm/hr9> [ ! "${VAR1}" -a "${VAR2}" ] && echo "Erreur"
<Pas d'erreur>

Avec la nouvelle machine

hr9@srv002:/home/adm/hr9> echo "$KSH_VERSION"
@(#)MIRBSD KSH R56 2018/01/14
hr9@srv002:/home/adm/hr9> VAR1=""
hr9@srv002:/home/adm/hr9> VAR2=""
hr9@srv002:/home/adm/hr9> [ ! "${VAR1}" -a "${VAR2}" ] && echo "Erreur"
Erreur

Consigne :
  • Ne pas utiliser dans les tests les opérateurs "-a" (AND) et "-o" (OR)

Préférer les syntaxes : 
  • pour AND : [ condition1 ] && [ condition2 ]
  • pour OR : [ condition1 ] || [ condition2 ]
ou
  • pour AND : [[ condition1 && condition2 ]]
  • pour OR : [[ condition1 || condition2 ]]
Et les regroupements :
[[ (condition1 && condition2) || condition3 ]]

Attention aux autres subtilités de l'opérateur [[ ... ]] (opérateurs numériques < == >, globalisation ... )

7 mars 2025

Tester l'ouverture des flux avec Test-NetConnection de PowerShell

Ci dessous un script PowerShell pour tester les connexions depuis un poste client Windows vers un serveur HR Access.

Dans cet exemple le serveur HR est à l'adresse 192.168.126.1 et la base de données sur 192.168.126.2
Les ports du LISTENER, du HTTP, AP0, SSH sont 1521, 1100, 1101 et 22
L'applicatif doit être démarré et à l'écoute.

Avoir exécuté la commande ipconfig /flushdns dans une fenêtre de commande DOS
Exécuter, dans une fenêtre PowerShell, le script ci-dessous :

$ipList = @(
@{IP="192.168.126.2"; Port=1521},
@{IP="192.168.126.1"; Port=1100},
@{IP="192.168.126.1"; Port=1101},
@{IP="192.168.126.1"; Port=22 }
)

$logFile = "test-netconnection.log"
"" | Out-File -FilePath $logFile

Write-Host "Les résultats sont enregistrés dans $logFile" -ForegroundColor Cyan

foreach ($entry in $ipList) {
$ip = $entry.IP
$port = $entry.Port
$result = Test-NetConnection -ComputerName $ip -Port $port

if ($result.TcpTestSucceeded) {
$message = "${ip}:${port} est accessible"
Write-Host "${ip}:${port} est accessible" -ForegroundColor Green
} else {
$message = "${ip}:${port} est injoignable"
Write-Host "${ip}:${port} est injoignable" -ForegroundColor Red
}

$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
"$timestamp - $message" | Out-File -FilePath $logFile -Append
}

Résultat (si les flux sont ouverts et les applications à l'écoute) :

192.168.126.2:1521 est accessible
192.168.126.1:1100 est accessible
192.168.126.1:1101 est accessible
192.168.126.1:22 est accessible

6 mars 2025

Wallet Oracle et SQLPlus

Créer un wallet Oracle permet d'y stocker les mots de passe de coinnexion, et ainsi d'éviter de retrouver des sqlplus HR/PASSWORD dans les scripts d'exploitation

Exemple (sur une machine disposant du client Oracle)

La base est HR9DEV hébergée par le serveur HOST_HR9DEV, les comptes HR et JETSPEED. Nous allons créer des alias HR9DEV_HR et HR9DEV_JETSPEED.

Les commandes permettent d'indiquer le mot de passe en ligne. Pour éviter qu'il ne soit accessible dans l'historique de commande, préférer répondre à la question  qui sera posée.

mkdir $HOME/.wallet

chmod 700 $HOME/.wallet

cd $HOME/.wallet

mkstore -wrl . -create

Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.
Enter password: *******
Enter password again: *******

mkstore -wrl . -createCredential HR9DEV_JETSPEED JETSPEED

Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.
Your secret/Password is missing in the command line
Enter your secret/Password: ***
Re-enter your secret/Password: ***
Enter wallet password: *******