Navigation Bar

OS/390 System Managed Storage

DFDSSSMS is a policy based storage management system used by IBM mainframes. These pages will not tell you everything about DFSMS, there are plenty of IBM manuals out there. What they will give you, is a general introduction, then some hints and tips on how to make SMS work.

SMS can decide what files look like, when they migrate between various types of storage, what type of performance they should get and what storage they are initially allocated to. These policies are determined by four constructs, the Data Class, Management Class, Storage Class and Storage Group. Each of these constructs are detailed in the four sub-pages. To change the constructs, you need to use ISMF, and to attach constructs to files, you need to use ACS routines. The following two sections discuss these in general terms

ISMF

The Interactive System Management Facility is an ISPF menu driven application used to control SMS. You site will probably have ISMF as a menu item somewhere, but the TSO command TSO ISMF seems to work everywhere. The first time you use ISMF you will see a restricted panel like

 Select one of the following options and press Enter:                  
    
 0  ISMF Profile            - Change ISMF User Profile                  
 1  Data Set                - Perform Functions Against Data Sets         
 2  Volume                  - Perform Functions Against Volumes           
 3  Management Class        - Specify Data Set Backup and Migration Criteria
 4  Data Class              - Specify Data Set Allocation Parameters       
 5  Storage Class           - Specify Data Set Performance and Availability
 9  Aggregate Group         - Specify Data Set Recovery Parameters       
 L  List                    - Perform Functions Against Saved ISMF Lists 
 R  Removable Media Manager - Perform Functions Against Removable Media  
 X  Exit                    - Terminate ISMF                          

Most people have been using SMS for so long, they forget that if new users want to see the full Storage Users menu list, you must take option '0', then option '0' again to change the user mode. You will then see a panel like

Specify the following:                                                
                                                                      
  User Mode  . . 1    (To specify your choice of session, type in a:
                                                                      
                         1 For an End User (EU)
                         2 For a Storage Administrator (SA)
           
                       in the User Mode Field and Press Enter to 
                       Verify Your Selection.)

change your user mode to '2 For a Storage Administrator (SA)', press enter, then use PF3 until you get right out of ISMF. Go back in again, and you will see the full set of options. Most sites restrict access to this, either by restricting access to the change user panel (DGTDPPF5) with RACF, or with some local coding.

So what does ISMF do? Most of the options are self explanatory, and have good help screens behind them. Options 1 and 2 are used to report on datasets and volumes. Options 3-6 are used to change the SMS constructs, details of this are in the construct subpages.

Option 7 is used to manage the ACS routines, the menu system should be easy to follow, and will be discussed a bit in the next section. A couple of tips are;
When you translate or validate the ACS routines, you have to specify the output file for the messages. When you come out of the validation page, you get a message.

 Specify Output Listing Disposition:
 
   Enter "/" to select option      Print Output Listing
                                   Delete Output Listing

Its always best to select the Delete option. Why? Because it will probably be a few months before you do this again. By then, your output listing file will have migrated off to tape, and your screen will be locked up while you wait for it to come back.

The display option will tell you who last updated each of the four routines. This is useful when things go wrong, especially if it wasn't you.

Option 8 is used to manage the control datasets. Your control datasets are defined in SYS1.PARMLIB(IGDSMS00) If you are not using the default '00' IGDSMS member, the actual member will be set in the ID Member in SYS1.PARMLIB(IEFSSN00)

SUBSYS SUBNAME(SMS)
  INITRTN(IGDSSIIN)
  INITPARM('ID=00,PROMPT=DISPLAY')
 

ACS routines

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

  • Keep the ACS routines simple
  • Put popular hits at the front of the code
  • If you have SMS compatible dataset names, you can keep your filtlists simple by using dataset name patterns. If you are replacing an older system, or introducing a new one, use the opportunity to influence the naming standards to make them SMS friendly. Its not a good idea to go to the expense of renaming all your files just to fix SMS.
  • Select ... When ... Otherwise statements are easier to write and understand, than nested If .. then .. else .. statements. Remember to code EXIT statements at the end of every WHEN clause, or everything will default to the otherwise clause.
    SELECT  
       WHEN (&DSN = &HSMCDS) DO
          SET &MGMTCLAS = 'CONCCOP
          EXIT
       END
    
       WHEN (&DSN = &SYSTEM) DO
          SET &MGMTCLAS = 'NOMGMT'
          EXIT 
       END 
       OTHERWISE  DO 
          SET &MGMTCLAS = 'DEFAULT'
          EXIT
       END
                                                                            
     END       /* OF SELECT   */
    

Finally, naming standards for SMS constructs. There are two opposing views here, and both have their merits.

  1. Make the naming standards meaningful, then you can tell what the construct does by its name. For example, you want a production management class which stays on primary disk for 7 days unused, migrates to ML1 for 10 days, then goes to ml2 for 2 years (or 730 days). A possible name for the management class is P071002Y. You can easily work out from the name exactly what that management class does. However, if you decide you want to change it to stay on ML1 for 20 days, you need to change the name, then run IDCAMS ALTERS to bind all existing files to the old name.
  2. Make the naming standards vague, and use ISMF to find out what they do. So you could call the above management class M0000001. The name means absolutely nothing, and you can change the attributes at will, without any issues.

Which is best? I like names which have some meaning, but there are times when too much meaning is a bad idea. For management classes, I would probably go for something like PRYEAR2, which simply means the file gets deleted after 2 years non-use, and the rest of the migration timings can be changed without affecting the name. Data classes are almost fixed by definition, so I'd probably make the dataclasses names meaningful. Storage classes can also be meaningful, while storage groups are usually a mixture of specific and general purpose, so the names should reflect that mixture.

back to top


By entering and using this site, you accept the conditions and limitations of use

 

 

 

Advertising banner for Lasconet