|
You can use BRMS to save low-volume user data on distributed iSeries systems to any Tivoli Storage Manager (TSM) server. You can do this by using a BRMS component called the BRMS Application Client, which is provided with the base BRMS product.
The BRMS Application Client has the look and feel of BRMS and iSeries. It is not a TSM Backup or Archive client. There is little difference in the way BRMS saves objects to TSM servers and the way it saves objects to media. A TSM server is just another device that BRMS uses for your save and restore operations.
The BRMS Application Client communicates with TSM servers through a special set of APIs that are referred to as the Tivoli Storage Manager Application Programming Interface for iSeries (TSM APIs).
The BRMS Application Client provides the following benefits for one or more systems at offsite locations:
- You can use BRMS policies to save non-system objects across a network for storage on any server in the TSM family.
- You can reduce the amount of media that is required at the offsite location, thereby increasing the level of backup automation.
- You can reduce the amount of time that is spent managing media.
- You can minimize device purchases on the offsite system.
Following is a list of additional restrictions that are placed on BRMS Application Client operations.
- Save-while-active *SYNCLIB is not supported when saving libraries to TSM servers. When libraries are saved to TSM servers, one save command is used to save each library because OS/400 requires the save to be setup as a save to a save file. The *SYNCLIB value will be ignored if it is specified.
- You cannot save iSeries system data to a TSM server. You must store system data on local media so that it is available for system recovery. This includes security data (*SAVSECDTA) and configuration data (*SAVCFG).
- The BRMS recovery data (SAVMEDIBRM) needs to be saved to tape after every save to the TSM server.
- The profile running the backup requires authority to objects in QUSRBRM library. If the user profile does not have *ALLOBJ authority, one of the following commands needs be run:
- GRTOBJAUT OBJ(QSYS/QUSRBRM) OBJTYPE(*LIB) USER(*PUBLIC) AUT(*ADD)
- GRTOBJAUT OBJ(QSYS/QUSRBRM) OBJTYPE(*LIB) USER(xxxxxx) AUT(*OBJOPR *READ *EXECUTE *ADD)
- Any user data that you can save to a save file, you can save to a TSM server except user data required to restore OS/400 to a functional level. This includes, security data, configuration data, IBM-supplied libraries, licensed programs, IBM-supplied libraries that are considered user data such as QGPL, QUSRBRM or QUSRSYS, and BRMS media information. These are excluded from save operations to TSM servers because these must be available on local media to recover your system.
- You cannot schedule operations from a TSM server because the TSM APIs do not provide this capability. You can however schedule your BRMS operations at the client using the native OS/400 job scheduler.
- BRMS uses its own media policies to manage the retention and expiration of data that is stored on the TSM server. TSM policies are not used for this purpose.
- Because the save command is processed in a prestart job, job related environments and parameters will not be honored. For example:
- 1) The adopted authority of the thread using the Save to Application (QaneSava) API is not available to the save command. One way to give the prestart job more authority is to use the adopted authority to swap user profiles within the application before calling the QaneSava API.
- 2) If the command be passed to the Save to Application (QaneSava) API uses a parameter to reference the current threads current IASP group, for example ASPDEV(*CURASPGRP), the current threads IASP group may not be available to the save command that is processed in the prestart job.
Email us with any further questions you have on BRMS Application Client to TSM.
Please contact the iSeries and AS/400 Support Line if you are having technical problems with our product.
| 
