, Hello, . Im trying to understand an anomaly using SDSF CSR - (Common Storage Remaining) I have read some of the documentation on SDSF CSR, however it didn't really give me an understand of the issue below - . I have two jobs which invoke the same program from the same load library - Bothe jobs invokes IEFSSI REQUEST=ADD and the SSI INIT ROUTINE is the same for both JOBs. The SSI INIT Routine has multiple CSECTS and issues IEFSSI REQUEST=ACTIVATE (Activate the subsystem), STORAGE OBTAIN (Key 0, Subpool 241, Length x'34'), and IEFSSI REQUEST=PUT (Store Sub System Data). . Granted the Key 0, subpool 241 may not be the best choice form allocating storage from MVS common, that's not the issue for this discussion. .-- In SDSF I see the following in CSR (Common Storage Remaining) - JOBNAME CSA CSA% SQA SQA% ECSA ECSA% JOBNUMA 392 0.0076 0 0.0000 5696 0.0079 JOBNUMB 0 0.0000 0 0.0000 9792 0.0135 .-- When I submit the first job (JOBNUMB) I see in SDSF CSR the job retains 9792 bytes of ECSA and 0.0135% of ECSA. Im not sure where the 9792 bytes of ECSA came from - I suspect the majority of this allocation are various control block structures associated with the SSI - . The storage obtain macro in the INIT Routine acquires X'34' bytes of storage - . However when I submit the second job (JOBNUMA), I see in SDSF CSR, the second job retains 5696 bytes of ECSA and 0.0079% of ECSA. Also JOBNUMA allocated 392 byes of storage from CSA, why? . Both jobs invoke the same program, and the same SSI INIT Routine from the same load library - I expected to see the same ECSA values for both jobs/programs. . Can someone explain why there is such a difference in values? I obviously don't understand this. .. Paul - . .
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
