- z/OS file structures
- DFSMS on z/OS
- Data Class
- Management Class
- Storage Class
- Storage Group
- ACS routines
- z/OS file utilities
- z/OS SMF statistics
- z/OS RMF reporting
ACS routines are used to assign the 4 SMS classes to datasets, tapes or objects. These routines can interrogate a number of read-only variables such as &DSN (datasetname) and &JOB (job name) then use that info to decide what values to assign to the 4 read-write variables &DATACLAS &MGMTCLAS &STORCLAS &STORGRP.
The four ACS routines are processed in the order DATACLAS - STORCLAS - MGMTCLAS - STORGRP. If a data allocation is redriven from DFHSM or DFDSS then it can go straight to the STORCLAS routine. If an allocation is not to be SMS managed then it will exit at the STORCLAS routine with the &STORCLAS variable set to NULL. Once the STORGRP is assigned, SMS goes on to select the allocation volume.
You will store your base ACS routines in a PDS, and its name will be unique to your site. The ACS routines are split into two sections, the first section combines lists of files and objects together, the second section contains the code which processes those lists. The ACS routines are processed every time a dataset is allocated, so SMS can be a big CPU user. However, SMS uses cross-memory services, so the CPU is not allocated to the SMS address space, but is passed over to the address space of the requesting user. This means that its difficult to determine just how much CPU SMS is using. CPU is expensive, so
WHEN (&DSN = &HSMCDS) DO
SET &MGMTCLAS = 'CONCCOP'
WHEN (&DSN = &SYSTEM) DO
SET &MGMTCLAS = 'NOMGMT'
SET &MGMTCLAS = 'DEFAULT'
END /* OF SELECT */
To make changes to your ACS routines follow the process below.
As DFSMS is now old and well established software, the biggest challenge is probably that ACS routines have mutated over the years and have become difficult to understand and change. This is especially true if your company has gone through a few mergers and several different SMS systems have been welded together. Two fundamental issue are, how do you debug SMS routines when something has gone wrong, and how can you safely change them when necessary.
One suggestion from IBM is to analyse each routine and produce a spreadsheet 'map' which shows ACS class names going down the sheet, and ACS variable names across the sheet, so you can see at a glance which variable values cause a given class name to be used. If you go to the trouble of setting up such a map, the issue then is that everyone who makes changes to the routines must update the map, or it becomes invalid.
A simple tip for debugging issues is to work backwards from the problem. If your dataset is getting the wrong management class, scan the mgmtclas routine and find the SET statements which allocate that class, there may be more than one. Once you find the SET statement, work out which variables and filtlists trigger that SET statement, then check exactly what parameters are used when allocating the file. Hopefully you will then understand why you are getting that management class. Now you need to work out what combinations of ACS variables and filtlists would be required to pick up the correct management class. You can probably see now how that spreadsheet map would make your life easier.
If you need to update an existing complex routine, always work from a copy. Try to understand how the original author's logic style worked and if possible use the same logic style yourself. Different styles within the same routine can be very confusing. A logic map can be very useful. Use comments to explain what you have done, you won't remember yourself in 3 months time. Once you have made the change, test, and test again before making the change live.
DO NOT put a simple catch all statement at the start of the routine that guarantees that your new allocation will work, not even just to test something. I once saw an experienced person do this and then direct all new allocations to tape. All tape drives were in use within seconds and the master console was flooded with 'no drives available' messages. All new dataset allocations hung and the systems ground to a halt. It took 2 minutes to backout the change, but freeing up the console took a lot longer.
back to top