Skip to main content

 
IBM Power Systems software  >  IBM i  > Support and services  > 

TSM tips

  
Overview Lotus Server Backups GUI TSM Support


Set up policies for the BRMS Application Client at the TSM
Use the maximum buffer size to improve performance
Use multiple concurrent control groups to improve performance
Use passwordaccess generate to automate TSM password management
Set up to utilize retention protection

Set up policies for the BRMS Application Client at the TSM server

Concepts

The TSM STANDARD management class does not provide the most efficient use of TSM server storage when used with the BRMS Application Client. This is because BRMS stores each saved iSeries object under a unique name. A second backup of the same object again uses a unique name. From an TSM server perspective, each of these iSeries objects are considered active because of the unique names. Thus, TSM server versioning does not play a role in BRMS Application client object retention, since TSM always saves active versions of objects. BRMS explicitly deletes TSM stored objects when these expire in the BRMS database. The retention is governed by BRMS Media policies. TSM server copygroup retentions are not used. Thus when BRMS expires an object and deletes it from the TSM server, the TSM server in turn will delete it from TSM storage during the next inventory expiration process.

Recommendation

You should consider using the following TSM administrative commands to create and enable a new TSM domain and TSM management class for BRMS use. This assures that the TSM server expires objects soon after these are deleted by BRMS.

 BRMS will be the management class name that is used by the BRMS Application Client.

DEFine DOmain BRMS DESCription='Domain for BRMS Application Clients' BACKRETention=365 ARCHRETention=0

DEFine POLicyset BRMS BRMS DESCription='Policy set for BRMS Application Clients'

DEFine MGmtclass BRMS BRMS BRMS DESCription= 'Management class for BRMS Application Clients'

DEFine COpygroup BRMS BRMS BRMS STANDARD Type=Backup DESTination=storage-pool-name VERExists=1 VERDeleted=0 RETExtra=0 RETOnly=0

ASSign DEFMGmtclass BRMS BRMS BRMS

ACTivate POlicyset BRMS BRMS

Register Node node-name password DOmain=BRMS COMPression=N0 BACKDELete=Yes

Additional considerations

Archive operations by the BRMS Application Client store objects in the TSM server backup storage pool. If you do not want TSM server backup storage used for BRMS archive operations, you need to create a second management class and specify this management class on the BRMS Media Policies used for BRMS archive operations.



Use the maximum buffer size to improve performance

Concepts

The BRMS Application Client transfers save and restore data in one megabyte blocks. The TSM Application Programming Interface ( TSM APIs) sends data to and receives data from the TSM server as requested by the BRMS Application Client. The TSM API default buffer size for these data transfers is 64 kilobytes for TCP/IP. The TSM API buffer size should be set to the maximum value to minimize the number of calls the TSM APIs make to transfer the data across the network.

Recommendation

Data transfer rates improved when the TSM API buffer size was increaded to 512 kilobytes.

Change this parameter value as follows:

 

  • Enter the command WRKDEVBRM
  • On the Work with Devices display, enter option 2 (change) beside the device name for the TSM server (Category * NET).
  • On the Change Net Device display, change the value of the  Buffer size parameter to 512.
                  Change Net Device



Net device  . . . . . :   TSMSERVER

  

Type changes, press Enter.

  

Text  . . . . . . . . .   Created by TSM Administrator

  

Location  . . . . . . .   TSMSERVER  Name, F4 for list

 

TSM file space . . . .   *LCL

 

Buffer size . . . . . .   512         *DEVTYPE, 1-512 KB

 

Internet address  . . .   1.2.3.4

Internet port . . . . .   1500        1-65534

Additional considerations

Support for the 512 kilobyte buffer size was introduced with Version 4.1 of the TSM APIs. PTF SF53289 is required for Version 4.1 of the TSM APIs to support the larger buffer size.

The data transfer buffer size for * APPC type devices is limited to a maximum of 31 kilobytes. If additional performance is required, consider changing the protocol from APPC to TCP/IP.

Use multiple concurrent control groups to improve performance

Concepts

Assumming there is adequate bandwidth on the network and at the TSM server, the BRMS Application Client can be used to establish multiple concurrent sessions with the TSM server when saving iSeries data. This does not require additional TSM user licenses. TSM allows multiple connections of a registered user under a single user license. Testing has demonstrated that as many as eight TSM sessions can be run concurrently without running into iSeries or BRMS resource contention problems.

How To Set It Up

Setting up the BRMS Application client for multiple concurrent sessions does not require additional media policies, or devices, or locations. It does require the entries in the backup control group to be split into multiple backup control groups and these control groups scheduled for batch processing at the same time. The steps to setup this up are as follows:

 

  1. Enter WRKCTLGBRM to get to the Work with Backup Control Groups display and locate the the backup control group being used to store user data to TSM.
  2. Use option 3 (Copy) on this backup control group to copy the attributes entries into a new control group.
  3. Use option 2 (Edit entries) to remove any backup items that will be included in other backup control groups.
  4. Press F3 and select option 1 (Save and exit session) to save the changed entries.
  5. Repeat steps 2-4 to create additional backup control groups as required.
  6. Use option 6 (Add to schedule) to schedule each of these backup control groups to start at or about the same time.

Recommendations

  • If * LINK is a backup control group entry, consider moving this entry into a seperate control group.
  • If there are any list entries of type * LNK , consider moving these entries into a seperate control group.
  • If * ALLDLO or * DLOnn are backup control group entries, consider moving these entries into a seperate control group.
  • If there are any list entries of type * FLR , consider moving these entries into a seperate control group.
  • If there are any list entries of type * SPL , consider moving these entries into a seperate control group.
  • If * ALLUSR is a backup control group entries, try the above alternatives first, because breaking this entry into multiple control groups requires the libraries be specified in the new control groups using generic library names. For example:
  • One control group could be created with library name entries for libraries starting with the entries  A* through  H* as follows:

             Backup     
    
    Seq      Items      
    
                       
    
      10     A*         
    
      20     B*         
    
      30     C* 
    
      40     D*
    
      50     E*         
    
      60     F*         
    
      70     G* 
    
      80     H*
    

    A second control group could be created with library name entries for libraries starting with the entries  I* through  P* .

    And a third control could be created with library name entries for libraries starting with the entries  R* through  Z* for the third control group.

Additional considerations

If you split a library into multiple control groups and one control group finishes processing significantly faster than the other control groups, consider moving more entries into the smaller control group.



  Use passwordaccess generate to automate TSM password management 

Concepts

If you have installed Version 4.2 of the Tivoli Storage Manger Application Programming Interface for iSeries, you can use the PASSWORDACCESS GENERATE client option to have new TSM passwords automatically created by TSM when the current passwords expire. You need to perform the following actions to enable this function in the BRMS client.

How To Set It Up

  1. Create a source physical file named QA1AGENPWD in the QUSRBRM library with a member named NODENAMES using the following command:

    CRTSRCPF FILE(QUSRBRM/QA1AGENPWD) RCDLEN(92) MBR(NODENAMES)

  2. Change the owner of file QUSRBRM/ QA1AGENPWD to QBRMS using the following command:
  3. CHGOBJOWN OBJ(QUSRBRM/QA1AGENPWD) OBJTYPE(*FILE) NEWOWN(QBRMS)
  4. Revoke current public authorities to file QUSRBRM/ QA1AGENPWD using the following command:

    RVKOBJAUT OBJ(QUSRBRM/QA1AGENPWD) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*ALL)

  5. Grant * USE public authority to file QUSRBRM/ QA1AGENPWD using the following command:

    GRTOBJAUT OBJ(QUSRBRM/QA1AGENPWD) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*USE)

  6. Use STRSQL and add a record for each node name which you want enabled for PASSWORDACCESS GENERATE using the following SQL command.

    INSERT INTO QUSRBRM/QA1AGENPWD (SRCDTA) VALUES('node-name')

The inserted node names must follow these rules:

  • Each node name must match the node name used in the media policy.
  • Enter only one node name for each record.
  • Left justify the node name in the record.
  • Use upper case when entering the node name.

Recommendations

The TSM created passwords are stored in file /etc/adsm/ TSM.PWD unless you have changed the DSMI_DIR environment variable to specify some other directory. To simplify recovery, make assure this file is backed up regularly to tape media.

Additional considerations

When the BRMS TSM client requires a connection to the TSM server, BRMS checks for the existance of file QUSRBRM/ QA1AGENPWD and then attempts to locate the node name from the current media policy in the NODENAMES member. If the node name is found, BRMS will submit the PASSWORDACCESS GENERATE client option when it starts the session with the TSM server. The automatic password management is under the control of the TSM APIs and the TSM server. BRMS does not manage the passwords when the PASSWORDACCESS GENERATE client option is used.

  Set up to utilize retention protection 

The following PTFs provide function for BRMS to store saved objects to Tivoli Storage Manager (TSM) servers which have been enabled for retention protection.

V5R3 SI15309
V5R2 SI15310
V5R1 SI15149

Objects saved using retention protection cannot be deleted from BRMS history or the TSM server until the object expires at the TSM server.

The TSM server uses retention protection if the server status shows "yes" for "Archive retention protection". If you do not know if the TSM server uses retention protection, contact the TSM server administrator.

Version V5R2M2 or later of the Tivoli Storage Manager Application Programming Interface (TSM APIs), program product 5733197, is required to use retention protection.

To enable BRMS to use Tivoli Storage Manager (TSM) servers enabled for retention protection, do the following:

  1. Install this PTF

  2. Install the V5R2M2 or later version of the TSM APIs.

  3. Create a BRMS location, media policy, and device for the TSM server as described in section "Setting up BRMS as a Tivoli Storage Manager Client" in the BRMS
    book, SC41-5345.

  4. After the BRMS device is created, use the Work with Members Using PDM (WRKMBRPDM) or Start Source Entry Utility (STRSEU) commands to edit the options for the device. Specify:

    File or Source file: QA1AOPT
    Library: QUSRBRM
    Member or Source Member: device-name

  5. Insert the following option as the last entry:

    ENABLEARCHIVERETENTIONPROTECTION YES

  6. Save the changes.

The following are some new TSM reason codes which may occur:

 247 DSM_RS_ABORT_INSERT_NOT_ALLOWED 

Occurs if you are trying to store objects on a TSM server enabled for retention protection but TSM client is not using the option of step 5 above.

 248 DSM_RS_ABORT_DELETE_NOT_ALLOWED 

Occurs when you attempt to delete an object from BRMS history that has been saved to a TSM server enabled for retention protection but the object has not yet expired at the TSM server.

Note: It is important that the BRMS retention and TSM server retention match when saving objects to TSM servers enabled for retention protection.
This is required so these objects can be deleted from BRMS history and the TSM server concurrently at expiration.

 400 DSM_RC_INVALID_OPT 

Occurs if you add the option of step 5 above and run a TSM operation using a TSM API level prior to V5R2M2.