The CHANGE function is used to alter the storage class, management class, or retention period for previously stored objects. A new storage class name, a new management class name, or a new retention period can be specified. Any combination is valid. The specified change is made to the object directory table immediately. The syntax diagram for the OSREQ CHANGE function follows.

Syntax for OSREQ CHANGE

>>-OSREQ CHANGE------------------------------------------------->

>--+-------------------------------------------+---------------->
   '-MF=-+-L---------------------------------+-'   
         +-(M,parameter_list-+-----------+-)-+     
         |                   '-,COMPLETE-'   |     
         '-(E,parameter_list-+-----------+-)-'     
                             '-,COMPLETE-'         

>--+-------------------------------------+---------------------->
   |       (1)                           |   
   '-TOKEN----=-+-token_area-----------+-'   
                '-(token_area_pointer)-'     

>--+--------------------------------------------------+--------->
   |          (1)                                     |   
   '-COLLECTN----=-+-collection_name_area-----------+-'   
                   '-(collection_name_area_pointer)-'     

>--+------------------------------------------+----------------->
   |      (1)                                 |   
   '-NAME----=-+-object_name_area-----------+-'   
               '-(object_name_area_pointer)-'     

>--+------------------------------------------------+----------->
   |          (2)                                   |   
   '-STORCLAS----=-+-storage_class_area-----------+-'   
                   '-(storage_class_area_pointer)-'     

>--+---------------------------------------------------+-------->
   |          (2)                                      |   
   '-MGMTCLAS----=-+-management_class_area-----------+-'   
                   '-(management_class_area_pointer)-'     

>--+-----------------------------------------------+------------>
   |       (2)                                     |   
   +-RETPD------=--+-retention_period-----------+--+   
   |               '-(retention_period_pointer)-'  |   
   |          (3)                                  |   
   '-EVENTEXP------=--+-number_of_days-----------+-'   
                      '-(number_of_days_pointer)-'     

>--+---------------------------+-------------------------------->
   |         (4)               |   
   '-DELHOLD----=-+-HOLD-----+-'   
                  '-(NOHOLD)-'     

>--+-------------------------------------+---------------------->
   '-MSGAREA=-+-message_area-----------+-'   
              '-(message_area_pointer)-'     

>--+------------------------------------+----------------------->
   '-RETCODE=-+-return_code-----------+-'   
              '-(return_code_pointer)-'     

>--+------------------------------------+----------------------->
   '-REACODE=-+-reason_code-----------+-'   
              '-(reason_code_pointer)-'     

>--+--------------------------------------+--------------------><
   '-TTOKEN=-+-tracking_token-----------+-'   
             '-(tracking_token_pointer)-'     

1. These keyword parameters must be specified on at least one of the forms if the MF=E does not indicate COMPLETE.
2. These keyword parameters result in object's pending action date set to current date.
3. The EVENTEXP keyword cannot be issued in the same statement as the RETPD keyword. Also, EVENTEXP is valid only if the object is in event-based-retention mode (for example: the expiration date is 0002-02-02 as a result of RETPD=-2 (X'FFFFFFFE') being specified on a previous STORE or CHANGE request). If EVENTEXP is specified on a CHANGE request when the expiration date is anything other than 0002-02-02, the CHANGE request fails.
4. The DELHOLD keyword issued without any type (2) keywords will not result in ACS routines run or pending action date set.

As a result of an OSREQ CHANGE, the last referenced date and pending action date of an object are updated to the current date. Because the pending action date is updated, changed objects are scheduled for action during the next storage management cycle. During that cycle, an object may be placed in a different level of the object storage hierarchy to meet a new performance objective. Thus, a new storage class assignment becomes effective during that storage management cycle.

If storage class is specified without management class, the ACS routines either confirm or override the requested storage class assignment. The resulting storage class assignment may be the previously assigned storage class, the requested storage class, or another storage class as determined by the ACS routines. After determining the storage class, the ACS routines determine whether a change in management class is also needed.

If storage class and management class are both specified, first the ACS routines either confirm or override the requested storage class assignment and then process the management class. In a method similar to storage class processing, the ACS routines either confirm or override the requested management class assignment. The resulting management class assignment may be the previously assigned management class, the requested management class, or another management class determined by the ACS routines.

If management class is specified without storage class, the ACS routines either confirm or override the requested management class assignment, resulting in assignment of the previous management class, the requested management class, or another management class. The storage class is not affected.

The new management class values obtained through ACS routine processing become the basis for retention period processing.

See Expiration date processing for more information.