If you are running on z/OS 2.5 or above, you can issue the "JCS" action against the row on the "CSR" panel and that will show each individual block of common storage which you can then browse using the "S" action.
This will allow you to see if you recognize the contents of the block. It is very possible that IBM z/OS services your code is invoking are obtaining common storage on your behalf and the amount and contents of these blocks are not immediately obvious. SDSF get the information for the CSR panel from the CAUB control blocks created by VSM common storage tracking in response to DIAGxx statement "VSM TRACK CSA(ON) SQA(ON)" The JCS action analyses the GQE control blocks that describe each allocated block of common storage. Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of esst...@juno.com Sent: Sunday, March 17, 2024 3:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF CSR EXTERNAL EMAIL , 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
