Backup Recovery and Media Services

Avoiding database conversion issues in BRMS

In v5r4 and above, conversion issues with the BRMS database can occur, to get around this problem, first run this command:

QSYS/CALL QBRM/Q1AOLD PARM('INSTALL ' 'ALTERTBL ' 'Y' '01' '01' '65535'
'TEXTFLDS ' 'QUSRBRM ' 'N')

If the the conversion errors still occur, run this command:

QSYS/CALL QBRM/Q1AOLD PARM('INSTALL ' 'ALTERTBL ' 'Y' '01' '01' '65535'
'TEXTFLDS ' 'QUSRBRM ' 'Y')

Notes:

1. The job log may contain some database messages about loss of data (example: CPA32B2) or other informational messages (example: CPI3210) which can be ignored.
2. In releases IBM i 7.1 and earlier, this override is available with the following PTFs or their superseding PTFs:
   
   • 7.1 SI41206
   • V6R1M0 SI41205
   • V5R4M0 SI41204

Back to top

Omit IFS directories and files from your *LINK saves

You can use the QLNKOMT user-modifiable backup link list to always omit any IFS directories or files that you do not want included in a *LINK save (for example, the directories that you use for virtual tapes). Just add those directory or file omits to the BRMS-provided QLNKOMT list.

Back to top

Installation time for BRMS

If the size of the QUSRBRM library on your server is large, you could experience long installation times when upgrading BRMS to a newer release. This is due to the conversion of the physical files in the QUSRBRM library to a new file format. The benefits of this conversion are:

• More storage available on your system
• Shorter save times when saving the user libraries on your system
• Less time to save the BRMS media information after each backup.

The physical file conversion occurs during the post processing phase of the primary language install. In V5R3 and above, the impact of this conversion is alleviated somewhat by processing it in a separate batch job, allowing the rest of the system install to continue processing at the same time.

The time required to convert the files in library QUSRBRM will vary depending on the system model, storage configuration and number of records in the physical file in the QUSRBRM library.

Note: When you perform the estimation process below, be sure to emulate the system environment which you plan to use when installing BRMS. The conversion performs best when system activity is minimized.

To estimate the conversion time do the following:

• If you are upgrading from V5R2, run the following command to determine the estimated conversion time.

  		CALL QBRM/Q1ARMLT PARM('ESTCONVTIM')
  		
  

• If you are upgrading from V5R3, run the following command to determine the estimated conversion time.

  		INZBRM *ESTPRDINZ
  		
  

• Review the job log or the BRMS log for the following message:

  		BRM402B: ESTIMATED CONVERSION TIME IS nn HOURS
  		AND nn MINUTES.
  		
  

Back to top

Improve outfile processing performance.

If you save libraries with *YES or *MBR specified in the Retain Object Detail attribute, you can significantly improve BRMS output file processing by following this tip. Output file processing spends a lot of time retrieving member size and member text fields for BRMS save history. If you do not need the member size and member text details (and you have installed SI20411 for V5R3 or SI20410 for V5R2), you can use the following command to disable retrieving those extended member details.

QSYS/CALL PGM(QBRM/Q1AOLD) PARM('RTVEXTMBR' '*NO')

Where parameter 2 may be specified as:
*NO - disable the retrieval of extended member details
*YES - enable the retrieval of extended member details
*DISPLAY - display whether the extended member details are being retrieved

Note: All parameters for this command must be entered in uppercase.

What this means:
By disabling retrieve extended member, BRMS will continue to allow you to drill down to member level detail and restore an individual member. However, the display option for that member on the WRKMEDIBRM screen will display blank for member text and 0 for member size. Object text and object size will continue to show the actual data.

Back to top

Run Maintenance every day!

Make efficient use of your media by running STRMNTBRM daily to expire media, remove history records for expired media, clean up temporary files, move media and manage journal receivers.

Back to top

Reorganize the BRMS data files once a month.

You can significantly lower the size of the BRMS data files by issuing the RGZPFM command. You will gain the most benefit by reorganizing QA1AHS, QA1AOD, QA1AMB, QA1AFD, QA1ALG, QA1AOQ, QA1ADI, QA1ADI2, QA1ALI and QA1ALI2 in QUSRBRM. In V5R2 or later, you can run this function during maintenance by changing the STRMNTBRM RGZBRMDB parameter to *YES. This way you do not have to enter all of the file names.

Note: Ensure that there is no BRMS activity while reorganizing these files.

Back to top

Saving time doing restores

When doing BRMS recoveries, users can use the new SUBMIT TO BATCH function when saves are done in Parallel-Serial mode or there is a need to run multiple restores concurrently to save time.

To use this function, the following needs to be done:

• Put all scheduled jobs on hold. Depending on the job scheduler you use, how to do this will differ.
• CHGJOBQE QBATCH - Change MAXACT and all MAXPTY* parameters to number of concurrent restores to be run and press Enter. These parameters should be reset to the original values when the restore is complete.
• Start QBATCH
• End Q1ABRMNET subsystem if it starts
• Run a STRRCYBRM *SYSBAS *RESTORE , chose the *VOLSET with the first volume, F16 to select, then F14 to submit to batch.
• STRRCYBRM *RESUME and did same for each *VOLSET
• Use WRKSBMJOB to monitor the restores that have been submitted to batch and check for any errors.

Note:

• You will need sufficient tape drives. A minimum of one for each restore job.
• If you have iASPs to recover, you will want to use STRRCYBRM *ASPDEV *RESTORE once they are AVAILABLE.
• Available at V5R4M0 and above

Back to top

IBM i parallel save and restore

Many customers are interested in spreading their backups across multiple drives simultaneously in order to shorten their backup time. The IBM i platform offers several techniques to do this, some of which have special considerations. This article will begin by outlining the various multi-streamed backup options. It will then discuss a situation with referential database constraints where care is required with multi-streamed saves. Finally, the article will delve into each of the three multi-streamed backup options, explaining how to use the save technique, and the best way to restore that type of save.

Overview of techniques for running multi-streamed backups on the IBM i platform
There are three different techniques for running multi-streamed backups on the IBM i platform:

• Concurrent saves
• Parallel-parallel saves
• Parallel-serial saves

Concurrent saves have been available since the early days of the AS/400. They are being used very successfully by many customers around the world, with very few considerations.

Parallel-parallel saves were introduced at V4R4 and were intended for customers who needed to split a single large object across multiple drives. To use them successfully, use Backup, Recovery and Media Services (BRMS) for the save, recover to a system that has access to the BRMS information about the save, and use the same number of drives for the restore as you used for the save.

Parallel-serial saves were introduced at V5R1 by allowing parallel saves to run against special values like *ALLPROD, *ALLTEST, *ALLUSR, *ASP01–*ASP99, *IBM, generics etc. They basically run a set of concurrent saves, but BRMS divides the libraries into the save streams rather than the user. To use parallel-serial saves successfully, use BRMS for the save, and use a special recovery technique to get multiple drives working on the restore simultaneously.

Referential constraints

When a database has referential constraints, there are some scenarios where multi-streamed restores can fail due to seize issues with the various objects related to the constraint. As one object is being restored, the system has a seize lock on it. If a related object is restored at the same time, then the second restore will be unable to get the necessary seize on the first object, and the restore will fail.

For customers who have referential constraints in their databases, there are three ways to work around this issue:

1. Use a single stream recovery rather than a multi-streamed recovery for the libraries that have files involved in the referential constraint
2. If the related objects are all in a single library, and if that library is saved using a save-while-active command, then IBM i is able to handle this situation.
3. If the save is a parallel-parallel save, and the recovery is done with the same number of drives as the save, then IBM i is able to handle the situation. (** Question ... Does this handle both the case where all the related objects are in 1 library, and also when they are in multiple libraries?)

These considerations for customers with referential constraints are in addition to those described in the sections below.

Concurrent saves

For this technique, the user decides how he will allocate the objects among the tape drives. He then issues one command or job for each drive, and the various drives will run independently from one another, e.g.

Drive 1: SAVLIB LIB (A* B* C* .... H*)
Drive 2: SAVLIB LIB (I* J* K* ..... R*)
Drive 3: SAVLIB LIB (S* T* U* .....Z*)
etc

Some tinkering will be required to make the save streams approximately the same size so they will end at approximately the same time. Care must be taken to ensure that all desired objects are included in the save, including libraries that start with non-alphabetic characters, the Document Library Objects (DLO), the Integrated File System (IFS), spoolfiles, etc.

Recovery is fairly simple. The sets of tapes can be restored using the same number of drives or fewer drives, by mounting the tapes and issuing the corresponding restore command. The key consideration on the restore is for customers who have their physical/logical files or their journals/receivers in different libraries: they need to ensure that the files are restored in the proper order, otherwise an error message will occur, and the missed files will need to be restored separately later. Careful planning of the save streams can usually allow the files to be restored in a single pass, even for customers with physicals/logicals and journals/receivers in different libraries.

Parallel-parallel saves

There was a group of customers who needed to shorten their backups, but could not do so with concurrent saves, because their data included a single large object that made up the bulk of the save. In the early days, there was no way to split this object across drives, so that one stream became the limiting factor in shortening the backup window. Adding more drives to the save was no help.

To assist these customers, IBM introduced parallel-parallel saves at V4R4. For a parallel-parallel save, the user issues a single save command, but asks IBM i to run it across multiple drives, e.g.,

SAVLIB LIB(biglib) DEV(*MEDDFN) MEDDFN(biglibdfn)
(where ”biglib” is the library with the large object, and where the “biglibdfn” media definition indicates multiple drives)

Although it is possible to implement this using IBM i commands, it is fairly difficult since media definition files need to be created for both the save and the restore. For example, the media definition for the restore tells IBM i the details of the data on the tapes and the file sequence numbers where the data can be found. Rather than doing this manually, customers are encouraged to use BRMS since it creates the media definition files in the background using the tape exit programs and the file sequence information in the BRMS database. Customers simply tell BRMS how many drives they would like to use for the save or restore, and BRMS handles the rest.

There are three key considerations for restoring this type of save:

1. In order to restore the data, you need access to the BRMS database so the media definition can be created. This is easy for a customer who is restoring an object to a system in the same BRMS network where it was saved, or a customer doing a full system recovery who will re-load his BRMS information as part of the restore. However, it is more difficult to take a parallel-parallel tape to a separate system and try to restore it since the media definition will need to be created manually.
2. When doing the recovery, IBM i will restore all parts of the first library from each tape, then go back and restore all parts of the second library from each tape, and so on. If you have the same number of drives on the restore as you had on the save, then IBM i mounts all the tapes and moves quickly among them and pulls the data off each tape in order. The recovery typically takes 1-2 times as long as the save. However, if the restore is done with fewer drives than the save, then IBM i needs to mount each tape once for each library that is saved on it. Due to all the tape mounts, searches, rewinds, etc this can take a very long time and is likely not practical.
3. As discussed above, using the same number of drives for the save and restore will avoid seize problems when there are referential database constraints.

The net of this is that parallel-parallel saves can be used successfully so long as saves are done with BRMS, restored to a system that has access to the BRMS information, and restored using the same number of drives as the save. As with concurrent saves, customers who have their physical / logical files and journals / receivers in different libraries need to plan their strategies so these objects are restored in the proper order.

Parallel-serial saves
Starting at V5R1, it became possible to specify generics (eg ABC*) and special values like *ALLUSR, *ALLPROD, *ALLTEST, *ASP01-*ASP99, *IBM, generics, etc on a parallel save. This type of save became known as a parallel-serial save since it was a cross between a parallel save and a regular (“serial”) save. It was considered parallel since IBM i decided how to spread the libraries among drives, unlike the concurrent save where the customer decided how to spread the libraries. However, individual objects are not necessarily spread across multiple drives: instead, IBM i uses a round-robin algorithm to allocate the various libraries, one to each drive, working from A-Z.

When you ask for a parallel save, IBM i decides whether to do a parallel-parallel or parallel-serial save, depending on the type of objects to be saved as follows:

• single object - parallel-parallel
• single library - parallel-parallel
• list of libraries - IBM i decides which to do depending on various factors
• generic libraries (eg LIB*) - parallel-serial
• special values (eg *ALLUSR, *ALLPROD) - parallel-serial

The tapes that result from a parallel-serial save have the libraries jumbled on them alphabetically due to the round-robin algorithm. For example, with a 3-drive save, if all the libraries were approximately the same size, the libraries might be spread something like the following:

Tape 1: A-lib, D-lib, G-lib, etc
Tape 2: B-lib, E-lib, H-lib, etc
Tape 3: C-lib, F-lib, I-lib, etc

Now as an aside: as mentioned above, programming convention on the IBM i platform says that customers should try to put their physicals / logicals or their journals / receivers in the same library. In this case, IBM i is able to restore these related files successfully. For customers who need these objects to be in separate libraries, programming convention says to name the libraries alphabetically so that IBM i will restore the base files first and the dependent files second when it does a restore in alphabetical order.

When restoring a parallel-serial save, BRMS tries to follow the above convention by restoring the objects in alphabetical order. Customers are often surprised to learn that regardless of how many drives they ask BRMS to use, the default restore only reads from a single drive at a time as follows:

If a customer asks BRMS to use the same number of drives for the restore as for the save, then the first tape of each set is loaded into each drive. However, IBM i then moves through the drives one by one, restoring the libraries in alphabetical order, such that only one drive is in use at any given time.

If customers ask BRMS to use a single drive for the restore, then IBM i mounts the first tape and restores the first library. BRMS then rewinds/dismounts the first tape and mounts/loads the second tape and restores the second library. This continues, cycling through the tapes one by one until all libraries are restored. Not only is the restore being performed on a single drive, but there are also numerous mount/search/rewind/dismount cycles to wait for.

Since a single-drive restore is typically not practical for customers, a work-around was devised whereby multiple restore jobs are submitted to get multiple drives working simultaneously. At V5R3 and lower, customers need to create these streams manually by carefully selecting the items to be restored. At V5R4, new function was added to the STRRCYBRM screens to make this simpler. Here is a description:

During a recovery, the STRRCYBRM command brings up a screen showing all the objects that are available for restore. This list is in alphabetical order. There are 3 ways to handle this screen:
 

1. If you ask BRMS to go ahead and do the default restore, you will find yourself in one of the situations described above where only a single drive is active on the recovery at a given time.
2. The workaround for V5R3 and earlier releases is to submit the recovery in multiple sections. This needs to be done very carefully. Start by figuring out all the tapes that are in the first set. Then open the STRRCYBRM screen and go down through the list and select all the items that are on that set of tapes, then submit the command for restore. Then go through the list again, and select the items that are on the second set of tapes, and submit them for restore. Continue until all items have been selected from the list.
3. Starting at V5R4, the same technique can be used, but BRMS offers assistance in selecting the items to be restored in each set. On the STRRCYBRM ACTION(*RESTORE) screen that lists the items for restore, there are two selection fields in the top right corner that let you specify *VOLSET and a volume number prior to using the F16=Select key. All saved items that are on the same set of tapes as that volume are marked with a ‘1’. You then use F9 for recovery defaults, and F4 to submit the restore. You then repeat this for each different save stream until all restores have been submitted.

As with concurrent and parallel-parallel saves, customers who have their physicals / logicals and journals / receivers in different libraries, may receive error messages indicating that files could not be restored since their base file was not yet on the system. Operators need to check for these messages and go back and restore the missing files later. Alternatively, it may be possible to plan the save strategy to minimize these concerns, using one of the following techniques:

• Design the save strategy so all traditional libraries are in a single stream, then use the other streams for other items like DLO, IFS, etc. That way the traditional library stream will be on a single drive and will restore in alphabetical order without dependencies between drives
• Design the streams so one stream saves all the dependent files (e.g. logical files and journal receivers). During the recovery, restore that stream last, after all the other streams are already back on the system

The net of this is that parallel-serial saves can be used successfully so long as the special recovery technique is used to get multiple drives running simultaneously during the recovery, and the restore order of physical / logical files and journals / receivers is handled.

Note that parallel-serial saves are very similar to concurrent saves, except that IBM i carves the backup into multiple streams and attempts to have them all finish at the same time based on the round robin algorithm. For customers with data that varies from day to day such that it would be difficult to pre-plan concurrent streams, then parallel-serial saves offer a benefit. However, customers who are able to design their own concurrent streams, may find that concurrent saves are a better strategy due to the simpler recovery prior to V5R4 and less overhead on the system.

Conclusion
Concurrent and parallel saves offer customers options to shorten their backup window. If customers understand the advantages and considerations for each, they can plan a save/restore strategy that will be a good fit for their organization.

(Article by Nancy Roper appeared in the COMMON Connect magazine)

Back to top

Tape library resource status tool

Do you ever want to find out who is using a resource in a tape library that you need?

PTFs SI24433 for V5R4, SI24427 for V5R3 and SI24426 for V5r2 include a helpful tool for customers with the advanced BRMS feature. This is included in the base code V6R1 and above.

This tool will produce a report that displays the users of the resources in a tape library for all systems in a BRMS network that share that library.

To find the tape library resource status for a specific system, issue the following command:

QSYS/CALL QBRM/Q1AOLD PARM('DEVUSESTS ' 'SYSTEM1 SYSTEM2')

Note that the second parameter can specify multiple systems, restricted only by the parameter length of 200 characters.

To find the tape library resource status for all systems in the BRMS network issue the following command:

 QSYS/CALL QBRM/Q1AOLD PARM('DEVUSESTS ' '*NETGRP')

Both of the commands will generate an output file, QTEMP/DEVICELOG, and a printer report, QP1ADEVUSE.

Notes:

1. In order to get status from a particular system, that system must have the appropriate PTF applied and must be in the BRMS network.
2. All characters in the PARM field need to be in capitals (CAPs)

Back to top

Adding steps to recovery report

Starting at V5R4M0, it is now possible to add additional user recovery steps to the BRMS recovery report. User recovery information can be included in the recovery report by adding records containing the information to the appropriate members of file QO1AUSRRCY in library QUSRBRM. Add records to member PROLOG to include user recovery information to the prolog information in the report.

Notes:

1. Add records to members STEP nnn to include user recovery information to specific steps in the report, where nnn is the step number as it appears on the report. Up to 92 bytes of user recovery information can be added to each record. There is no limit to the number of records.
2. User recovery information is added to the report following the BRMS information and before any saved items in the step. This information will be clearly highlighted on the report as user recovery information.
3. Each record is read sequentially from the file member, starting from the first record and ending with the last record, and will be added to the report in the same order as read. Each record will be placed on the report following the last printed line starting in column 8.
4. The user is responsible for all spacing, positioning and translation of the recovery information in each record.
5. The user is responsible for assuring the accuracy of the user recovery information.
6. The step numbers in the report differ depending on the value of the Option (OPTION) parameter and the content of the recovery. If the OPTION or content is changed, the names of the members in file QO1AUSRRCY may need to be renamed accordingly. The step numbers should be consistent if the report type and saved item content are consistent.
7. No exception is signaled if user recovery information is requested but no records are found in the members.
8. When using STRRCYBRM USRRCYINF(*ADD) FROMSYS(), the user steps from the target system will not be included in the recovery report unless the additional steps have being added to the QO1AUSRRCY file in library QUSRBRM. on the system where the recovery report is being run on.
9. STRRCYBRM ACTION(*RESTORE) USRRCYINF(*ADD) will fail with BRM132E

Back to top

Setting Expiration date of duplicate volumes

It is possible to set the expiration date of duplicate volumes to match the expiration date of the original volumes. To do this, users can use the EXPDATE parameter on the DUPMEDBRM command

V6R1M0 and above

Use EXPDATE(*FROMVOL)

In V5R3M0 and V5R4M0

Set the value in the EXPDATE parameter to one of the following : 010170 for systems with a Date format of *MDY 010170 for systems with a Date format of *DMY 700101 for systems with a Date format of *YMD.

Help Text (added in future release) Output file sequences and volumes from this duplication operation are assigned the expiration dates of the input file sequences and volumes.

Note: the following PTF or their superseding PTF is required.

• V6R1M0 SI33975
• V5R4M0 SI33974
• V5R3M0 Si33971

Back to top

Send email notification for messages sent to the BRMS log

Use the BRMS graphical user interface (GUI) to set the following 'Global Policy Properties':

• Click the 'Network' tab and set the 'Primary system', 'Secondary system' and 'E-mail address' fields.
  
  
  
  Note: The system that you select as the primary system will distribute the messages. If the primary system cannot complete the distribution, it sends the message to the secondary system for distribution. For example, you could select a local primary system and a remote secondary system. When the local system is in restricted state, BRMS sends the email through the remote secondary system. If a secondary system is not specified and the primary system is in restricted state, the message will be queued and distributed as soon as the BRMS networking is restarted. Note: The email server must have the Simple Mail Transport Protocol (SMTP) configured. If it is not configured, messages will not get distributed and an error message may not result.
  
  
• Click the 'Logging' tab and add the messages you wish to be notified for in the 'Message IDs to distribute' field. For example, to have emails sent for errors found by the STRBKUBRM command, add messages BRM1970, BRM1971, BRM10A1, BRM1820, BRM4116 and CPF9999.
  
  

Back to top

Working with saved IFS objects

In BRMS, there are several methods to view the save history for IFS objects, using commands such as WRKMEDBRM, WRKMEDIBRM, WRKLNKBRM, etc.

When an option is taken to work with objects from one of the commands and you are presented with a list containing the column heading "Directory", it is a list of the parent directories for objects that were included in the save. This list does not indicate whether the directory objects were included in the save.

When an option is taken to work with objects from one of the commands and you are presented with a list containing the column heading "Object", it is a list of the objects that were included in a save. This list does indicate that all of the objects were included in the save.

The following examples use this following directory structure:

• '/dir1'
• '/dir1/file1'
• '/dir1/dir2a'
• '/dir1/dir2a/file2'
• '/dir1/dir2b'

If you take option 7 on an item from a screen with a "Directory" column, '/*' will be appended to the name during the restore. For example, specifying option 7 for '/dir1' will restore '/dir1/*'. The directory object '/dir1' will not be restored, only the contents of '/dir1' will be restored: '/dir1/file1', '/dir1/dir2a', '/dir1/dir2a/file2' and '/dir1/dir2b'.

If you take option 7 on an item from a screen with an "Object" column, the object itself will be included in the restore. For example, specifying option 7 for 'dir1' will restore the directory object '/dir1' along with the contents of '/dir1': '/dir1/file1', '/dir1/dir2a', '/dir1/dir2a/file2' and '/dir1/dir2b'.

Back to top

Remove the deleted library attention block from recovery reports

To remove the deleted library attention block from recovery reports, see data area QUSRBRM/Q1ANODLTAT.

Back to top

When do I use the INZBRM OPTION(*SECUREDDM) command?

This command was designed to maintain the user profile and password for BRMS to use when a the BRMS network has been set up to use secure DDM connections. This removes the requirement of having to add server authentication entries for all the systems in a BRMS secure DDM network. The server authentication entries for QDDMSERVER are still required. The INZBRM OPTION(*SECUREDDM) command requires *SECADM special authority.

• To set the user profile:

  	INZBRM OPTION(*SECUREDDM)
  	        ACTION(*SET)
  	        USER(xxxxx)
  	        PASSWORD()
  

Note: The user profile and password must exist and be the same on the local and remote systems. It is recommended that the user profile entered on the ACTION(*SET) be the same user profile that was entered for the QDDMSERVER server authentication entry for the QBRMS user profile. The ACTION(*SET) should be used to initially set a user profile and password for BRMS to use for secure DDM connections. It also needs to be ran every time the user profile or password of the profile set for secure DDM connections changes. It only needs to be ran on one of the systems in the BRMS network.

• To display the currently set user profile:

  	INZBRM OPTION(*SECUREDDM)
  	        ACTION(*DISPLAY)
  

Note: This will cause a CPF9898 message which will display the user profile BRMS is using for secure DDM connections. This message display *NONE if no user profile is set.

• To remove the user profile:

  	INZBRM OPTION(*SECUREDDM)
  	        ACTION(*REMOVE)
  

Back to top

Status of last run of BRMS backup Control Groups

It is possible to check the status of the last run of a BRMS control group. This is only available in V6R1M0 of BRMS and PTF SI31653 superseding PTF needs to be applied.

Using BRMS GUI

Only the status of the *SYSTEM control group can be checked. To check the status of the last run, do the following:

1. Ensure that the BRMS GUI plug-in has been removed and reinstalled after SI31653 (V6R1M0) or superseding PTF was applied
2. Open IBM i Navigator
3. Click on Backup, Recovery and Media Services
4. Click on Open Backup, Recovery and Media Services

The following panels explain the differences a user may see:

When the *SYSTEM control group has   never been done or no *SYSTEM control group history records exist:

Click to enlarge

When the most recent *SYSTEM control group was successful:

Click to enlarge

When the most recent *SYSTEM control group completed with errors:

Click to enlarge

When the most recent *SYSTEM control group completed with unexpected errors:

Click to enlarge

5250 Emulation (Green Screen)

In green screen, the following option is available:

CALL QBRM/Q1AOLD PARM('CTLGSTATUS' '*DISPLAY')

The following output will be shown in the joblog.

AUTODUPE	*BKU	*FAILED	1080520133003	189671	1080520.
*SYSTEM	*BKU	*FAILED	1080612094059	226878	1080612.
FRED	*BKU	*QUALIFIED	1080612124046	228654	1080612.
TESTER	*BKU	*SUCCESS	1080616105029	230290	1080616
NOMSGIFS	*BKU	*SUCCESS	1080618084252	231088	1080618.

Where:

• The first column is the control group name.
• The 2nd column is the control group type...only *BKU support.
• The 3rd column is status:
  • *FAILED means did not work
  • *QUALIFIED means some objects were not backed up.
  • *SUCCESS - means no problems
• The 4th column is the date/time in CYYMMDDHHMMSS format.
• The 5th column is the job number.
• The 6th column is the date of expiration of media used in CYYMMDD format.

Back to top

Having expiration dates after 12/31/2038 in BRMS

Media volumes cannot have an expiration date after 12/31/2038. Setting a volume's expiration date to a date that exceeds 2038. will cause the date to be converted to *PERM.

To find all *PERM volumes that would have expired after 12/31/2038, run this query:

SELECT TMCVSR, TMCCRT, TMCEXP FROM QUSRBRM/QA1AMM WHERE TMCCRT <
'CYYMMDD' AND TMCCRT <> '0000000' AND TMCEXP = '9999999' ORDER BY
 TMCCRT ASC

For example, if you would like to find all volumes that are more than 11 months old (assume today's date is 1110510), run this query:

SELECT TMCVSR, TMCCRT, TMCEXP FROM QUSRBRM/QA1AMM WHERE TMCCRT <
'1100610' AND TMCCRT <> '0000000' AND TMCEXP = '9999999' ORDER BY
 TMCCRT ASC

Note: In releases IBM i 7.1 or earlier, the following PTFs or their superseding PTFs are required:

• 7.1 SI43868
• V6R1M0 SI43869
• V5R4M0 SI43862

Back to top

Using BRMS to Update Status of Cartridges on TS35xx Tape Media Libraries

When sharing a TS35xx tape media library between systems, the status of cartridges does not always match. Using BRMS, it is now possible to get the volume status to match.

In order to set this up, the following requirements must be met:

1. BRMS networking is required and set up. See how to set up the BRMS network by referring to Rochester Support Center knowledgebase document 361619501, BRMS Networking: Adding, Removing, or Renaming a System. To link to 361619501 immediately, click here Notes Link.
2. Systems have to be attached to the same tape media library.
3. IBM i Navigator (GUI) with BRMS plug-in or IBM i Directory (Web) for setup.
4. V6R1M0 or higher.
5. Devices need to be defined to BRMS (WRKDEVBRM).
6. Media has to be moved using BRMS (MOVMEDBRM, ADDMLMBRM, WRKMLMBRM Option 1 and Option 7, or WRKMEDBRM Option 8).

The following steps list how to configure this using IBM i navigator:

1. Open Backup, Recovery, and Media Services. You should right click on Media, and select Manage Devices.

Click to enlarge

2. A list of tape devices defined in BRMS is displayed.

Click to enlarge

3. Select the device you want to configure, right click on it , select List actions, and then select Manage Tape Media Library Connections....

Click to enlarge

4. Select List Actions, and then select Add.

Click to enlarge

5. Type the Device name, select the System name, and select OK .

Click to enlarge

6. Repeat Steps 1 through 5 for each system. If there are multiple shared libraries, the steps would need to be completed for each tape media library.

Click to enlarge

7. Once all the systems sharing the tape media library have being added, the screen should look something like this:

Click to enlarge

When media is now moved using BRMS commands (MOVMEDBRM, ADDMLMBRM, WRKMLMBRM Option 1 and Option 7 or WRKMEDBRM Option 8) , the status of cartridges in the tape library on other systems in the BRMS network will be updated.

Back to top

Overriding the presentation characters for Domino and DAOS weekly activity

Use the following command to override the presentation characters that are used to represent Domino and DAOS saves in weekly activity fields. By default, 'N' is used to represent 'Domino full backups and incremental Domino Attached and Object Service (DAOS) backups' and 'D' is used to represent 'Domino incremental backups and full Domino Attached and Object Service (DAOS) backups'.

To set 'Domino full backups and incremental Domino Attached and Object Service (DAOS) backups' to 'Y' and 'Domino incremental backups and full Domino Attached and Object Service (DAOS) backups' to 'Z', use the following command:
CALL PGM(QBRM/Q1AOLD) PARM('DAOSCHARS ' '*SET ' ' ' 'Y' 'Z')

To set the weekly activity values back to their defaults, use the following command:
CALL PGM(QBRM/Q1AOLD) PARM('DAOSCHARS ' '*SET ' ' ' 'N' 'D')

To show the override values for presentation characters that are used to represent Domino and DAOS weekly activity, use the following command: CALL PGM(QBRM/Q1AOLD) PARM('DAOSCHARS ' '*DISPLAY' ' ')

Note: The presentation character overrides for Domino and DAOS weekly activity will only be available in releases IBM i 7.1 and earlier. In releases following IBM i 7.1, interfaces will be provided on BRMS commands. The following PTFs or their superseding PTFs are required:

• 7.1 SI40005
• V6R1M0 SI40006
• V5R4M0 SI40001

Back to top

Overriding the update history (UPDHST) parameter for library objects

To override the update history (UPDHST) parameter for library save operations, use one of the following commands:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHST' '*YES')
CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHST' '*NO')

To remove the override for the update history (UPDHST) parameter for library save operations, use the following command:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*REMOVE ' 'UPDHST')

To show the override for the update history (UPDHST) parameter for library save operations, use the following command:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*DISPLAY' 'UPDHST')

Note: The update history parameter override will only be available in releases IBM i 7.1 and earlier. In releases following IBM i 7.1, interfaces will be provided on BRMS commands. The following PTFs or their superseding PTFs are required:

• 7.1 SI40005
• V6R1M0 SI40006
• V5R4M0 SI40001

Back to top

Overriding the update history (UPDHST) parameter for integrated file-system objects

To override the update history (UPDHST) parameter for integrated file-system save operations, use one of the following commands:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHSTI' '*YES')
CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHSTI' '*NO')
CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHSTI' '*SYS')
CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHSTI' '*PC')
CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'UPDHSTI' '*SYS *PC')

To remove the override for the update history (UPDHST) parameter for integrated file-system save operations, use the following command:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*REMOVE ' 'UPDHSTI')

To show the override for the update history (UPDHST) parameter for integrated file-system save operations, use the following command:

CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*DISPLAY' 'UPDHSTI')

Note: The update history parameter override will only be available in releases IBM i 7.1 and earlier. In releases following IBM i 7.1, interfaces will be provided on BRMS commands. The following PTFs or their superseding PTFs are required:

• 7.1 SI40005
• V6R1M0 SI40006
• V5R4M0 SI40001

Back to top

Overriding the 'Detail retention days' parameter on the RMVMEDIBRM command for IFS objects

In releases IBM i 7.1 and earlier, the 'Detail retention days' parameter on the RMVMEDIBRM command applies to detail history for library objects, spooled files, folders and IFS objects. There is no way to change the retention days specifically for IFS objects using the command. This override is being provided to change the detail history retention days for IFS objects.

To override the detail history retention days for IFS objects, use the following command, where nnnn is the number of days the IFS detail history will be retained after a save.

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'LNKDTL' 'nnnn')

To remove the override:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*REMOVE ' 'LNKDTL')

To show the override:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*DISPLAY' 'LNKDTL')

Note: In releases IBM i 7.1 and earlier, this override is available with the following PTFs or their superseding PTFs:

• 7.1 SI41206
• V6R1M0 SI41205
• V5R4M0 SI41204

Back to top

Display the status of a control group

In releases V6R1M0 and later, it is possible to display the status of an individual BRMS control group by running the following command:

  CALL QBRM/Q1AOLD Parm('CTLGSTATUS' '*DISPLAY'    'xxxxxxxxxx')

  where xxxxxxxxxx = control group name

If you wish to see all the control groups, run the following command:

  CALL QBRM/Q1AOLD Parm('CTLGSTATUS' '*DISPLAY')

The command will send a message for each control group that contains the following information:

• Control Group Name
• Type (*BKU) backup
• Status: *SUCCESS/*FAILED/*QUALIFIED
• Save Date/Time: CYYMMDDHHMMSS
• Job Nbr
• Expiration Date: CYYMMDD

Note: In release V6R1M0 or IBM i 7.1, the following PTFs or their superseding PTFs are required:

• 7.1 SI42066
• V6R1M0 SI42065

Back to top

Allow volumes that are marked for duplication to be moved

In releases IBM i 7.1 and earlier, media movement is not allowed for volumes that are marked for duplication. The following interfaces can be used to override this behavior and allow movement for volumes that are marked for duplication. This is useful for device TS7650 and other virtual tape libraries which require virtual volumes to be moved during the duplication process.

To override a move policy to allow movement when a volume is marked for duplication:

  CALL QBRM/Q1AOLD  PARM('MOVMRKDUP '  '*SET   '  'move policy'

'Y')

To remove the override for a move policy that allows movement when a volume is marked for duplication:

  CALL QBRM/Q1AOLD  PARM('MOVMRKDUP '  '*SET   '  'move policy'

'N')

To display all overrides for move policies that allow movement when a volume is marked for duplication:

  CALL QBRM/Q1AOLD  PARM('MOVMRKDUP '  '*DISPLAY  ')

To remove all overrides for move policies that allow movement when a volume is marked for duplication:

  CALL QBRM/Q1AOLD PARM('MOVMRKDUP ' '*CLEAR    ')

Restriction: In releases IBM i 7.1 and earlier, there will be no synchronization of this behavior to other systems in the BRMS network. Each system wishing to use this new function will need to run the commands above. In releases following IBM i 7.1, this restriction will be removed.

Note: The move policy override to allow movement when a volume is marked for duplication will only be available in releases IBM i 7.1 and earlier. In releases following IBM i 7.1, similar interfaces will be provided on BRMS commands. The following PTFs or their superseding PTFs are required:

• 7.1 SI42925
• V6R1M0 SI42924
• V5R4M0 SI42923

Back to top

Does BRMS support the ASYNCBRING parameter when saving the IFS?

In V6R1 and above, override support for the new ASYNCBRING key on QsrSave API to help improve IFS save performance is now possible using one of the following commands:

To enable the new ASYNCBRING key:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'ASYNCBRING' '*YES')

To disable the new ASYNCBRING key:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'ASYNCBRING' '*NO ')

To remove the override, use the following command (default is *NO):

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*REMOVE ' 'ASYNCBRING')

To show the current override being used, use the following command:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*DISPLAY' 'ASYNCBRING')

Note: In releases following IBM i 7.1, interfaces will be provided on BRMS commands and on the control groups to use the new Asynchronous Bring and these calls will not work. If *YES had been set in the call statement , then the backup policy will reflect that on a new field after upgrading.

The following PTFs or their superseding PTFs are required:

BRMS:
7.1 SI44710
V6R1M0 SI44709

IBM i OS:
For release 6.1.0 (with 6.1.0 SLIC)
MF53846
SI44587
SI44589
SI44739

For release 6.1.0 (with 6.1.1 SLIC)
MF53847
SI44587
SI44589
SI44739

For release 7.1.0
MF53848
SI44588
SI44590
SI44688

Other IBM i PTFs to help IFS save performance:
- 6.1.0: MF52495
             SI45791
- 6.1.1: MF52284
- 7.1.0: MF52772
             SI45792

Note: The best performance improvement may be seen with a well balanced directory tree in which all objects qualify for the save. In situations where a large number of objects reside in a single directory, few objects qualify for the save, or the system is memory constrained, performance may degrade with ASYNCBRING(*YES) specified.

Back to top

Using Compression for BRMS Save Files

In V5R4 and above, override support for the DTACPR parameter is now supported for saves to save file saves within BRMS. *HIGH/*MEDIUM/*LOW/*DEV/*NO/*YES are all valid values.

To enable the new save file DTACPR parameter to a *HIGH:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*HIGH  ')

To enable the new save file DTACPR parameter to a *MEDIUM:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*MEDIUM  ')

To enable the new save file DTACPR parameter to a *LOW:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*LOW  ')

To enable the new save file DTACPR parameter to a *YES:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*YES  ')

To enable the new save file DTACPR parameter to a *NO:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*NO  ')

To enable the new save file DTACPR parameter to a *DEV:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*ADD' 'SAVFDTACPR'
  '*DEV  ')

To remove the override, use the following command:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*REMOVE ' 'SAVFDTACPR')

To show the current override being used, use the following command:

  CALL PGM(QBRM/Q1AOLD) PARM('PARMOVR' '*DISPLAY' 'SAVFDTACPR')

The following PTFs or their superseding PTFs are required:
BRMS:
7.1    SI44710
V6R1M0 SI44709
V5R4M0 SI44708

Back to top