, , , Effacer la log de votre travail

Vous faites le l’administration, le plus souvent en 5250 sous l’écran de commandes IBMI
==> call QCMD

Vous voulez effacer la log que vous voyez par la commande DSPJOBLOG.

La première solution consiste à vous déconnecter, du coup la log est effacée ou transformée en spool.

Cette méthode efface tout le contexte mis en place, liste de bibliothèques , variables d’environnement, objets dans QTEMP que vous avez peut être mis beaucoup de temps à construire dans vos tests.

L’idée c’est d’avoir une solution moins radicale qui permette de n’effacer que la log de votre travail, c’est pourquoi vous devriez avoir dans vos tools un outil comme celui la

Une commande qu’on a appelé astucieusement CLRLOG que vous pouvez trouver ici

https://github.com/Plberthoin/PLB/tree/master/CLRLOG

Comme le code est simple on le remet ici

On utilise la commande RMVMSG qui n’est utilisable que dans un programme CLLE

Le programme en CLLE

 PGM /*------------------------------------*/        
 /* Supprime les messages de votre log     */        
 /* Ne supprime pas les messages *PGMQ     */        
 /*----------------------------------------*/        
              RMVMSG     PGMQ(*ALLINACT) CLEAR(*ALL) 
              RMVMSG     PGMQ(*EXT) CLEAR(*ALL)      
 ENDPGM

La commande 

 /* Supprime les messages de votre log     */ 
CMD        PROMPT('Clearer la log de votre job')

Remarque :

Cette commande n’efface pas les messages de type *PGMQ

/par
, , , Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)

Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)

Mise en place d’OpenSSH Server sur Windows

Pour mettre en place OpenSSH Server sur Windows, la méthode « standard » consiste à passer par les Paramètres > Applications et fonctionnalités > fonctionnalités facultatives :

Il est recommandé de redémarrer Windows une fois la fonctionnalité ajoutée.

Il suffit ensuite de démarrer le serveur via le gestionnaire de Services Windows :

Il est également souhaitable de configurer le démarrage automatique du serveur :

Remarque

Il est également possible d’installer OpenSSH sur Windows via d’autres sources (GitHub par exemple) ce qui permet, entre autres, de choisir plus facilement sa version d’OpenSSH, voir section Détail.

Création d’un jeu de clefs SSH via ssh-keygen

Pour plus de détails sur la création de clefs, vous pouvez vous référer à l’article de Guillaume Gestion des clefs SSH.

Il est également possible d’utiliser PuttyGen, outil venant avec le client Putty pour générer le jeu de clefs de manière graphique (https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html).

Dans cet article je vais tout réaliser sur l’IBM i via QSH :

$ ssh-keygen -t ecdsa -f ~/.ssh/ssh_key

Mise en place de la clef privée et configuration côté IBM i (client)

On a généré la clef privée dans le répertoire .ssh de l’utilisateur, donc elle est déjà bien en place. Il suffit donc de créer un fichier config dans le répertoire .ssh de l’utilisateur afin de simplifier nos commandes pour la suite.
Voici un exemple de fichier config :

[~/.ssh/config]

Host windows
    Hostname sshd_server.lan
    User jl
    IdentityFile ~/.ssh/key
    StrictHostKeyChecking accept-new
HostNom de la configuration, utilisé à la place des différentes informations à la connexion
HostnameAdresse ou nom du serveur à atteindre
UserNom de l’utilisateur
IdentityFileChemin vers la clef privée
StrictHostKeyChecking accept-newPermet d’ajouter automatiquement la signature du serveur distant au known_hosts

Mise en place de la clef privée et configuration côté Windows (serveur)

Il faut transférer la clef ssh_key.pub vers Windows et l’ajouter soit au fichier %UserProfile%.ssh\authorized_keys pour un utilisateur lambda, soit au fichier C:\ProgramData\ssh\administrators_authorized_keys pour un utilisateur ayant des droits d’administrateur local.

Attention à ce niveau, les droits des fichiers sont un peu particulières, il faut comme toujours avec le SSH réduire au maximum les utilisateurs ayant accès au fichier et, particularité de Windows, ajouter le droit de lecture au profil de service local Système :

Activation du fichier de log – Configuration sshd_config

Afin de pouvoir analyser d’éventuels problèmes ou simplement vouloir observer un peu plus en détail les différentes étapes de la mise en relation d’un flux ssh il est possible d’activer la log du serveur.

Par défaut celle-ci est redirigée vers les journaux d’évènements Windows et est seulement en « info ».
On les retrouver via l’Observateur d’événements Windows :

Le mieux à mon avis est de repasser par un système plus standard, soit un vrai fichier de logs.

Pour ce faire, il faut aller modifier le fichier de configuration du serveur SSH, généralement il se trouve ici : 

C:\ProgramData\ssh\sshd_config
ou
%ProgramData%\ssh\sshd_config

Il faut rechercher les lignes suivantes :

[sshd_config]

# Logging
#SyslogFacility AUTH
#LogLevel INFO

Les décommenter et indiquer les valeurs suivantes :

[sshd_config]

# Logging
SyslogFacility LOCAL0
LogLevel Debug3

Une fois la configuration modifiée et le serveur redémarré, il suffit de retenter une connexion puis d’aller consulter le fichier de log :

C:\ProgramData\ssh\logs\sshd.log
ou
%ProgramData%\ssh\logs\sshd.log

Remarque

Les problèmes courants se passent généralement autour des lignes liées au fichier authorized_keys ou administrators_authorized_keys, problèmes de droits ou
chemin du fichier utilisé…

Test de SSH IBM i vers Windows

On peut maintenant tester le tout via QSH ou CALL QP2TERM.
Grâce au fichier config la commande est simple :
(l’option -T permet de désactiver l’allocation d’un pseudo terminal)

$ ssh -T windows
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Il est maintenant possible d’exécuter des commandes Shell Windows à partir de cette connexion.

Si on voulait obtenir les mêmes niveaux de log côté client (IBM i) que l’on a activé côté Windows, on pourrait utiliser la commande suivante :

$ ssh -T -vvv windows
OpenSSH_8.0p1, OpenSSL 1.1.1t  7 Feb 2023                                            
debug1: Reading configuration data /home/jl/.ssh/config                              
debug1: /home/jl/.ssh/config line 1: Applying options for *                          
debug1: /home/jl/.ssh/config line 4: Applying options for laptop                     
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config
...
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Pour plus de détails

OpenSSH.com : https://www.openssh.com/
OpenSSH Server sous Windows – Document Microsoft : https://learn.microsoft.com/fr-fr/windows-server/administration/openssh/openssh_overview
OpenSSH – GitHub : https://github.com/PowerShell/Win32-OpenSSH/releases
/par
, ,

Connexions sécurisées via ACS & gestion des certificats

Sécurisez vos services IBM i ! Nous ne le répéterons jamais suffisamment : vous devez crypter les accès au telnet 5250, au serveur de base de données etc … Bref partout où transitent aussi bien vos profils/mots de passe que vos informations métier.

Nous prenons ici l’exemple de telnet, le plus visuel.

Pour crypter vos connexions telnet : https://www.ibm.com/docs/en/i/7.5?topic=server-assigning-certificate-telnet

En synthèse :

  1. Importer ou créer un certificat dans DCM (Digital Certificate Manager)
  2. Associer ce certificat aux services à sécuriser : TELNET ici mais aussi CENTRAL, SIGNON, DATABASE …
  3. Ne pas oublier de permettre la connexion sécurisée à telnet :
Permettre l'accès non sécurisé et sécurisé (ports 23 et 992) :
CHGTELNA ALWSSL(*YES) 

Permettre l'accès sécurisé uniquement (port 992 uniquement) :
CHGTELNA ALWSSL(*ONLY)

Dès lors vous pouvez vous connecter avec ACS en mode sécurisé. Soit en indiquant au niveau de la configuration dans l’émulateur 5250 (menu Communication puis Configuration) :

Soit au niveau de la connexion système dans sa globalité :

A la prochaine connexion vous obtenez :

Mais comment ces certificats sont-ils gérés par ACS ?

Principe d’un certificat, chaîne de certification

Un certificat est une clé de cryptage permettant de chiffrer les données entre un serveur et un client.

La question est de savoir comment faire confiance à un certificat (celui de votre banque par exemple ?).

Un certificat est lui-même signé, c’est à dire validé, par une autorité de certification à laquelle nous faisons confiance.

Exemple avec les informations issues d’un navigateur :

Le navigateur fait confiance à www.volubis.fr car le certificat est lui-même signé par « Gandi Standard SSL CA 2 » et « USERTrust RSA Certification Authority » qui sont eux connus du navigateur :

D’autres critères entrent en compte comme la durée de validité par exemple

Pour un certificat non reconnu par votre navigateur, vous avez :

Validation par Access Client Solutions

ACS va utiliser la même mécanique : si l’autorité de certification est connue de ACS, alors le certificat est validé.

Si l’autorité n’est pas connue : demande à l’utilisateur de valider ou non l’accès.

Access Client Solutions utilise plusieurs magasins de certificats pour stocker les autorités :

  • le magasin lié à votre JVM qui exécute ACS
  • un magasin propre à ACS en complément

Magasin lié à la JVM

Pour trouver la JVM utilisée par ACS :

Java utilise par défaut un magasin de certificats JAVA_HOME\lib\security\cacerts. Ce magasin est protégé par un mot de passe (défaut = changeit)

Remarque :

Cette configuration par défaut peut être modifiée par fichier de configuration ou arguments de démarrage de la JVM.

Ou outil de gestion des certificats est fourni avec votre JVM : keytool (cf https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html)

Exemple :

Nous retrouvons bien notre autorité primaire « USERTrust RSA Certification Authority » :

Magasins liés à ACS

Par défaut, chaque utilisateur d’ACS dispose de son propre magasin de certificat (complémentaire à celui de l’environnement Java ci-dessus).

Dans les préférences vous retrouvez l’emplacement des configurations :

Access Client Solutions dispose également d’un outil de gestion des certificats pour son propre magasin uniquement : menu « Outils » puis « Gestion des clés » :

Cela vous permet d’importer, supprimer, voir vos certificats.

Remarque :

Cette configuration par défaut peut être modifiée par fichier de configuration AcsConfig.properties : permet d’indiquer l’emplacement du magasin de certificats.

Cas d’un certificat « internet »

Si vous avez acheté votre certificat auprès d’un organisme certificateur (Gandi pour nous, mais aussi OVH, Sectigo … Let’s encrypt gratuit), Access Client Solutions ne devrait rien vous demander et accepter directement le certificat : les autorités présentes dans le magasin associé à votre JVM permettent la validation.

Vous pouvez rencontrer des problèmes avec d’anciennes installations de Java non mises à jour : les nouvelles autorités de certification ne seront pas présentes. Bien sûr cela n’arrive jamais.

Cas d’un certificat « local »

Pour un certificat que vous avez généré sur votre IBM i, ou autre plateforme dans votre SI, si vous disposez de vos propres autorités de certification internes (fréquent dans les sociétés de grande taille) : Access Client Solutions ne dispose pas des autorités permettant la validation !

Remarque :

Si vos équipes de déploiement des postes client livrent les autorités de certification dans le magasin de la JVM, vous revenez dans le cas précédent.

A la première connexion, vous avez ce message :

Non : vous refusez la connexion

Oui : l’autorité de certification est ajoutée au magasin de certificats d’ACS.

Après avoir répondu « Oui » :

Aucun message affiché lors des prochaines connexions.

Changement de certificat

Comment faire en sorte que la sécurisation de vos services ou un changement de certificat soit transparent pour vos utilisateurs ?

Nous savons que demander à des centaines d’utilisateurs de répondre « Oui » peut générer un support très important aux équipes et être anxiogène.

Mise en place

Au-delà du certificat, il faut procéder aux changements de configurations : au niveau de la définition du système et/ou de la session 5250.

Pour le certificat, plusieurs solutions :

  1. Vous disposez d’un poste modèle sur lequel vous avez installé ACS, et importez manuellement l’autorité de certification. Il vous suffit alors de déployer le fichier cacerts de ACS sur les différents postes.

Ce dernier est ici : "C:\Users\{USER}\Documents\IBM\iAccessClient\Private\{USER}\cacerts"

  1. Dans le fichier de configuration AcsConfig.properties : vous pouvez indiquer un fichier cacerts mutualisé sur un lecteur réseau par exemple :

  1. Injection du certificat en mode commande

ACS dispose de commande, avec option silencieuse :

/PLUGIN=certdl => demande à downloader l’autorité de certification et l’importer dans le magasin

/SYSTEM=nom système configuré => depuis le système en question

A intégrer dans vos outils de déploiement pour exécution sur chaque poste client ! Le certificat est ensuite visible dans le menu « Outils » puis « Gestion des clés ».

Renouvellement

  1. Le certificat est issu de la même autorité de certification que le précédent : rien à faire ! C’est l’autorité qui est stockée, pas le certificat lui-même
  2. Le certificat est issu d’une autre autorité (autre fournisseur, autorité précédente périmée ou invalidée) : il faut injecter l’autorité dans le magasin de certificat (cf Mise en place)

En synthèse : pas de difficulté, plusieurs solutions en fonction de votre organisation et outillage !

N’oubliez pas de renouveler vos certificats avant la date d’expiration …

/par
, , Comment tracer immédiatement la création d’un PF ou d’une table dans une bibliothèque ?

Vous voulez savoir immédiatement quand un fichier PF ou table est créé dans votre bibliothèque

4 principales techniques sont à votre disposition,

La première, les programmes d’exit

QIBM_QCA_CHG_COMMAND pour

CRTPF
CRTDUPOBJ
CPYF
MOVOBJ
RSTOBJ

QIBM_QZDA_SQL1 ou QIBM_QZDA_SQL2
Pour les create table SQL
Attention sera appelé pour chaque requête SQL sur votre système
et la syntaxe peut être compliqué

La deuxième technique consiste à utiliser la journalisation

Si votre bibliothèque est journalisée

— Mise en plage des règles d’héritages
— pour avoir tous les événnements, ce qui n’est pas le cas par défaut

ENDJRNLIB LIB(votre bib)

STRJRNLIB LIB(votre bib)
JRN(votre bib/votre journal)
INHRULES((*ALL *ALLOPR *INCLUDE *BOTH *OPNCLO))

Protocole de test

CREATE TABLE
code D Type CT

CRTPF
code D Type CT

CRTDUPOBJ
code D Type CT

MOVOBJ OBJ(GAIA/APF3) OBJTYPE(*FILE) TOLIB(GDATA)
Pas de poste est le fichier n’est pas journalisé

CPYF
code D type CT

RSTOBJ
Pas de poste et le fichier n’est pas journalisé
il est journalisé que si c’est une restauration de lui même, paramètre du RSTOBJ … STRJRN(*YES)

vous pourrez faire un programme d’exit sur le journal pour les code D type CT
mais attention donc
donc pas de poste pour les MOVOBJ et les RSTOBJ

La troisième technique est d’utiliser le journal d’audit


s’il est démarré et qu’il a la valeur *CREATE, vous allez avoir des postes code T type CO pour les créations
et OR, RA, RO pour les restaurations

Vous pourrez faire un programme d’exit sur le journal d’audit pour les postes vues ci dessous,
remarque les outils de replication logiciel utilise cette techno.

La quatrième, le journal du catalogue DB2

Le catalogue bénéficie de son propre journal, QDBJRNFILE de la Bibliothèque QRECOVERY

Quand vous créez une table ou un PF, vous avez un poste code R type PT ou PX qui sont générés

Vous pouvez mettre en place un programme d’exit journal sur celui ci

C’est une solution simple et efficace

Conclusion

Pas de solution miracle
si votre base est journalisée utiliser la solution 2 semble la plus simple
surtout que dans certain cas on ne voudra pas tracer les MOVOBJ et les RSTOBJ

/par
, , , , , Débuter avec API RSE

Dans la dernière TR est apparue une nouveauté très intéressante « API RSE », c’est un ensemble d’API REST fournies avec votre système d’exploitation au travers du serveur ADMIN5.


Ces APIs sont utilisables depuis le web et permettent de lancer des commandes, accéder à l’IFS, de lancer de requêtes SQL…

Ce service ne fonctionne qu’en TLS vous devrez donc le sécuriser par l’administration http ://Votre_systeme:2001/HTTPAdmin

Vous devez ensuite le démarrer s’il ne l’est pas c’est le serveur ADMIN5

==>STRTCPSVR SERVER(*IAS) INSTANCE(admin5)

Ce serveur tourne par défaut sur le port 2012

https://Votre_systeme:2012/openapi/ui/

Vous devrez vous authentifiez pour commencer utilisez un user et un mot de passe ibmi, vous cliquez sur authorize

Nous allons tester une commnde CL

Vous cliquez sur try input

Vous avez un flux json avec vos commandes IBMI à l’intérieur vous cliquez sur execute

Vous avez alors le résultat

A noter que vous avez le lien, en haut pour l’intégrer dans vos applications

Conclusion
C’est gratuit c’est technologies actuelles, testez les possibilités de ce service

Pour en savoir plus


la pause café de volubis ici : https://www.volubis.fr/Pausecaf/PAUSECAF91.html

le site IBM : https://www.ibm.com/support/pages/node/6982701

/par
, , , , DEBOGUER UN WATCHER

Il est difficile de déboguer un watcher parce qu’on ne maitrise pas son lancement.

Voici une méthode en utilisant RDI, qui va vous permet de le faire :

  1. Trouver le nom du programme à analyser :

WRKWCH WCH(*ALL) :

  • 5 pour le détail
  • Dans RDI, clic droit sur le programme à déboguer => débogage ou couverture de code (entrée de service) => définir un point d’entrée de service

Le message d’affiche :

Pour tester, on peut simuler un traitement qui va planter. Dans notre cas, on fait un call d’un programme qui n’existe pas, et donc ça va faire un plantage dans QSYSOPR.

SBMJOB CMD(CALL PGM(GAIA/ERREURA)) 

        JOB(ERREURA)                

        JOBQ(QSYSNOMAX)         

Une fois le programme a été lancé, sur RDI s’affichera le message suivant :

Cliquer sur « Afficher *LISTING »

Pour avancer d’un pas on peut utiliser la touche F5 ou en cliquant sur la flèche :

Pour afficher les valeurs des variables il suffit de passer la souris sur le nom de la variable :

Conclusion : c’est une solution simple pour déboguer un watcher ou un programme dont vous ne maitrisez pas le lancement.

Le programme doit être compilé avec le source.

Vous devrez avoir le droit pour faire ce type d’opération. Soit au niveau de profil, soit par les fonctions usages.

/par
, , Informations sur les SAVF

Les groupes DB2 pour la TR2 de la V7R5 et de la TR8 de la V7R4 sont disponibles, une des nouveautés c’est les vues sur les fichiers de sauvegarde

La première vue sur les SAVF SAVE_FILE_INFO permet d’avoir des informations sur le SAVF

par exemple
vous voulez connaitre les SAVF qui date de plus de 6 mois

select * from QSYS2.SAVE_FILE_INFO
where SAVE_TIMESTAMP < current date – 6 month
order by SAVE_TIMESTAMP desc

Vous pouvez par exemple utiliser la fonction SQL QCMDEXC pour faire le ménage plus d’informations ici
https://www.gaia.fr/qcmdexc-en-fonction-sql/

La deuxième vue sur les objets sauvegardés dans les SAVF, QSYS2.SAVE_FILE_OBJECT permet d’avoir des informations sur les ojets contenus dans le SAVF

Par exemple vous voulez savoir, si un objet est dans une sauvegarde et sa date de sauvegarde

select * from QSYS2.SAVE_FILE_OBJECTS
where OBJECT_NAME = ‘votre objet’ and OBJECT_TYPE = ‘votre type’
order by SAVE_TIMESTAMP desc

Attention
Ces fonctions sont à lancer en batch, c’est des informations qui mettent du temps à être extraites

/par
, Messages CPF1124 et CPF1164

Quand un travail démarre, il crée dans la log système un message CPF1124 et un message CPF1164 quand il se termine.

C’est comme ca qu’on sait qu’un job à tourné

Mais attention, Il existe des travaux pour lesquels les messages CPF1124 et CPF1164 ne sont pas logués dans QHST : il s’agit des SPAWN jobs.

Les travaux QP0ZSPWP & QP0ZSPWT en sont de bons exemples.

Spawn batch jobs : https://www.ibm.com/docs/en/i/7.4?topic=jobs-spawn-batch

Spawn est une fonction qui crée un nouveau processus de travail (processus enfant) qui hérite de nombreux attributs du processus appelant (processus parent). Un nouveau programme est spécifié et commence à s’exécuter dans le processus enfant. Lorsque vous lancez un travail par lots, vous utilisez un travail parent pour transmettre des arguments et des variables d’environnement au travail enfant. L’API spawn() utilise des travaux batch immédiats, des travaux pré-démarrés ou des travaux batch pré-démarrés.

https://www.ibm.com/docs/en/i/7.4?topic=ssw_ibm_i_74/apis/spawn.htm

https://www.ibm.com/docs/en/i/7.4?topic=programs-example-using-process-related-apis

Ca peut être le cas aussi pour les jobs QCTXDMON (IBM transformer)

plus rigolo

Vous pouvez demander à supprimer ces messages

Pour cela vous devez créer une dtaara QWTFMSG dans QUSRSYS :

CRTDTAARA DTAARA(QUSRSYS/QWTFMSG) TYPE(*CHAR) LEN(14) VALUE(‘CPF1124CPF1164’)

Cette valeur est prise en compte au démarrage de vos sous systémes

elle est globale c’est dommage qu’on ne puisse préciser un sous système

Attention


Beaucoup d’outils d’analyse utilise ces messages pour vérifier le bon traitement d’une tache

/par
, Les instructions SQL d’un profil

Vous voulez récupérer les requêtes SQL exécutées sous une session interactive

Si vous pouvez vous connecter sous le profil c’est relativement simple

Connectez vous sous le profil et sous STRSQL faites <F13>

Vous pouvez indiquer un fichier avec différentes options, le fichier par défaut s’appelle QSQLSESS de QGPL

La difficulté existe, si vous ne pouvez pas vous connecter sous le profil en effet ces informations sont stockées dans le profil.

Pour les voir vous devrez donc utiliser la commande DMPSYSOBJ

Comme ceci

DMPSYSOBJ OBJ(‘ISQLSTvotreuser*’) +
CONTEXT(QRECOVERY) TYPE(19) SUBTYPE(EE)

Vous obtenez un spool QPSRVDMP que vous pourrez analyser

Bien sur vous devez avoir le droit de dumper et le droit sur le profil

Pour vous aider nous avons fait un outil DMPSQLUSR que vous pouvez trouvez ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS

Il n’est pas parfait, mais il produit un fichier SQLLISTE dans QTEMP qui contiendra toutes instructions exécutées

Rappel :

Vous pouvez également retrouver des informations sur l’exécution des requêtes dans des moniteurs DB ou dans le cache SQL.

/par
, , , Les zones HIDDEN en SQL

Il existe un comcept dans SQL sur les tables qui s’appelle les zones cachées.
Je vais essayer de vous expliquer ce que c’est.

Exemple :

CREATE TABLE SALAR (
NUMERO CHAR(6) CCSID 1147 NOT NULL DEFAULT  » ,
NOM CHAR(20) CCSID 1147 NOT NULL DEFAULT  » ,
PRENOM CHAR(30) CCSID 1147 NOT NULL DEFAULT  » ,
SALAIRE DECIMAL(5, 0) NOT NULL DEFAULT 0 IMPLICITLY HIDDEN )

Pour faire simple ces des zones qui n’apparaîtront pas si vous faites un select *


Il y plusieurs buts à cette démarche , caché sommairement des informations ou simplifier des requêtes en cachant des informations utiles et enfin les zones complétables automatiquement les bien connues date, heure et utilisateur de modification.
Maintenant que vous savez ce que c’est je vais vous expliquer l’impact sur vos développements existants.
D’abord bien sûr si vous avez des select * dans vos développements ça produira une erreur si vous respectez les règles de développement vous ne devriez pas en avoir.
Ensuite sur les insert , par défaut il ne connait que les zones non cachées vous devrez indiquer explicitement les zones cachées que vous voulez alimenter.

Conclusion
Ça peut être intéressant dans certains cas pour éviter une vue qui aurait juste pour fonction de limiter les zones.
Attention toutefois, si voulez utiliser cette possibilité toutes les zones sont visibles dans les invites Sql …

Et enfin une zone ajoutée même en hidden change le niveau de format puisqu’il est calculé sur l’ensemble des zones.

/par