IBM Security Z Security

Security for Z

Join this online user group to communicate across Z Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Allocation failures with large number of Access Monitor files

    Posted Tue December 10, 2024 10:56 AM

    I am looking at a job failure which attempted to allocate 312 access monitor files.
    The job had the following message, so think the TIOT is as large as it can be.

    IEFA111I JJJJJJJJ IS USING THE FOLLOWING JOB RELATED SETTINGS:
             SWA=ABOVE, TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB

    The failures stated,

    IKJ56220I DATA SET -----REDACTED----- NOT ALLOCATED, TOO MANY DATA SETS+
    IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED BY YOUR SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS.
    There were 257 IGD103I messages for data sets allocated.
    Each dataset has a DATACLAS assigned which specifies Dynamic Volume Count as 59.  I suspect this is the cause of the problem.
    However as I don't know what options are selected on zSecure dynamic allocation text units I cannot be sure.
    For example, is there some way to get zSecure allocation to use the XTIOT?
    Any other suggestions. Changing the DATACLAS of an existing data set seems to not be supported.

    Regards
    Lennie

    P.S. I am also asking questions on IBM-MAIN about this.



    ------------------------------
    Lennie Dymoke-Bradshaw
    Director
    Reverse Sweep Consulting Limited
    BUSHEY
    07504304158
    ------------------------------


  • 2.  RE: Allocation failures with large number of Access Monitor files

    Posted Tue December 10, 2024 11:48 AM
    Edited by Rob van Hoboken Tue December 10, 2024 11:51 AM

    Hi Lennie

    You may want to add a DYNAMNBR parameter on the EXEC command in the JCL,  read here.

    ------------------------------
    Rob van Hoboken
    ------------------------------



  • 3.  RE: Allocation failures with large number of Access Monitor files

    Posted Tue December 10, 2024 12:30 PM

    Rob,

    If you look in IBM-MAIN there are some recent posts with a title of DYNAMNBR to which Scott Ballentine of z/OS Device Allocation has added some really useful info. I am pretty sure I can discount the use of DYNAMNBR to assist in this case.

     

    Regards

    Lennie

     




    Original Message


  • 4.  RE: Allocation failures with large number of Access Monitor files

    Posted Tue December 10, 2024 03:55 PM

    If you're interested in the DYNALLOC options used for the ACCESS data sets, you can add a DEBUG SVC99 command in the CARLa program, or in the SETUP PREAMBLE, see here.



    ------------------------------
    Rob van Hoboken
    ------------------------------

    Original Message


  • 5.  RE: Allocation failures with large number of Access Monitor files

    Posted Wed January 08, 2025 08:45 AM

    Rob,

    After some detailed investigations together with Scott Ballentine there is a useful piece of information with regards to DYNAMNBR. DYNAMNBR only affects those allocations which are marked as in-use. It appears that TSO ALLOCATE (and I suspect, IDCAMS ALLOCATE) mark each allocation as not-in-use after performing the allocation. However, from using the DEBUG SVC99 command in CARLa I can see that zSecure does not do this. This explains why DYNAMNBR affects TSO allocations but not other allocations which ignore the in-use flag.

    This behaviour of TSO ALLOCATE has never been documented as far as we can see. Scott has spoken with TSO development and one person has said that in-use attribute processing was intended to provide a limiting factor for allocations independent of the TIOT size and affecting TSO users only. These days I suspect this is of little use. As I said to Scott, I have never seen a problem in which the solution was to REDUCE the value of DYNAMNBR.

    Regards

    Lennie



    ------------------------------
    Lennie Dymoke-Bradshaw
    ------------------------------

    Original Message


  • 6.  RE: Allocation failures with large number of Access Monitor files

    Posted Tue December 10, 2024 03:34 PM

    Lennie,

    This may be due to having never performed the monthly consolidation (or if the scheduled job no longer runs), and the specification of DSNPREF= in SE.1 is attempting to allocate more data sets than would be allowed (even if DYNAMNBR was increased).   If you have more than one month's daily Access Monitor data sets (suffixed with ".Dyymmdd"), this is an indication the monthly consolidation process has not been performed.

    Have a look at the following documentation about the C2PJCONM (monthly consolidation) if you are finding you have more than one month's worth of Access Monitor data sets.

    https://www.ibm.com/docs/en/szs/3.1.0?topic=monitor-consolidating-data-collected-by-access

    Feel free to open a case if you need further assistance.

    John Young



    ------------------------------
    JOHN YOUNG
    ------------------------------

    Original Message


  • 7.  RE: Allocation failures with large number of Access Monitor files

    Posted Wed December 11, 2024 04:08 AM

    Rob,

    Thanks for that DEBUG hint. I will give it a go to see what the output looks like.

    John,

    The large number of access monitor files represents 9 lpars over a year. It is not to do with a lack of consolidation.

    Everyone,

    I am now convinced that the problem is the Dynamic Volume Count. There is a table in MVS Initialisation and Tuning Reference here,
    https://www.ibm.com/docs/en/zos/2.5.0?topic=defaults-statements-parameters-allocxx 

    This show that the number of allocations I can make with a 64K TIOT and each allocation having 59 volumes is 259. This is my situation.

    So thanks to all who contributed. I think I have my answer. Use a different DATACLAS.

    Lennie



    ------------------------------
    Lennie Dymoke-Bradshaw
    Director
    Reverse Sweep Consulting Limited
    BUSHEY
    07504304158
    ------------------------------

    Original Message


Related Content