Abdelbar SAJI

Ingénieur Systèmes Mainframe

Ingénieur en Cybersécurité

Ingénieur Systèmes & Réseaux

Développeur Full Stack

Cryptanalyst

Abdelbar SAJI

Ingénieur Systèmes Mainframe

Ingénieur en Cybersécurité

Ingénieur Systèmes & Réseaux

Développeur Full Stack

Cryptanalyst

Articles

Gestion Mémoire CICS : Storage Management

septembre 12, 2025 CICS, Mainframe

Architecture mémoire CICS complète

CICS gère plusieurs zones mémoire distinctes avec une hiérarchie sophistiquée basée sur la ligne des 16 Mo et l'adressage 64-bit. Cette architecture évolue constamment pour supporter les applications modernes Java/REST tout en préservant la compatibilité avec les programmes COBOL traditionnels.

Hiérarchie mémoire complète : BELOW vs ABOVE vs 64-bit

L'architecture mémoire CICS s'articule autour de trois espaces d'adressage distincts avec des caractéristiques et usages spécifiques :

				
					┌─────────────────────────────────────────────────────────────────┐
│                   HIÉRARCHIE MÉMOIRE CICS                      │
├─────────────────────────────────────────────────────────────────┤
│ 🔴 BELOW THE LINE (< 16MB) - Adressage 24-bit                │
│    ┌─────────────┬─────────────┬─────────────┬─────────────┐   │
│    │     DSA     │    UDSA     │    CDSA     │   Système   │   │
│    │ (Dynamic    │ (User       │ (Common     │   OS/390    │   │
│    │  Storage)   │  Domain)    │  Domain)    │             │   │
│    │             │             │             │             │   │
│    │ • Tâches    │ • Programmes│ • CICS      │ • MVS       │   │
│    │ • Work Areas│   utilisateur│  Control   │ • JES       │   │
│    │ • Commarea  │ • Copie WS  │  Blocks     │ • RACF      │   │
│    └─────────────┴─────────────┴─────────────┴─────────────┘   │
│                                                                 │
│ 🟡 ABOVE THE LINE (16MB - 2GB) - Adressage 31-bit            │
│    ┌─────────────┬─────────────┬─────────────┬─────────────┐   │
│    │    EDSA     │   EUDSA     │   ECDSA     │   ERDSA     │   │
│    │ (Extended   │ (Extended   │ (Extended   │ (Extended   │   │
│    │  Dynamic)   │  User)      │  Common)    │  Read-Only) │   │
│    │             │             │             │             │   │
│    │ • Gros      │ • Programmes│ • Shared    │ • Load      │   │
│    │   volumes   │  THREADSAFE │  Resources  │   Modules   │   │
│    │ • Buffers   │ • Working   │ • Système   │ • Read-Only │   │
│    │ • I/O       │   Storage   │   Tables    │   Data      │   │
│    └─────────────┴─────────────┴─────────────┴─────────────┘   │
│                                                                 │
│ 🟢 64-BIT STORAGE (> 2GB) - Adressage 64-bit                 │
│    ┌─────────────┬─────────────┬─────────────┬─────────────┐   │
│    │  JVM HEAP   │  Container  │   Liberty   │  Modernisation│  │
│    │             │   Runtime   │   Profile   │              │   │
│    │ • Java Apps │ • Docker    │ • REST APIs │ • Node.js    │   │
│    │ • Heap/GC   │   Support   │ • Web Svcs  │ • Python     │   │
│    │ • JAR Files │ • zCX       │ • JSON/XML  │ • Analytics  │   │
│    └─────────────┴─────────────┴─────────────┴─────────────┘   │
└─────────────────────────────────────────────────────────────────┘
				
			

Tableau comparatif des espaces mémoire

				
					╔══════════════╦══════════════╦══════════════╦═══════════════════╗
║   CRITÈRE    ║  BELOW 16MB  ║  ABOVE 16MB  ║    64-BIT        ║
╠══════════════╬══════════════╬══════════════╬═══════════════════╣
║ Adressage    ║ 24/31-bit    ║ 31-bit       ║ 64-bit           ║
║ Taille Max   ║ 16 MB        ║ 2 GB         ║ Plusieurs TB     ║
║ Usage        ║ Legacy COBOL ║ Programmes   ║ Java/Containers  ║
║              ║ Système      ║ modernes     ║ Applications Web ║
║ Performance  ║ Très rapide  ║ Rapide       ║ Optimisé I/O     ║
║ Contraintes  ║ Limité       ║ Compatible   ║ Haute mémoire    ║
║ Threading    ║ Non-thread   ║ THREADSAFE   ║ Multi-thread     ║
║ Modernité    ║ ⭐⭐         ║ ⭐⭐⭐⭐     ║ ⭐⭐⭐⭐⭐       ║
╚══════════════╩══════════════╩══════════════╩═══════════════════╝
				
			

Configuration avancée des Storage Areas

La configuration optimale des zones mémoire nécessite une approche méthodique basée sur les patterns d'usage et les projections de charge :

				
					* Configuration DFHSIT optimisée pour environnement moderne
DFHSIT TYPE=FINAL,
    * === ZONES BELOW THE LINE (< 16MB) ===
    DSA=20480,              * Dynamic Storage Area (20MB)
    UDSA=2048,              * User Domain Storage (2MB)  
    CDSA=8192,              * Common Domain Storage (8MB)
    
    * === ZONES ABOVE THE LINE (16MB-2GB) ===
    EDSA=65536,             * Extended DSA (64MB) - Gros volumes
    EUDSA=16384,            * Extended User DSA (16MB) - Programmes
    ECDSA=32768,            * Extended Common DSA (32MB) - Système
    ERDSA=8192,             * Extended Read-Only DSA (8MB)
    
    * === PROTECTION MÉMOIRE ACTIVÉE ===
    STGPROT=YES,            * Protection contre corruptions
    STGRCVY=1024,           * Storage Recovery (1MB buffer)
    CUSHION=10,             * 10% cushion pour urgences
    
    * === OPTIMISATIONS PERFORMANCE ===
    MAXOPENTCBS=100,        * TCBs ouverts simultanément
    MAXSSLTCBS=20,          * SSL/TLS TCBs
    TCBLIMIT=999,           * Limite totale TCBs
    
    * === SUPPORT 64-BIT POUR JAVA ===
    JVM=YES,                * Support JVM intégré
    JVMPROPS='heap_size=512M', * Heap Java initial
    LIBPATH='/opt/cics/lib:/java/lib'  * Librairies 64-bit
				
			

Protection mémoire avancée (STGPROT=YES)

L'activation de la protection mémoire CICS insère des guard zones automatiques et détecte les corruptions avant qu'elles ne se propagent. Bien que générant un léger surcoût (2-3% de performance), cette fonctionnalité est indispensable en production :

				
					* Impact de STGPROT=YES sur l'architecture mémoire
┌─────────────────────────────────────────────────────────────────┐
│              PROTECTION MÉMOIRE ACTIVÉE                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│    [DATA BLOCK]  [GUARD]  [DATA BLOCK]  [GUARD]  [DATA BLOCK]  │
│    ┌─────────┐  ┌─────┐  ┌─────────┐   ┌─────┐  ┌─────────┐    │
│    │ Program │  │ ### │  │  Work   │   │ ### │  │ Control │    │
│    │  Data   │  │ ### │  │ Storage │   │ ### │  │  Block  │    │
│    │         │  │ ### │  │         │   │ ### │  │         │    │
│    └─────────┘  └─────┘  └─────────┘   └─────┘  └─────────┘    │
│         │          │          │           │          │         │
│         ▼          ▼          ▼           ▼          ▼         │
│    Valid Data   Guard Zone  Valid Data  Guard Zone Valid Data  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

* Configuration de protection dans le programme COBOL
WORKING-STORAGE SECTION.
01  PROTECTED-WORK-AREA.
    * Guard pattern automatique inséré par CICS si STGPROT=YES
    05  CRITICAL-DATA           PIC X(1000).
    05  CUSTOMER-BUFFER         PIC X(2000).
    05  TRANSACTION-LOG         PIC X(500).

PROCEDURE DIVISION.
MEMORY-PROTECTION-DEMO.
    * Vérification automatique des guard zones à chaque accès
    MOVE CUSTOMER-ID TO CRITICAL-DATA(1:10)
    
    * Si corruption détectée → ASRA abend automatique
    * Message console : DFH0202 Storage violation detected
    
    * Test de détection de corruption
    EXEC CICS HANDLE CONDITION
        ERROR(CORRUPTION-DETECTED)
    END-EXEC
    
    * CICS vérifie automatiquement l'intégrité
    PERFORM BUSINESS-LOGIC
    
    EXEC CICS RETURN END-EXEC.

CORRUPTION-DETECTED.
    EXEC CICS WRITE OPERATOR
        TEXT('Memory corruption in task ' || EIBTASKN)
        ROUTECODES(1,11)
    END-EXEC
    
    EXEC CICS ABEND ABCODE('SMEM') CANCEL END-EXEC.
				
			

Détection et traitement des conditions SOS (Short on Storage)

Les conditions SOS représentent l'un des défis majeurs dans la gestion mémoire CICS. Une stratégie proactive de détection et de récupération est essentielle :

				
					* Monitoring SOS et récupération automatique
WORKING-STORAGE SECTION.
01  SOS-MANAGEMENT-SYSTEM.
    05  STORAGE-THRESHOLDS.
        10  DSA-WARNING-LEVEL       PIC S9(3) COMP VALUE 80.
        10  DSA-CRITICAL-LEVEL      PIC S9(3) COMP VALUE 90.
        10  DSA-EMERGENCY-LEVEL     PIC S9(3) COMP VALUE 95.
    05  SOS-COUNTERS.
        10  SOS-INCIDENTS           PIC S9(9) COMP VALUE ZERO.
        10  RECOVERIES-ATTEMPTED    PIC S9(9) COMP VALUE ZERO.
        10  SUCCESSFUL-RECOVERIES   PIC S9(9) COMP VALUE ZERO.

PROCEDURE DIVISION.
SOS-DETECTION-AND-RECOVERY.
    * Monitoring continu des niveaux mémoire
    EXEC CICS INQUIRE STORAGE('DSA')
        MAXSIZE(WS-DSA-MAX)
        SIZE(WS-DSA-CURRENT)
        CUSHION(WS-DSA-CUSHION)
        FREESPACE(WS-DSA-FREE)
    END-EXEC.
    
    COMPUTE WS-USAGE-PERCENT = 
        (WS-DSA-CURRENT / WS-DSA-MAX) * 100.
    
    * Déclenchement des niveaux d'alerte
    EVALUATE TRUE
        WHEN WS-USAGE-PERCENT > DSA-EMERGENCY-LEVEL
            PERFORM EMERGENCY-MEMORY-RECOVERY
        WHEN WS-USAGE-PERCENT > DSA-CRITICAL-LEVEL
            PERFORM CRITICAL-MEMORY-CLEANUP
        WHEN WS-USAGE-PERCENT > DSA-WARNING-LEVEL
            PERFORM PREVENTIVE-MEMORY-MANAGEMENT
    END-EVALUATE.

EMERGENCY-MEMORY-RECOVERY.
    * Messages typiques en console lors de SOS
    * DFH0502E Storage cushion below threshold in DSA
    * DFH0503E Short on storage condition detected
    * DFH0504I Attempting storage recovery procedures
    
    ADD 1 TO SOS-INCIDENTS
    ADD 1 TO RECOVERIES-ATTEMPTED
    
    * Récupération d'urgence - libération forcée
    EXEC CICS PERFORM SHUTDOWN IMMEDIATE
        PGMNAME('NONESSENTIAL-TASK')
    END-EXEC
    
    * Activation du cushion d'urgence
    EXEC CICS FREE STORAGE
        FROM(CACHED-BUFFERS)
        LENGTH(CACHE-BUFFER-SIZE)
    END-EXEC
    
    * Purge des programmes non-résidents
    EXEC CICS DISCARD PROGRAM('TEMP-*')
    END-EXEC
    
    * Compression des temporary storage queues
    EXEC CICS DELETEQ TS QUEUE('TEMP*') END-EXEC
    
    IF MEMORY-RECOVERED
        ADD 1 TO SUCCESSFUL-RECOVERIES
        EXEC CICS WRITE OPERATOR
            TEXT('Emergency memory recovery successful')
        END-EXEC
    ELSE
        EXEC CICS WRITE OPERATOR
            TEXT('CRITICAL: Unable to recover sufficient memory')
            ROUTECODES(1,2,11)
        END-EXEC
    END-IF.

* Exemples de messages SOS dans la console MVS
* DFH0502E 14.30.42 STC05678 CICSPROD Short on storage in DSA
* DFH0503W 14.30.42 STC05678 CICSPROD Storage cushion exhausted  
* DFH0504I 14.30.43 STC05678 CICSPROD Storage recovery initiated
* DFH0505I 14.30.45 STC05678 CICSPROD 2.5MB storage reclaimed
				
			

Monitoring avancé SMF et outils professionnels

L'ingénieur système expérimenté utilise plusieurs couches de monitoring pour une visibilité complète de la mémoire CICS :

				
					* === MONITORING NIVEAU 1 : SMF 110 Records ===
* Structure simplifiée d'un record SMF pour mémoire CICS
01  SMF110-MEMORY-SECTION.
    05  SMF110-DSA-USAGE.
        10  SMF110-DSA-CURRENT      PIC S9(9) COMP.     * Utilisation courante
        10  SMF110-DSA-PEAK         PIC S9(9) COMP.     * Pic d'utilisation
        10  SMF110-DSA-GETMAINS     PIC S9(9) COMP.     * Nombre GETMAIN
        10  SMF110-DSA-FREEMAINS    PIC S9(9) COMP.     * Nombre FREEMAIN
    05  SMF110-EDSA-USAGE.
        10  SMF110-EDSA-CURRENT     PIC S9(9) COMP.
        10  SMF110-EDSA-PEAK        PIC S9(9) COMP.
    05  SMF110-STORAGE-VIOLATIONS   PIC S9(9) COMP.     * Violations détectées
    05  SMF110-SOS-CONDITIONS       PIC S9(9) COMP.     * Conditions SOS

* === RAPPORT SMF TYPIQUE (extrait) ===
CICS Storage Analysis Report                    Date: 12/09/2025
Region: CICSPROD    From: 08:00  To: 20:00
═══════════════════════════════════════════════════════════════
Storage Area     Current   Peak    %Used   Getmains  Freemains
───────────────────────────────────────────────────────────────
DSA              15.2MB   18.9MB    94%      45,234    44,856
EDSA             48.7MB   52.1MB    81%       2,156     2,098
UDSA              1.8MB    2.0MB    90%       8,765     8,701
CDSA              6.2MB    7.8MB    78%       1,234     1,211
───────────────────────────────────────────────────────────────
Total Below      23.2MB   28.7MB    87%      55,233    54,866
Total Above      48.7MB   52.1MB    81%       2,156     2,098

SOS Conditions: 0        Storage Violations: 0
Memory Efficiency: 96.8%  Fragmentation: 3.2%

Peak Usage Hours:
  10:15 - DSA reached 18.9MB (94.5% of max)
  14:30 - EDSA reached 52.1MB (81.4% of max)
  
Recommendations:
• Consider increasing DSA to 22MB (current max: 20MB)
• Monitor 14:30 workload - potential batch interference
• Excellent violation record - STGPROT working effectively
				
			

Optimisation LSR Pools et Programme Residence

Les Local Shared Resources (LSR) et la gestion des programmes résidents représentent des leviers d'optimisation majeurs souvent sous-exploités :

				
					* === CONFIGURATION LSR OPTIMISÉE ===
* Définition d'un pool LSR pour fichiers VSAM haute fréquence
DEFINE FILE(CUSTOMER) GROUP(MAINGRP)
    DSNAME(PROD.CUSTOMER.KSDS)
    LSR=YES                     * Activation LSR
    LSRPOOLID(1)               * Pool dédié
    STRINGS(50)                * 50 chaînes simultanées
    BUFFERS=POOL               * Buffers partagés

* Configuration du pool LSR dans DFHSIT
LSRPOOL1=(SIZE:32M,BUFFERS:500,KEYLEN:10,HWM:80,LWM:60)

* Impact mémoire LSR vs non-LSR
┌────────────────────────────────────────────────────────────┐
│                    COMPARAISON LSR                        │
├────────────────────────────────────────────────────────────┤
│           │   Sans LSR    │    Avec LSR   │   Économie    │
│───────────┼───────────────┼───────────────┼───────────────│
│ CUSTOMER  │   10MB buffs  │      -        │      -        │
│ ACCOUNTS  │   15MB buffs  │      -        │      -        │  
│ PRODUCTS  │    8MB buffs  │      -        │      -        │
│ ORDERS    │   12MB buffs  │      -        │      -        │
│───────────┼───────────────┼───────────────┼───────────────│
│ TOTAL     │    45MB       │    32MB       │    13MB       │
│ EFFICACITÉ│     65%       │     92%       │   +27%        │
└────────────────────────────────────────────────────────────┘

* === STRATÉGIE PROGRAM RESIDENCE ===
WORKING-STORAGE SECTION.
01  PROGRAM-RESIDENCY-STRATEGY.
    05  HIGH-FREQUENCY-PROGRAMS.
        10  FILLER              PIC X(8) VALUE 'CUSTINQ '.  * 15,000 calls/day
        10  FILLER              PIC X(8) VALUE 'PAYPROC '.  * 8,500 calls/day
        10  FILLER              PIC X(8) VALUE 'BALANCE '.  * 12,000 calls/day
    05  MEDIUM-FREQUENCY-PROGRAMS.
        10  FILLER              PIC X(8) VALUE 'REPORTS '.  * 500 calls/day
        10  FILLER              PIC X(8) VALUE 'ADMIN  '.   * 200 calls/day
    05  LOW-FREQUENCY-PROGRAMS.
        10  FILLER              PIC X(8) VALUE 'YEAREND '.  * 12 calls/year
        10  FILLER              PIC X(8) VALUE 'AUDIT  '.   * 50 calls/year

* Configuration résidence programmes
DEFINE PROGRAM(CUSTINQ) GROUP(HIGHFREQ)
    STATUS(ENABLED)
    RESIDENT(YES)               * Toujours en mémoire
    USAGE(NORMAL)

DEFINE PROGRAM(YEAREND) GROUP(LOWFREQ)  
    STATUS(ENABLED)
    RESIDENT(NO)                * Chargé à la demande
    USAGE(NORMAL)

* Analyse coût/bénéfice résidence
* Programme RESIDENT   : +2MB mémoire, -50ms temps chargement
* Programme NONRESIDENT: +0MB mémoire, +50ms temps chargement
* Break-even: ~200 appels/jour
				
			

Shared Data Tables (SDT) et optimisation I/O

Les SDT permettent de maintenir des données de référence en mémoire partagée, éliminant les I/O répétitifs :

				
					* === IMPLÉMENTATION SHARED DATA TABLES ===
* Définition d'une SDT pour codes postaux (exemple)
DEFINE FILE(POSTCODES) GROUP(REFDATA)
    DSNAME(REF.POSTCODES.KSDS)
    SDT=YES                     * Activation SDT
    SDTSIZE(5M)                 * 5MB en mémoire
    SDTFREQ(3600)               * Refresh toutes les heures

* Programme utilisant SDT
WORKING-STORAGE SECTION.
01  SDT-ACCESS-STATS.
    05  SDT-HITS                PIC S9(9) COMP VALUE ZERO.
    05  SDT-MISSES              PIC S9(9) COMP VALUE ZERO.
    05  I-O-SAVED               PIC S9(9) COMP VALUE ZERO.

PROCEDURE DIVISION.
SDT-OPTIMIZED-LOOKUP.
    * Recherche automatique en SDT puis VSAM si nécessaire
    EXEC CICS READ FILE('POSTCODES')
        RIDFLD(WS-POSTCODE)
        INTO(POSTCODE-RECORD)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    * CICS gère automatiquement SDT hit/miss
    IF WS-RESPONSE = DFHRESP(NORMAL)
        ADD 1 TO SDT-HITS
        ADD 1 TO I-O-SAVED      * I/O évitée grâce à SDT
    END-IF.

* Monitoring SDT effectiveness
EXEC CICS INQUIRE FILE('POSTCODES')
    SDTHITS(WS-SDT-HITS)
    SDTMISSES(WS-SDT-MISSES)
    SDTRATIO(WS-HIT-RATIO)
END-EXEC.

* Résultats typiques SDT bien configurée :
* Hit Ratio: 94.7% (excellent > 90%)
* I/O Reduction: 18,500 I/O évitées par jour
* Response Time: -35ms moyenne par lookup
				
			

Modernisation : JVM Server et gestion mémoire 64-bit

L'intégration des applications Java/REST dans CICS nécessite une approche spécifique de la gestion mémoire 64-bit :

				
					* === CONFIGURATION JVM SERVER DANS CICS ===
* JVMSERVER resource definition
DEFINE JVMSERVER(RESTJVM) GROUP(JAVA)
    STATUS(ENABLED)
    JVMPROFILE(RESTPROFILE)
    
* JVM Profile (membre RESTPROFILE dans DFHJVMPR)
#───────────────────────────────────────────────────────
# Configuration JVM pour applications REST/JSON
#───────────────────────────────────────────────────────
JAVA_HOME=/java/J8.0_64
WORK_DIR=/tmp/cics/work

# === GESTION HEAP 64-BIT ===
-Xms512m                    # Heap initial 512MB
-Xmx2048m                   # Heap maximum 2GB
-Xmn256m                    # Young generation 256MB

# === GARBAGE COLLECTION OPTIMISÉ ===
-XX:+UseG1GC                # G1 Garbage Collector
-XX:MaxGCPauseMillis=200    # Pause GC max 200ms
-XX:G1HeapRegionSize=16m    # Régions G1 16MB
-XX:+UseStringDeduplication # Déduplication chaînes

# === MONITORING JVM ===
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:/logs/gc.log

# === INTÉGRATION CICS ===
-Dcom.ibm.cics.jvmserver.trace.level=2
-Dcom.ibm.cics.jvmserver.heap.dump.on.oom=true

* Programme COBOL appelant service REST Java
WORKING-STORAGE SECTION.
01  JAVA-INTEGRATION.
    05  JVM-HEAP-STATUS.
        10  HEAP-USED           PIC S9(9) COMP.
        10  HEAP-MAX            PIC S9(9) COMP.
        10  GC-COUNT            PIC S9(9) COMP.
    05  REST-REQUEST            PIC X(4000).
    05  REST-RESPONSE           PIC X(8000).

PROCEDURE DIVISION.
CALL-REST-SERVICE.
    * Invocation service REST via JVM Server
    EXEC CICS INVOKE SERVICE('RestCustomerService')
        CHANNEL('REST-CHANNEL')
        RESP(WS-RESPONSE)
    END-EXEC.
    
    * Monitoring heap JVM
    EXEC CICS INQUIRE JVMSERVER('RESTJVM')
        HEAPUSED(HEAP-USED)
        HEAPMAX(HEAP-MAX)
        GCCOUNT(GC-COUNT)
    END-EXEC.
    
    * Alerting si heap critique
    COMPUTE HEAP-PERCENT = (HEAP-USED / HEAP-MAX) * 100
    IF HEAP-PERCENT > 85
        PERFORM JVM-MEMORY-ALERT
    END-IF.

* === ARCHITECTURE MÉMOIRE HYBRIDE ===
┌─────────────────────────────────────────────────────────────────┐
│            CICS + JVM MEMORY ARCHITECTURE                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ CICS Region (31-bit)          JVM Server (64-bit)              │
│ ┌─────────────────────┐      ┌─────────────────────────────┐   │
│ │ DSA/EDSA            │      │ Java Heap                   │   │
│ │ • COBOL Programs    │<────>│ • REST Services             │   │
│ │ • CICS Control      │ IPIC │ • JSON Processing           │   │
│ │ • Transaction Data  │      │ • Business Logic            │   │
│ └─────────────────────┘      └─────────────────────────────┘   │
│           │                              │                     │
│           ▼                              ▼                     │
│ z/OS Virtual Storage              64-bit Address Space         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
				
			

Stratégies THREADSAFE et optimisation TCB

La programmation THREADSAFE est cruciale pour éviter les basculements coûteux entre TCB QR (haute performance) et TCB L8 (mode sérialisé) :

				
					* === IMPACT THREADSAFE SUR LA MÉMOIRE ===
┌─────────────────────────────────────────────────────────────────┐
│              COMPARAISON TCB QR vs L8                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ THREADSAFE Program (TCB QR)    Non-THREADSAFE (TCB L8)        │
│ ┌─────────────────────────┐    ┌─────────────────────────────┐ │
│ │ • Shared Working Storage│    │ • Private Working Storage   │ │
│ │ • Concurrent Execution  │    │ • Serial Execution          │ │
│ │ • Optimal Memory Usage  │    │ • Higher Memory Overhead    │ │
│ │ • Fast Task Switch      │    │ • Slow Task Switch          │ │
│ └─────────────────────────┘    └─────────────────────────────┘ │
│            │                              │                   │
│ Performance: 100%               Performance: 35-50%            │
│ Memory: Optimal                Memory: +200% overhead          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

* Programme optimisé THREADSAFE
IDENTIFICATION DIVISION.
PROGRAM-ID. OPTMIZED-THREADSAFE.
CBL THREADSAFE

DATA DIVISION.
WORKING-STORAGE SECTION.
* ATTENTION: Variables WS partagées entre executions !
01  WS-CONSTANTS.
    05  MAX-CUSTOMERS           PIC S9(5) COMP VALUE 10000.
    05  RECORD-LENGTH           PIC S9(5) COMP VALUE 500.

* Variables locales dans LINKAGE (non partagées)
LINKAGE SECTION.
01  LOCAL-WORK-AREA.
    05  LWA-CUSTOMER-ID         PIC X(10).
    05  LWA-COUNTER             PIC S9(9) COMP.
    05  LWA-TIMESTAMP           PIC S9(15) COMP-3.

PROCEDURE DIVISION USING LOCAL-WORK-AREA.
THREADSAFE-PROCESSING.
    * Chaque tâche obtient sa propre copie LINKAGE
    EXEC CICS ASKTIME ABSTIME(LWA-TIMESTAMP) END-EXEC
    
    * Éviter absolument les variables globales partagées
    * MOVE ZERO TO WS-COUNTER  <- DANGEREUX: race condition!
    MOVE ZERO TO LWA-COUNTER   * OK: local à cette exécution
    
    PERFORM BUSINESS-LOGIC USING LOCAL-WORK-AREA.

* === DIAGNOSTIC THREADSAFE ISSUES ===
* Messages typiques lors de basculement TCB:
* DFH0120I Task switched to L8 mode - non-threadsafe program
* DFH0121W Performance degradation due to TCB switching
				
			

Monitoring et outils professionnels IBM

L'arsenal complet de monitoring mémoire pour l'ingénieur CICS expérimenté :

				
					* === COMMANDES CEMT AVANCÉES ===
* Monitoring temps réel détaillé
CEMT INQUIRE STORAGE                    * Vue d'ensemble
CEMT INQUIRE STORAGE(DSA) DETAIL        * Détails DSA
CEMT INQUIRE STORAGE(EDSA) CUSHION      * État cushion EDSA
CEMT INQUIRE PROGRAM(ALL) RESIDENCY     * Programmes résidents
CEMT INQUIRE TRANSACTION(ALL) STORAGE   * Usage par transaction

* === IBM OMEGAMON FOR CICS ===
* Dashboard typique Omegamon
┌────────────────────────────────────────────────────────────────┐
│  IBM Omegamon for CICS - Memory Dashboard  14:35:42           │
├────────────────────────────────────────────────────────────────┤
│ DSA Usage Trend:     [████████████████████▓▓▓] 87%  (17.4MB)  │
│ EDSA Usage:          [██████████████▓▓▓▓▓▓▓▓▓▓] 64%  (40.9MB)  │
│ Storage Violations:  [                      ] 0    (Perfect)  │
│ SOS Conditions:      [                      ] 0    (Stable)  │
│                                                                │
│ Top Memory Consumers:                                          │
│ 1. CUSTINQ    2.3MB  (15,432 calls)                          │
│ 2. PAYPROC    1.8MB  (8,765 calls)                           │
│ 3. REPORTS    1.2MB  (234 calls)                             │
│                                                                │
│ Alerts: 🟡 DSA trending upward (predicted full: 16:45)       │
└────────────────────────────────────────────────────────────────┘

* === CICS PERFORMANCE ANALYZER ===
* Rapport automatisé CPA
Memory Analysis Report - CICSPROD
Generated: 2025-09-12 14:30:15
═══════════════════════════════════════════════
Peak Memory Usage Analysis:
• 10:15 - DSA peaked at 94.2% during batch window
• 14:22 - EDSA stress test: 89.7% utilization
• 16:45 - Memory efficiency optimal: 97.3%

Program Residency Recommendations:
✓ CUSTINQ (15.2K calls) - Keep RESIDENT
✓ PAYPROC (8.8K calls)  - Keep RESIDENT  
⚠ REPORTS (234 calls)   - Consider NON-RESIDENT (-1.2MB)
❌ YEAREND (12 calls)    - Set NON-RESIDENT (-2.1MB)

Projected Savings: 3.3MB memory (16% reduction)
				
			

Anti-patterns et pièges courants

Les erreurs fréquentes qui dégradent les performances mémoire et leur résolution :

				
					* === ANTI-PATTERNS MÉMOIRE CICS ===

❌ ANTI-PATTERN 1: Allocation massive sans libération
WRONG-MEMORY-PATTERN.
    PERFORM VARYING COUNTER FROM 1 BY 1 UNTIL COUNTER > 10000
        EXEC CICS GETMAIN
            SET(ADDRESS OF TEMP-BUFFER(COUNTER))
            LENGTH(1024)
        END-EXEC
        * PROBLÈME: Jamais de FREEMAIN correspondant !
    END-PERFORM.

✅ PATTERN CORRECT: Gestion disciplinée
CORRECT-MEMORY-PATTERN.
    EXEC CICS GETMAIN
        SET(ADDRESS OF WORK-BUFFER)
        LENGTH(REQUIRED-SIZE)
    END-EXEC
    
    PERFORM BUSINESS-PROCESSING
    
    EXEC CICS FREEMAIN
        DATA(WORK-BUFFER)
    END-EXEC.

❌ ANTI-PATTERN 2: Variables non-THREADSAFE partagées
* DANGEREUX dans programme THREADSAFE
WORKING-STORAGE SECTION.
01  SHARED-COUNTER      PIC S9(9) COMP VALUE ZERO.

PROCEDURE DIVISION.
    ADD 1 TO SHARED-COUNTER  * Race condition !

✅ PATTERN CORRECT: Variables locales
LINKAGE SECTION.
01  COMMAREA.
    05  LOCAL-COUNTER    PIC S9(9) COMP.

PROCEDURE DIVISION USING COMMAREA.
    ADD 1 TO LOCAL-COUNTER  * Safe !

❌ ANTI-PATTERN 3: Programmes mal dimensionnés
* Programme RESIDENT de 5MB utilisé 3 fois/jour
DEFINE PROGRAM(BIGPROG) RESIDENT(YES)  * Gaspillage !

✅ PATTERN CORRECT: Résidence basée sur fréquence
* Seuil décision: fréquence × coût_chargement > coût_mémoire
IF DAILY-CALLS > 200
    SET PROGRAM-RESIDENT TO TRUE
ELSE
    SET PROGRAM-RESIDENT TO FALSE
END-IF.
				
			

Stratégies de modernisation progressive

Roadmap d'évolution de l'architecture mémoire vers les standards modernes :

				
					* === ROADMAP MODERNISATION MÉMOIRE ===
┌─────────────────────────────────────────────────────────────────┐
│            ÉVOLUTION ARCHITECTURE MÉMOIRE CICS                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ Phase 1: Optimisation Legacy    Phase 2: Hybridation          │
│ ┌─────────────────────────┐    ┌─────────────────────────────┐ │
│ │ ✓ STGPROT activation    │    │ ✓ JVM Server integration   │ │
│ │ ✓ LSR Pool optimization │    │ ✓ REST/JSON services       │ │
│ │ ✓ THREADSAFE migration  │    │ ✓ 64-bit heap management   │ │
│ │ ✓ Program residency     │    │ ✓ Container support        │ │
│ └─────────────────────────┘    └─────────────────────────────┘ │
│                                                                 │
│ Phase 3: Full Modernization                                    │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ✓ Cloud-native integration                                  │ │
│ │ ✓ Kubernetes orchestration                                  │ │
│ │ ✓ Multi-language runtime                                    │ │
│ │ ✓ Event-driven architecture                                 │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

* === CHECKLIST AUDIT MÉMOIRE ===
Memory Audit Checklist for CICS Production Environment
═══════════════════════════════════════════════════════

🔍 Configuration Audit:
 ☐ STGPROT=YES activated for corruption detection
 ☐ Storage areas sized based on workload analysis  
 ☐ CUSHION parameters set (recommended: 5-10%)
 ☐ LSR pools configured for high-frequency files
 ☐ Program residency aligned with call frequency

🔍 Performance Audit:
 ☐ THREADSAFE compliance > 90% of programs
 ☐ Memory fragmentation < 5%
 ☐ SOS conditions = 0 in last 30 days
 ☐ Storage violations = 0 detected
 ☐ Peak usage < 85% of maximum capacity

🔍 Monitoring Audit:
 ☐ SMF 110 records collected and analyzed
 ☐ OMEGAMON/CPA dashboards configured
 ☐ Automated alerting for memory thresholds
 ☐ Regular trend analysis performed
 ☐ Capacity planning updated quarterly

🔍 Modernization Readiness:
 ☐ JVM Server memory requirements assessed
 ☐ 64-bit storage capacity planned
 ☐ Java heap sizing calculated
 ☐ REST service memory impact evaluated
 ☐ Container integration roadmap defined
				
			

Bonnes pratiques avancées de gestion mémoire

THREADSAFE obligatoire : Programmer systématiquement en THREADSAFE pour optimiser l'usage mémoire et éviter les basculements TCB coûteux.

Monitoring SMF proactif : Analyser quotidiennement les records SMF 110 avec IBM OMEGAMON ou CICS Performance Analyzer.

LSR pour fichiers critiques : Configurer des pools LSR pour tous les fichiers VSAM haute fréquence (>1000 accès/jour).

STGPROT=YES en production : Activer la protection mémoire malgré le léger surcoût (2-3%) pour détecter les corruptions.

Fragmentation surveillance : Maintenir la fragmentation sous 5% par des analyses régulières et du compactage préventif.

Residency intelligente : Baser les décisions de résidence sur des métriques (seuil: ~200 appels/jour selon taille programme).

SDT pour données référence : Utiliser les Shared Data Tables pour éliminer les I/O répétitifs sur données statiques.

64-bit pour modernisation : Planifier l'usage 64-bit pour Java/REST services et applications conteneurisées.

SOS prevention : Configurer des cushions appropriés (5-10%) et des alertes préventives à 80% d'usage.

Audit régulier : Effectuer un audit mémoire trimestriel avec checklist complète et ajustements proactifs.

Tags:
Écrire un commentaire

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.