Susan Powers
Scott Buttel
Amit Dave
Rolf Hahn
Derek McBryde
Edelgard Schittko
Tony Storry
Gunnar Svensson
Mervyn Venter
ibm.com/redbooks
SG24-4840-01
International Technical Support Organization
February 2001
Take Note!
Before using this information and the product it supports, be sure to read the general information in Appendix I,
“Special notices” on page 317.
This edition applies to Version 3, Release 2 of Backup Recovery Media Services for OS/400, 5769-BR1, for use with
V4R5 of OS/400.
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1997, 2001. All rights reserved
Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
How this redbook is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
iii
3.16 BRMS/400 reports and maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.17 Current status of media and save activity . . . . . . . . . . . . . . . . . . . . . . . 53
3.18 Restoring data using BRMS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
v
9.3.2 Creating media library device descriptions . . . . . . . . . . . . . . . . . . . 168
9.3.3 Creating a Robot Device Description (ROBOTDEV) for the 3494 . . 170
9.3.4 Changing media library device descriptions . . . . . . . . . . . . . . . . . . 172
9.3.5 Allocating resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9.3.6 Managing multiple devices in a single 3494 . . . . . . . . . . . . . . . . . . 177
9.3.7 Selecting and varying on devices . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.4 Updating BRMS/400 device information. . . . . . . . . . . . . . . . . . . . . . . . . 181
9.4.1 Device location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.5 Managing cartridges in the media library device . . . . . . . . . . . . . . . . . . 183
9.5.1 Special cartridge identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9.5.2 VOL(*MOUNTED) usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.5.3 End option (ENDOPT) setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.5.4 Importing cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.5.5 Exporting cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.6 Restricted state automation for the 3494 . . . . . . . . . . . . . . . . . . . . . . . . 189
9.7 Using a tape resource as a stand-alone unit (RISC) . . . . . . . . . . . . . . . 190
Chapter 12. Planning for the hierarchical storage management archiving so-
lution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
12.1 Archiving considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
12.1.1 How archiving is done by BRMS/400 . . . . . . . . . . . . . . . . . . . . . . 217
12.1.2 The BRMS/400 double save for archiving . . . . . . . . . . . . . . . . . . 221
12.2 Normal-aged file member archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
12.2.1 Database file members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
12.2.2 Source file members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
12.3 Application swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
12.4 Logical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12.5 Duplicating your archive tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
12.5.1 Archive tape duplication process . . . . . . . . . . . . . . . . . . . . . . . . . 227
12.6 Re-archiving retrieved objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
12.7 Retrieval considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
12.7.1 How BRMS/400 does Dynamic Retrieval . . . . . . . . . . . . . . . . . . . 230
12.8 Retrieval methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
vii
13.9 Administration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
13.9.1 Retrieve authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
13.9.2 Restore options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
13.9.3 Securing the retrieve policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Appendix B. Save and restore tips for better performance . ...... . . . . . 301
B.1 Data compression . . . . . . . . . . . . . . . . . . . . . ............. ...... . . . . . 301
B.2 Load balancing. . . . . . . . . . . . . . . . . . . . . . . . ............. ...... . . . . . 302
B.3 Using the USEOPTBLK parameter . . . . . . . . ............. ...... . . . . . 302
B.4 Additional hints and tips . . . . . . . . . . . . . . . . . ............. ...... . . . . . 302
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
ix
x Backup Recovery and Media Services for OS/400
Figures
1. Overview of BRMS/400 operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Changing BRMS/400 license information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. BRMS/400 main menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. BRMS/400 functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. BRMS/400 commands by functional areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Add Storage Location example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Change Storage Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changing device using BRM for V3R7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Add Media Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Add Media Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Container class for ¼-inch cartridges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Adding a container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Change Container showing a move policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. User-created move policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15. Media management summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16. Change Media Policy example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17. Expiring media using the STREXPBRM command . . . . . . . . . . . . . . . . . . . . . 31
18. Changing defaults for the BRMS/400 system policy . . . . . . . . . . . . . . . . . . . . 32
19. Change Presentation Controls display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
20. Change Backup Policy display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
21. Adding and removing libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
22. Backup control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
23. Work with Backup Control Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
24. Backup control group *SYSGRP for backing up IBM data . . . . . . . . . . . . . . . . 38
25. Default backup control group *BKUGRP for saving all user data . . . . . . . . . . 39
26. Job Queues to Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
27. Ending subsystems in the EDELM09 control group . . . . . . . . . . . . . . . . . . . . . 42
28. Restarting ended subsystems in the SAVIFS control group . . . . . . . . . . . . . . 42
29. Change Backup Control Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
30. Adding media using the ADDMEDBRM command . . . . . . . . . . . . . . . . . . . . . 44
31. Add Media Information to BRM display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
32. Backing up the SETUPTEST control group . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
33. BRMS/400 log information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
34. Start Maintenance for BRM example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
35. Verify Media Moves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
36. Work with Media Information example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
37. Work with Media example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
38. Display Backup Plan example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
39. Checking for expired media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
40. The message indicating that the request was successful . . . . . . . . . . . . . . . . 64
41. Sample backup control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
42. User Exit Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
43. Omitting libraries from backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
44. Edit Backup Control Group Entries display: Creating an *EXIT . . . . . . . . . . . . 73
45. User Exit Maintenance display: Completed MONSWABRM command . . . . . . 76
46. Synchronizing multiple libraries with save while active . . . . . . . . . . . . . . . . . . 77
47. Save-while-active example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
48. Save-while-active example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
49. Save-while-active example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
50. Save-while-active example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figures xi
51. Save-while-active example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
52. Including and excluding spooled file entries in backup list . . . . . . . . . . . . . . . .84
53. Backup list SAVESPLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
54. Work with Saved Spooled Files (WRKSPLFBRM) . . . . . . . . . . . . . . . . . . . . . .85
55. Select Recovery Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
56. Start console monitor option on the Backup menu . . . . . . . . . . . . . . . . . . . . . . 88
57. Console Monitor active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
58. Submitting a system save to batch using the console monitor . . . . . . . . . . . . .89
59. Command line access from the console monitor . . . . . . . . . . . . . . . . . . . . . . .89
60. Initial program to secure the console monitor . . . . . . . . . . . . . . . . . . . . . . . . . .90
61. Console Monitor Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
62. Work with Backup Control Groups display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
63. Add Job Schedule Entry display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
64. Work with BRM Job Schedule Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
65. Changing job scheduler in BRMS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
66. Change Job Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
67. Work with Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
68. Adding a BRMS application to job scheduler for OS/400 . . . . . . . . . . . . . . . . . 95
69. Sample backup control group entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
70. BRMS/400 synchronization process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
71. Work with Configuration Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
72. WRKACTJOB display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
73. Additional Message Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
74. Additional Message Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
75. Overview of establishing a BRMS/400 network . . . . . . . . . . . . . . . . . . . . . . . 105
76. Adding a new system to the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
77. SYSTEM05 added to the network group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
78. Running INZBRM *NETSYS on SYSTEM05 . . . . . . . . . . . . . . . . . . . . . . . . . 108
79. Network group entry on SYSTEM05 for SYSTEM09 . . . . . . . . . . . . . . . . . . . 110
80. BRMS/400 networking subsystem: Q1ABRMNET . . . . . . . . . . . . . . . . . . . . .110
81. Change Network Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
82. Removing systems from a network group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
83. Removing the old system name from the network . . . . . . . . . . . . . . . . . . . . .115
84. Confirm Remove of Network Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
85. Incorrect way of joining two BRMS/400 networks . . . . . . . . . . . . . . . . . . . . . . 118
86. Correct way to join the BRMS/400 network . . . . . . . . . . . . . . . . . . . . . . . . . . 118
87. Media update to check the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
88. No update for SYS04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
89. LAN Server/400 Integrated PC Server objects . . . . . . . . . . . . . . . . . . . . . . . . 126
90. Change Link List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
91. Examples of authority issues with IFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
92. Displaying the monitor job example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
93. Ending the monitor job example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
94. Work with Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
95. Change Link List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
96. Example of an *LNK list in a control group . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
97. Example of the *LINK list in the V3R7 control group. . . . . . . . . . . . . . . . . . . . 140
98. Display BRM Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
99. Work with Media Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
100.Work with Link Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
101.Work with Directory Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
102.Work with Link Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
103.Work with Directory Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Figures xiii
157.Retrieve *VERIFY messages (Part 1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
158.Retrieve *VERIFY messages (Part 2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
159.Retrieve *VERIFY messages (Part 3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
160.Retrieve *NOTIFY message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
161.Confirm Retrieve display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
162.Program for restricted save processing with the 3494 . . . . . . . . . . . . . . . . . . 306
163.CL program to create a tape category and add volumes (Part 1 of 2) . . . . . .307
164.CL program to create a tape category and add volumes (Part 2 of 2) . . . . . .308
165.Example program to identify volume mismatches . . . . . . . . . . . . . . . . . . . . .309
166.Example query to identify volume mismatches . . . . . . . . . . . . . . . . . . . . . . . 310
Tables xv
xvi Backup Recovery and Media Services for OS/400
Preface
This IBM Redbook preserves the valuable information from the first edition of A
Practical Approach to Managing Backup Recovery and Media Services for
OS/400, SG24-4840, which is based on CISC implementations. The updates in
this edition were made to reflect the documentation and URL values that were
available at the time of publication.
This publication is unique in its detailed coverage of using BRMS/400 with tape
libraries within a single AS/400 CISC system, or within multiple AS/400 CISC
configurations across multiple levels of OS/400 ranging from OS/400 V3R1 to
and through OS/400 V3R7. Coverage for BRMS for OS/400 for RISC and iSeries
systems will be found in a redpaper that is planned for publication later in 2001.
Note: At the time this redbook was written, V4R2 and earlier releases of OS/400
and BRMS were no longer supported by IBM.
This redbook is written for customers who are familiar with the basic functions of
BRMS/400 and are in the process of implementing media management and tape
management solutions. This publication is also intended for IBM Business
Partners, marketing specialists, availability specialists, and support personnel.
Prior to reading this redbook, you must be familiar with the native OS/400 save
and restore command interfaces and their options.
Preface xix
The team that wrote this redbook
The second edition of this redbook preserves the content for those customers
maintaining CISC systems. The team who updated this redbook for the second
edition includes:
Susan Powers Senior I/T Specialist for the ITSO, Rochester Center
The first edition of this redbook was produced by a team of specialists from
around the world working at the International Technical Support Organization
Rochester Center:
Thanks to the following development and support personnel for their invaluable
contributions to this project:
David Bhaskaran
Swinder Dhillon
Tim Fynskov
Paul (Hoovey) Halverson
Steve Hank
Dennis Huffman
Ann Johnson
Neil Jones
Greg Krietemeyer
Scott Maxson
Genyphyr Novak
Debbie Saugen
Bill Soranno
IBM Rochester Laboratory
Joy Cheek
Bruce Reynolds
Brian Younger
Merch Bacher and Associates, Oklahoma, USA
The ITSO also thanks the participants of the BRMS/400 Forum for sharing their
experiences with the BRMS/400 product and for providing valuable hints and tips
to the BRMS/400 community.
Preface xxi
xxii Backup Recovery and Media Services for OS/400
Chapter 1. Backup Recovery and Media Services/400 introduction
You can plan, control and automate the backup, recovery, and media
management services for your AS/400 systems with Backup Recovery and Media
Services for OS/400 (BRMS/400).
Proper planning is the key to success, and skills are available to help you plan
the hardware, media, and administrative resources needed for successful
implementation and operation. This includes recovery planning, particularly
disaster recovery planning, where you identify and document your critical
resources and your plans to recover them.
Contact your local IBM representative for more information on how IBM can help
you with your planning.
Backup
BRMS/400
Delete
Archived Media Backup
Copies Interim Inventory Interim Copies
Save Files Save Files
Control groups define logical groups of libraries and objects that possess similar
backup, retention, and recovery requirements. In addition to allowing you to
define the order in which backup, archive, and recovery processing occurs,
control groups also provide for special related actions such as tape loads,
processing subsystems, and job queues. Control groups provide exits for
user-defined processing during the backup cycle.
During installation, BRMS/400 can retrieve information from your AS/400 internal
configuration tables and configure defaults for your environment. For example, it
automatically creates BRMS/400 device information for the tape drives that you
configured on your system. You must review the default options that are selected
by BRMS/400 for further changes.
If you use BRMS/400 commands in user control language programs, you should
be particularly aware of new or changed commands, new or changed parameters,
and any changes in defaults. See Backup Recovery and Media Services for
OS/400 (part of the IBM Online Library SK2T-2171) for information on this.
Information is also available in Appendix A, “Summary of changes” on page 289.
We strongly recommend that you also review Automated Tape Library Planning
and Management, SC41-5309, for details on significant enhancements in the
areas of tape automation.
For example, Version 3 Release 1 (V3R1) of BRMS/400 for CISC processors saw
enhancements on Dynamic Retrieval and improvements in BRMS/400
networking. It saw the introduction of the chargeable OS/400 Media and Storage
Extensions (QMSE) feature for OS/400. Communications for 3494 Automated
Tape Library Data Server was integrated into OS/400 and new media library
commands were introduced. Other commands were changed. For example,
Confirm Moves using BRM (CFMMOVBRM) was changed to Verify Moves using
BRM (VFYMOVBRM); Save Recovery using BRM (SAVRCYBRM) was changed
to Save Media Information using BRM (SAVMEDIBRM).
Version 3 Release 2 (V3R2) of BRMS/400 for CISC processors has many of the
features that were available in V3R6 but retains its identity with V3R1. The
functions are equivalent to those provided with the BRMS/400 V3R1 release.
Version 4 Release 1 and Version 4 Release 2 (V4R1 and V4R2) of BRMS/400 for
RISC processors includes enhancements to support generic folder names for
backup and supports large tape file sequence numbers up to 16,777,215. It
allows the ability to omit an ASP from a backup, an *ERR keyword on select
commands to help identify the objects in error on a backup, and other command
and menu improvements.
A rich portfolio of functions is now available from the OS/400 and BRMS/400
combinations. It is a challenging portfolio for those in the process of migration, for
those who have mixed levels of software in a network, and for those who are
introducing new media types and having them coexist with the existing types.
Hint
At times, it can be difficult to remember the enhancements made in every
release. One way you can be certain of enhancements within a particular
release of BRMS/400 is to understand the actual release cycle. For example,
V3R7 provides functional equivalency with V3R2 and contains additional
enhancements. Likewise, V3R2 provides functional equivalency with V3R6,
and contains additional enhancements. You can draw similar comparisons for
V3R6 and V3R1.
The authors have made an attempt to pull together the threads of the overall
picture. However, it is not the objective of this redbook to paint the picture itself.
For more detail and for self-education, you are still asked to refer to the
BRMS/400 manuals and other information that has already been published.
We have taken BRMS/400 V3R1 as the starting level and assume that most
people are already familiar with the BRMS/400 functions. We have not addressed
V2R3 or V3R0M5 because these releases of OS/400 were no longer supported
by IBM at the time this redbook was published. Most of the examples
documented in this book are primarily based on V3R2, V3R6, or V3R7 releases
of BRMS/400.
Note: We intend to update all the relative information in this publication to V4R5
at a later date.
In writing this book, we assume that you have a working knowledge of the basics
of BRMS/400. The redbook attempts to focus on areas that are not so familiar
such as automated tape libraries, managing BRMS/400, networking BRMS/400
for media synchronization, the integrated file system, and automated recovery.
This chapter addresses the planning considerations for BRMS/400 along with
details on how to install BRMS/400 on your AS/400 system. For additional
planning information on backup on recovery functions, you should also consult
Backup and Recovery - Basic, SC41-4304.
You also need to be aware of the various functional enhancements that have
been made to the BRMS/400 releases since V3R1. See Appendix A, “Summary
of changes” on page 289, for additional information.
2.1.2 Media
In addition to strategies for save and restore, you should have a strategy for
media to use for your save and restore. This should include the number of copies
of your saved objects that you keep, where you keep these copies, and which
media to use. It ensures that, in the event of a backup being unavailable or
unreadable, you can restore the system from another copy. You should consider
keeping at least one of these backups off-site to protect your data in the event of
a major disaster, such as fire or flood, at your main site.
The following items will help you design standards for your media volumes:
• Scratch pool: With a scratch pool, tapes are not allocated to specific sets.
When a tape is required for output, any available scratch tape can be used.
This requires that you keep an inventory of all tapes so that available tapes
can be identified. The advantage is that tapes do not need to be allocated in
advance. If the inventory is well managed, tape usage can be balanced rather
than some tapes being used more than others. You can control the retention
periods down to the file level on the tape. A scratch pool is easily managed by
BRMS/400, which is the preferred option.
Table 1. Media scratch pool
Note
This technique may not be suitable if there are plans to merge two
enterprises that adopt the volume naming conventions described in the
preceding example.
Note
If you already use this system, you can change to a scratch pool without
renaming the media. With the scratch pool, any AS/400 system in the
BRMS/400 network can use an expired volume so your volumes may not
always get used by the system to which they were originally assigned. This
should not concern you, since within a BRMS/400 network, the media
information is shared across all of the AS/400 systems that are participating
in the network. Most importantly, you have a unique volume in the media
inventory that you can track and manage using BRMS/400.
When you physically label cartridges for the 3494 Automated Tape Library Data
Server, you add an E as the suffix (seventh character) to the enhanced capacity
3490 cartridges and a J to the 3590 cartridges. Within BRMS/400, you do not
have to create special volume identifiers for these types of cartridges. BRMS/400
automatically adds the suffix during media enrollment.
The purpose of taking an offline copy of your system and applications is to protect
against a major failure. Save files in a user auxiliary storage pool (ASP) do not
protect if your entire AS/400 configuration is affected. Keeping your offline tapes
Even a fire-proof safe or vault close to the computer room cannot guarantee a
fully-protected environment in the event of an explosion or major fire. Therefore,
you should plan to have at least one copy of your backups stored off-site. You
should consider two off-site copies (in different locations) for your most critical
objects.
Note: Do not forget to include a copy of your updated recovery report with the
media. It is also a good idea to keep a copy of your recovery procedures off-site
with the media. This ensures that you have procedures to follow even if your main
site has been destroyed.
You should consider both the device and media type that you require for your
backups. Each has its own characteristics, and you should decide which to use
for different types of saves.
Generally, for backup purposes, you use the fastest and most dense media. For
systems with a large amount of disk storage, you probably require the speed and
capacity of a 3590 tape device.
Hint
Your SAVSYS activity is restricted by your alternate IPL device. You must also
consider whether you need to be able to read your offline backups on another
system and what limitations that may impose.
Informational APAR II09772 is the master index for all of the Informational APARs
related to BRMS/400. You should download this APAR and any subsequent
APARs that you may feel are relevant for your installation.
This information is readily available through the Internet and from the AS/400
home page. If you do not have access to the Internet, contact your IBM Support
or Service Representative to assist you with the information.
To access information on PTFs from the AS/400 Internet home page, follow these
steps:
1. Go to http://www.as400.ibm.com/ using your Web browser.
2. Select the Support fast path from the options.
3. Select AS/400 under Integrated mid-market business servers. This takes
you to the iSeries and AS/400 Technical Support home page.
4. Select the Technical Information and Databases fastpath.
5. Select the Authorized Problem Analysis Reports (APARS) fastpath. This
takes you into a multiple selection display for APARs.
6. Select the All APARs by Component fastpath. This gives you a list of
licensed program products by their release.
7. Select the 57XXBR1 - BRMS/400 component fastpath to review all the PTFs
and APARs related to the product for your appropriate release of BRMS/400.
Before you begin installing BRMS/400 on your AS/400 system, make sure you
have:
Note
MLDD is only required if you are using the 3494 Automated Tape Library
Data Server with OS/400 V3R1 or V3R2 (CISC-based processors). It is not
required for AS/400 with PowerPC technology with V3R6 or V3R7.
For additional information about MLDD installation and setup on your
AS/400 system, see IBM 3494 User’s Guide: Media Library Device Driver
for Application System/400, GC35-0153.
BRMS/400 creates two libraries on your system: QBRM and QUSRBRM. The
QBRM library contains BRMS/400 program objects. The installation program also
copies all of the BRMS/400 commands into the QSYS library. The QUSRBRM
library is used to store BRMS/400 database objects and logs, including a history
of media information, user-defined control groups, policies, and other installation
specific information. We strongly recommend that you include these two libraries
in a backup control group to be saved for disaster recovery purposes.
Note
Beginning with V3R2 and V3R7, a default user profile QBRMS is shipped as
part of OS/400 even if you do not install BRMS/400. This user profile QBRMS
must not be deleted.
After you have installed BRMS/400, verify that the Allow user domain in user
libraries (QALWUSRDMN) system value is set to *ALL, which is the default
shipped value. This value allows user domain objects in libraries and determines
which libraries on the system may contain the user domain objects *USRSPC
(user space), *USRIDX (user index), and *USRQ (user queue).
If this value is not set to *ALL, you must add QBRM and QUSRBRM libraries to
the list of libraries specified for the QALWUSRDMN value.
Use the Change License Information ( CHGLICINF) command to change the license
information as shown in Figure 2 on page 14.
Note: If you are upgrading from a V2R3 system to a V3R1 or a later release, you
must register your media using the INZBRM *REGMED command. This time stamps
the media at the time the command is run. If you continued to update media on
other systems in your network during this process, the updates may have an
older time stamp and are ignored. Make sure that all network activity has
completed before you register the media.
The INZBRM command builds default control groups, BRMS/400 policies, and
tables based on the characteristics of the system that is being initialized.
If you are re-installing on a V3R6, V3R7, or a V3R2 system, you might choose to
use INZBRM OPTION(*DEVICE). This performs the same functions as INZBRM
OPTION(*DATA), as well as clearing the device and media library information. It
re-initializes the BRMS/400 files only with information on the tape units that are
currently configured on your system, resetting defaults as it does so. You should
review these defaults if you have implemented your own specific environment for
BRMS/400.
1. Media management
2. Backup
3. Archive
4. Recovery
10. Scheduling
11. Policy administration
12. Reports
Beginning with V3R2 and V3R7, an additional option was added to the BRMS/400
main menu (option 12; Reports) as shown in Figure 3. These reports include:
• Media expiration report (QP1AEP)
• Media report (QP1AMM)
• Media information report (QP1AHS)
• Media movement report (QP1APVMS)
• Media volume statistics report (QP1AVU)
• Saved objects report (QP1AOD)
• Link information report (QP1ADI)
• Recovery activities report (QP1ARW)
• Recovery analysis report (QP1ARCY)
• BRMS/400 log report (QP1ALG)
From this BRMS/400 main menu, you can “drill down” to the media management
functions, backup, archive, recovery, retrieve, scheduling, and report analysis
menus.
If you select F13 from the BRMS/400 main menu, you go to some of the
commonly used BRMS/400 functions as shown in Figure 4 on page 16.
1. Move management
2. Display log
3. Work with expired media
4. Save BRM save files to tape
5. Schedule BRM maintenance
6. Restart subsystems
7. Work with job scheduler
8. Duplicate media
9. Work with active jobs
10. Work with spooled files
11. Work with system status
12. Display system operator messages
Selecting F10 from the BRMS/400 main menu takes you to a list of all of the
BRMS/400 commands grouped by functional area (Figure 5). This is the
equivalent of typing GO CMDBRM on the command line.
Media commands
1. Add media to BRM ADDMEDBRM
2. Add media information to BRM ADDMEDIBRM
3. Add media library media to BRM ADDMLMBRM
4. Change media using BRM CHGMEDBRM
5. Copy media information using BRM CPYMEDIBRM
6. Display duplicate media DSPDUPBRM
7. Duplicate media using BRM DUPMEDBRM
8. Initialize media using BRM INZMEDBRM
9. Move media using BRM MOVMEDBRM
10. Print labels using BRM PRTLBLBRM
11. Print media movement PRTMOVBRM
12. Print media exceptions for BRM PRTMEDBRM
13. Remove media volumes from BRM RMVMEDBRM
More...
Alternatively, you can use the Select Command (SLTCMD QBRM/*ALL) command to
list all of the commands in library QBRM in an alphabetical sequence.
Finally, you can access BRMS/400 functions directly by explicitly entering the
menu name. For example, you can enter GO BRMSYSPCY to access the System
Policy Menu or the Work with Control Groups in the BRM (WRKCTLGBRM)
command.
The BRMS/400 functions for archive and retrieval are not covered here because
they closely follow the functions provided by the backup and recovery policies.
These are covered in 13.3, “Using BRMS/400 for hierarchical storage
management” on page 267.
This chapter does not cover the actual installation and configuration instructions
for using automated tape libraries with BRMS/400. See Chapter 7, “AS/400
hardware support for automated tape libraries” on page 151, and Chapter 9,
“Implementing automated tape libraries” on page 165, for information on using
automated tape libraries with BRMS/400. Where required, this chapter highlights
the importance of setting some of the parameters correctly if you have a media
library attached to your AS/400 systems. These parameters are discussed during
the various implementation stages throughout this chapter.
You should also review the BRMS/400 enhancements that are highlighted in
Appendix A, “Summary of changes” on page 289.
Before you start implementing BRMS/400, you should decide on the naming
conventions that you will use for your media policies, media classes, move
polices, volume identifiers, and control groups. The naming conventions become
more and more important when you use automated tape libraries along with
BRMS/400. See 2.1.3, “Media naming convention” on page 8, for more
information.
We recommend that you leave these defaults unchanged and create additional
storage location entries to match the additional locations that you want
BRMS/400 to manage.
Hint
If you have different types of media, you need to ensure that your System
Policy Home Location can accommodate all types. We recommend that you
specify a location other than the media library for the home location. If the
system identifies a mismatch on the media in the tape library, you want it to be
ejected and not “returned” to the library device.
The “Storage Location” in the media policy instructs BRMS/400 where to look for
a tape to perform your backup. Normally this is the scratch pool or the automated
tape library, but it can also be another location. The default for the storage
location parameter in the media policy is *ANY. You should review this parameter,
especially if you permit media to expire in a location other than the “home”
location so that BRMS/400 does not request the mount of a tape that is not even
on-site. If you have media libraries, you have to be careful how you specify the
storage location to ensure it only indicates tapes that are “inside” of the library.
If you have more than one library, or if you have stand-alone drives as well as a
library (for example, 3590 devices inside and outside a 3494 Automated Tape
Library Data Server), you need to ensure that neither requests the other's media.
You also need to ensure that the device description is updated to indicate its
location (for example, from *HOME to MLB01).
The “Home Location” on the move policy tells BRMS/400 where it should put the
tape when it completes the moves in the move policy. Typically, this is the
computer room or the scratch tape rack. If you use media libraries, it may be
returning from the vault to the library.
You can use the Work with Storage Locations (WRKLOCBRM) command to display the
storage locations that are defined for BRMS/400. The WRKLOCBRM command
can also be used to add, change, or remove storage locations. In addition, you
can work with media or containers that are in the storage locations by selecting
additional parameters when using the change option for a specific storage
location.
There are two important field parameters that you need to set correctly:
• Allow volumes to expire: Should be set to *NO for your off-site location. You
could select *YES for a storage location that is physically located near the
system such as the computer room or a tape library.
Note
A choice of *NO indicates that volumes whose retention period has passed
(as specified in the media policy) must be transferred to a location that
allows tapes to expire before the media can become eligible for reuse
(scratch).
For additional information, see Backup Recovery and Media Services for OS/400
(part of the IBM Online Library SK2T-2171).
At the time of installation, BRMS/400 determines the media libraries and tape
devices on your system and develops corresponding device information entries.
You should review these entries for accuracy and make any necessary changes
to reflect your device specifications as shown in Figure 8 on page 22.
The Work with Devices using BRM (WRKDEVBRM) command shows all of the
devices and their associated type and model that are defined to BRMS/400. This
command also allows you to add, change, or remove a device from a list of
devices that you want to use in BRMS/400 processing. If you are adding a device,
it must already be defined to the system through the device description
(CRTDEVD) function.
Beginning with V3R6, a new function key (F8) has been added on the
WRKDEVBRM display that allows you to access the Work with Configuration
Status (WRKCFGSTS) display.
When you add a device, you can specify both read and write densities for that
device. Most devices have the same read and write densities. However, such
devices as the 3490-B40 can read lower densities, but can only write in higher
densities.
QIC2GB
The reverse bold numbers that follow correspond to the reverse bold numbers
shown in Figure 8:
1 If, for example, COMPROOM is a defined location, you should change the
tape devices to be at the COMPROOM location rather than the default *HOME
location. If you have a media library device, such as a 3494 Automated Tape
Library Data Server, the Device location parameter should contain the same
name as the media library unit.
2 The Next volume message parameter specifies whether you want BRMS/400
to notify you through messages to place another tape into the device. For
media libraries (MLB), this parameter should be set to *NO.
3 The Auto enroll media parameter specifies if BRMS/400 should automatically
add media used in output operations to the media inventory if the operation
has been done using a BRMS/400 media class and is on this device. If you
specify *YES, the number of media volumes to be registered to BRMS/400 is
increased. This function is not available in V3R1.
4 The Shared device support parameter allows a tape device to be shared by
multiple systems. When you specify *YES for shared devices, the device is
varied on when the save or restore operation begins and is varied off when the
save or restore operation ends. You should leave this parameter to *YES if you
are planning to share a media library device with more than one AS/400
system. If the command that you are running specifies ENDOPT(*LEAVE), the
device is left in a varied on state after your request to save or restore is
complete.
See Appendix B, “Save and restore tips for better performance” on page 301, for
tips on save and restore performance. It also explains how you should set the
Data compression and Data compaction parameters on the save commands
when using various kinds of tape devices.
Note
All of the settings for devices (for example, shared device support, media
library devices, vary on or vary off, allocate unprotected, and so on) depend on
which libraries and which level of OS/400 are being used. See Chapter 9,
“Implementing automated tape libraries” on page 165, for additional
information.
Library type *USRDFN permits you to define third-party media libraries. For
information on third-party media libraries, refer to Backup Recovery and Media
Services for OS/400 (part of the IBM Online Library SK2T-2171).
At the time of installation, BRMS/400 creates media classes to match the tape
devices that you have installed on your system. The Shared media parameter is
set to *YES for these default media classes.
You may need to create extra media classes if you have tapes that are physically
different but can be read by the same tape drive. For example, a 120 MB ¼-inch
cartridge is classified differently than a 525 MB ¼-inch cartridge so you create
classes with meaningful names, such as QIC120 and QIC525, for each of these
cartridge categories.
BRMS/400 creates classes for all media types supported by the drive. The Work
with Media Classes (WRKCLSBRM) command can be used to add, change, or
remove media classes as shown in Figure 10.
When adding a media class, you must make the text field as descriptive as
possible because this field is shown on the WRKCLSBRM display. You should
also consider updating the additional options that are accessed through the F10
key. Using these options simplifies the maintenance of your tape library in the
future.
Hint
You should consider creating a user media class, such as USER3490, as the
default media class so unscheduled saves do not interfere with the regular
saves.
To update your container classes (Figure 11), you can use the command:
WRKCLSBRM TYPE(*CNR)
The Automatic unpack value (*YES) in Figure 11 breaks the link between the tape
volumes and the container. The media can be used and assigned to another
container. Likewise, other volumes can be assigned to the container. Automatic
unpack in the container class essentially moves the volume to container *NONE
when the volumes have expired. Note that if you move the container to be
3.8 Containers
If you created a container class, you can enroll the containers that you have.
When adding the containers to the BRMS/400 database, you need to specify the
container ID. This is a unique name for the container similar to the way you
specify a volume ID for a tape. You specify the class to which this container
belongs and also the current location of the container (Figure 12).
Add Container
Once you have added your containers, you can use the change option to change
various other parameters for your containers such as the move policy. The other
values used in the container definition are changed automatically when
containers are used and moved. You might want to manually change either the
container status or the move policy if a different container is used than is
recommended by BRMS/400. The Change Container option allows you to do this
so BRMS/400 knows about any changes you make (Figure 13).
Change Container
Container ID . . . . . . . . . . : QICCASE001
Container location . . . . . . . : *HOME
In this case, the home location is COMPROOM. Once you save data on the tape,
it is moved to the FIRESAFE. Five days later, the tape is moved to the VAULT.
The tape stays in the VAULT until it expires. Once the tape expires, it is returned
to COMPROOM for re-use.
10 FIRESAFE 5
20 VAULT *EXP
The reverse bold numbers that follow correspond to the reverse bold numbers
shown in Figure 14:
1 It is good practice to create your own “home” location for media. When
BRMS/400 detects an error in media movement, or when there is an anomaly
(for example, if the move policy for active media is accidentally deleted),
BRMS/400 moves the tape to default *HOME location as defined by the
system policy. Media found in the *HOME location can be easily distinguished
from normal moves to the storage location specified in the move policy.
2 You can confirm media moves automatically or manually for each move policy.
If you choose to confirm media moves automatically, BRMS/400 performs this
task for you when you set the Verify moves parameter to *NO. By setting the
parameter to *NO, the media is moved immediately as far as BRMS/400 is
concerned, although it may not have physically moved to the new location. If
you choose to confirm the media moves manually, you are supplied with a
Verify Media Movement display to confirm that media movement, scheduled
by BRMS/400 according to this move policy, is complete. You leave the Verify
moves parameter to *YES, which is the default. The decision to confirm moves
comes from two points:
We recommend that you leave the Verify move parameter set to *YES until you
are completely confident that media is also physically moved to the new location,
as indicated by the move policy.
There is no step defined in the move policy to return media to the home location.
When the move pattern is complete, the media moves to the home location
defined in the move policy. The ability to return to home location is important, for
instance, in the case of a media library device (MLB), where tapes are only
written to the MLB itself.
Hint
• The value you specify in the Duration field is important when you create a
move policy. Besides being able to enter the number of days or a specific
date that you want to keep the media in that particular location, you can also
specify *EXP (expire media) or *PERM (permanent retention in that
location). Move policy entries after a *PERM entry are ignored for move
processing since move policies move only active volumes that are not
assigned a permanent storage location. If you want to retain the volumes
permanently for audit records, you should specify *PERM in the duration
field.
• If you are planning to use APPEND(*YES) as part of your backup policy, you
must make sure that the move policy keeps the tape on-site for enough
days. See 3.13.1, “Appending to media rules” on page 44, for details on how
BRMS/400 selects volumes for append processing.
For additional information on using the Calendar options within a move policy,
see Backup Recovery and Media Services for OS/400 (part of the IBM Online
Library SK2T-2171) for your appropriate release.
Device Entry
- Type
- Attributes
Container
Container
Backup or Archive
Control Group
Attributes
- Media Policy
- Devie
We recommend that you create a media policy for every combination of retention,
media location, media class, or move policy that you plan to use.
With the installation of BRMS/400, there are three default media policies:
• FULL (35 days retention) with a move policy of OFFSITE
• INCR (incremental, 14 days retention) with a move policy of *NONE
• ARCHIVAL (1725 days retention) with a move policy of *NONE
Figure 16 on page 30 shows a change to the default media policy FULL to include
the MOVECOM move policy that we created earlier.
Important
Use care if you choose versions for retention of media. For example, assume
that you are saving *ALLUSR with a retention of three versions. After the
second save, you delete TESTLIB from your system. The next save does not
include TESTLIB and, therefore, this library never reaches the third version.
Media containing this library, therefore, normally does not expire.
To expire the media, you must use the Work with Media using BRM ( WRKMEDBRM)
command and select option 7 for the volume to expire the media. Alternatively,
you can use the Start Expiration for BRM (STREXPBRM) command as shown in
Figure 17.
Be sure to review these policies and update the values to suit your installation.
They can be accessed by selecting option 11 from the BRMS main menu. For
additional information, see the “Policy Administration” section in Backup
Recovery and Media Services for OS/400 (part of the IBM Online Library
SK2T-2171). Archive and retrieve policies are also discussed in 12.1.1, “How
archiving is done by BRMS/400” on page 217, and in 12.8, “Retrieval methods”
on page 231.
During the initial implementation of BRMS/400, you should review the system
policy and the backup policy to ensure that the default values match your backup
and recovery strategy.
For additional information and explanations for each of these items, see Backup
Recovery and Media Services for OS/400 (part of the IBM Online Library
SK2T-2171).
As the need for system availability increases, the window of opportunity for
backup decreases. Therefore, it may be necessary to schedule backups before
midnight that continue into the following morning.
The Day start time parameter in the System Policy allows you to change the start
of day from 0:00:00 to another time (for example, 06:00:00). Any media created
before the time set in this parameter is treated as having been created the
previous day. Therefore, this makes it much easier to run saves over midnight
and keep all of the media together when performing the movements.
You may want to create a special output queue for BRMS/400, such as
BRMOUTQ. You can then specify the new output queue in the system policy. This
way, all of your BRMS/400 related spooled files are directed to the BRMOUTQ
output queue.
Character representing
full backup . . . . . . . . . . . . F Character
Character representing
incremental backup . . . . . . . . . I Character
Character representing
general activity . . . . . . . . . . * Character
First day of week . . . . . . . . . . . MON SUN, MON, TUE...
Most users prefer Monday as the first day of the week. Therefore, the value
should be changed from SUN to MON (Monday).
As with the system policy, you can also change the backup policy to tailor some
of the parameters based on your backup strategy. For example, you may want to
save the information that forms part of your backup history at the object level
instead of the library level. You can do so by setting the Automatically backup
media information parameter to *OBJ as shown in Figure 20 on page 34. The
default is *LIB.
Important
Use this facility with care. As when working with a control group, it is easy to
overlook the fact that you have specified omissions in the policy.
Select option 2 from the BRMBKUPCY menu, and add or remove the libraries that
you want to omit as shown in Figure 21 on page 36.
In the example in Figure 21, all libraries beginning with TEMP are omitted from
the *ALLUSR backups. Also, if you are using BRMS/400 to save data to save
files, these files are placed in a library called Q1ABRMSFxx, where xx is the ASP
number in which the library is placed. When a control group containing the *IBM
special value is backed up to tape, this save file library is not included in the
save. Typically, you use the Save Save File using BRM (SAVSAVFBRM)
command to save the save files. They may also be quite large and can take much
time and media to back up. Therefore, you may want to omit this library from the
*IBM group using the method previously described. See 4.2.1, “Considerations
for libraries that affect BRMS/400” on page 65, for information on why the QGPL,
QUSRSYS, QUSRBRM, QMLD, and QUSRMLD libraries are not omitted from the
backup policy.
Special Operations:
*EXIT
*LOAD
A backup control group can include one or many of the items listed in Figure 22.
For example, it can be used to back up a single library, a group of related
libraries, a set of objects or folders defined by a Backup List, and certain
predefined components of the system such as configuration or security data. It
can also include special operations to tell the operator to load a new tape or
execute an exit program. This program can send a message to operations or
users, start a subsystem, or do anything you choose.
As part of the backup control group, you also must define a backup activity. The
backup activity identifies which days of the week the backup list performs a
backup and whether the backup is a full (save entire object) or incremental (save
changed object) save.
You can use the Work with Control Groups ( WRKCTLGBRM) command to access the
backup control groups on your system (Figure 23 on page 38).
Note
In the examples shown here, both of the displays are from a V4R2 system. In
V3R1, you may notice that the backup item of LINKLIST does not exist to save
IFS directories. For a workaround, see 6.6, “Saving and restoring V3R1 IFS
data with BRMS/400” on page 146. The LINKLIST backup item was added with
V3R2 and V3R6. In V3R7, the LINKLIST item was changed to *LINK. See 6.4,
“Saving IFS using BRMS/400” on page 137, for additional information on
saving IFS directories with BRMS/400.
Group . . . . . . . . . . : *SYSGRP
Default activity . . . . : *BKUPCY
Text . . . . . . . . . . : Entry created by BRM configuration
Figure 24. Backup control group *SYSGRP for backing up IBM data
Group . . . . . . . . . . : *BKUGRP
Default activity . . . . : *BKUPCY
Text . . . . . . . . . . : Entry created by BRM configuration
Figure 25. Default backup control group *BKUGRP for saving all user data
For your first backup, you should use the default backup control groups to
perform a full save. With the default control groups, you are not able to hold a job
and release certain job queues or subsystems, or save your spooled files. You
have to either change the default control groups or create your own to tailor how
you want to manage your system during a BRMS/400 save. It is important to
understand that BRMS/400 does not put the system in a restricted state when it
performs an *ALLUSR save. It is equally important to understand which of the “Q”
libraries are considered to be user libraries when you perform an *ALLUSR or
*ALLPROD save operation. Table 2 on page 40 contains a list of libraries that are
considered as part of an *ALLUSR or *ALLPROD save under BRMS/400.
To avoid conflicts with library locks, we recommend that you end all of the
subsystems prior to starting the *BKUGRP saves. If you have an Integrated PC
Server (FSIOP), you should also vary this off before you start the save.
Hint
A change was made to BRMS/400 implementation to allow for a native RSTLIB
LIB(*ALLUSR) operation to work when the QGPL, QUSRBRM, and QUSRSYS
libraries span across multiple volumes. The following BRMS/400 PTF is
required for your appropriate BRMS/400 release:
• V3R1 - SF37714
• V3R2 - SF37715
• V3R6 - SF37716
• V3R7 - SF37718
When you apply the PTF, BRMS/400 will save the QGPL and QUSRSYS
libraries during the *ALLUSR or *ALLPROD save. It will no longer separate
these libraries and save them ahead of other libraries. The QUSRBRM library
will be saved at the end of your control group, unless it is being omitted. See
the PTF cover letter for additional information.
See 4.2, “Setting up your own control groups” on page 64, for additional
information on creating your own control groups.
From the Work with Backup Control Groups display, select F9 to go directly to the
Job Queues to Process display (Figure 26). Enter the values for BRMS JOBQ as
shown in Figure 26. You must ensure that the BRMS JOBQ is created on your
system and that you have added a job queue entry to your default batch
subsystem description. In most cases, this is the QBATCH subsystem.
Use . . . . . . . . . : *BKU
Control group . . . . : WKLIBM09
Another area for special attention is when a control group specifies a weekly
activity that, for example, excludes Mondays, and that control group is run on a
Monday.
Note: The subsystems are still brought down even though there is no subsequent
save.
Beginning with V3R6 and V3R2, BRMS/400 provides enhanced subsystem and
job queue processing that addresses these challenges.
It is now possible to end a subsystem in one control group, but not to restart it
until a subsequent control group has been processed. This also applies to job
queues to be held and released.
From the Work with Backup Control Groups display, go to your backup control
group and select option 9 to create a list of subsystems that you want the control
group to process.
Figure 27 on page 42 shows how you can end the subsystems at the start of one
control group (EDELM09) and restart them when you have completed processing
another control group (SAVIFS).
Use . . . . . . . . . : *BKU
Control group . . . . : EDELM09
Subsystems QINTER and QCMN are ended by backup control group EDELM09
1. They will remain ended after the control group has finished processing (Figure
28).
Use . . . . . . . . . : *BKU
Control group . . . . : SAVFIFS
The backup control group SAVIFS will restart subsystems QINTER and QCMN
after it has finished processing 2.
The backup control group SAVIFS also has an additional subsystem to end
(QSERVER) and restart after it has finished processing 3.
You now need to ensure that your backup control group attributes are set
correctly, as per your backup and media policies. From the Work with Backup
Control Groups display, select option 8 for your backup control group. This brings
up the Change Backup Control Group Attributes display shown in Figure 29.
Group . . . . . . . . . . . . . . . . : WEEKLY09
You should change the Media policy for full backups, Media policy for incremental
backups, and the Backup devices parameters to the appropriate values. In our
example, we used WEEKLY09 for the media policy and *MEDCLS for the backup device
values.
Additional options for the backup control group attributes are discussed in 4.2.6,
“Backup control group attributes” on page 69. Review these options and set them
appropriately to reflect your installation requirements.
Media can be enrolled into the BRMS/400 media inventory at any time. The only
requirement is that the media must be known to BRMS/400 prior to any save or
restore operation.
Additional Parameters
You can also use the ADDMLMBRM command as described in Figure 136 on page
188. You need to decide whether you want to initialize the media during
enrollment. This is done using the Initialize tape parameter on both commands.
Note
Beginning with V3R7, you can perform a DSPTAP operation to an output file as
long as you use *LABEL information only. The output file option is not valid for
the *SAVRST option.
With the ADDMEDIBRM command, you have to manually enter data for each
sequence number that appears on the tape or on the printout as shown in Figure
31 on page 46.
You need to perform the following steps to record media content information
using the ADDMEDIBRM command:
1. Use the DSPTAP command with DATA(*SAVRST) to produce a printout of your tape
volume for reference.
2. Add your media to BRMS/400 using the ADDMEDBRM command.
3. Run the ADDMEDIBRM command. Specify the name of the tape drive where the
volume is, the saved library name, the file origin, date and time of the save,
and the number of objects saved. This is where you have to check your
DSPTAP report listing to see how your libraries were saved, the sequence
number, the number of objects that were saved, and the date and time they
were saved.
You have to use this command for every library or sequence number that is on
the saved tape.
4. Check the media contents information after the ADDMEDIBRM command has
completed using WRKMEDBRM command or WRKMEDIBRM command.
5. Move the media to the appropriate storage location.
You cannot use the ADDMEDIBRM command to add media contents information
for a volume that contains active files or that is not expired.
The BRMS/400 recovery reports will include information so that you can use the
media for recovery purposes.
Note
Although the media information is not recorded within BRMS/400 when your
job terminates, the data on your saved media can still be accessed for recovery
purposes using OS/400 native restore commands. You must understand the
sequence in which BRMS/400 had saved your libraries to recover from the
tapes. You must plan this thoroughly.
Important
At the time this redbook was written, the EXTMEDIBRM command registered
the media content information as *FILE, instead of using *FULL, *INCR,
*CUML, and so on. You cannot recover data that has a save type of *FILE, with
no saved objects in it. BRMS/400 recovery will be enhanced so that it will allow
you to recover *FILE save types at a future date. Until then, you must not use
the EXTMEDIBRM command.
The *SYSGRP control group contains the *SAVSYS and *IBM special values that
save OS/400 and IBM Licensed Program Products (mostly, the Q-libraries). It
also includes *SAVSECDTA and *SAVCFG data.
The contents of *SAVSYS and *IBM change infrequently, usually only when:
• Applying PTFs
• Adding a new program product
• Performing a release upgrade
The *SAVSECDTA command and *SAVCFG values can be run separately and do
not require restricted state processing. They should be scheduled frequently.
Restricted state saves, such as the *SAVSYS save, must be run from the system
console. Beginning with V3R2 and V3R6, the console monitor function allows
saves to be run in a secure unattended mode. See 4.5, “BRMS/400 console
monitor” on page 87, for information on how you can use console monitoring to
schedule unattended saves. Prior to this function, you were unable to schedule
unattended saves without security exposures. For example, if the console is left
unattended, there is nothing to stop someone from issuing the ENDRQS
command (ALT and SYSREQ keys) and obtaining access to a command line.
Control group *SYSGRP should use a media class with the Shared media
parameter set to *NO. The reason for this is because the network media inventory
cannot be updated when a system is in a restricted state (communication links
that are at a varied on status to manage media integrity). Selecting SHARE(*NO)
prevents accidentally overwriting of active tape volumes.
To invoke a backup using BRMS/400, you can issue any of the save commands
such as:
• Save DLO using BRM (SAVDLOBRM)
• Save Folder List using BRM (SAVFLRLBRM)
• Save Library using BRM (SAVFLRBRM)
• Save Object using BRM (SAVOBJBRM)
• Save Object List using BRM (SAVOBJLBRM)
• Save Save Files using BRM (SAVSAVFBRM)
Your media inventory is now managed through BRMS/400, set by the Media
monitor parameter in the system policy. Although you can still use the native save
commands, such as SAVDLO, SAVLIB, SAVOBJ, and so on, we recommend that
you perform all of your save operations using BRMS/400 commands at all times
unless there are exceptions. For example, you can use the native save
commands to save objects for distribution using SNADS. You can also use the
ObjectConnect commands to perform concurrent save and restore operations on
your target system. The ObjectConnect method can be faster and requires less
setup time. See Upgrading to Advanced Series PowerPC AS, SG24-4600, or
Backup and Recovery - Basic, SC41-4304, for V3R7, for more information on
ObjectConnect.
Another important factor to saving your system using BRMS/400 is the availability
of media in the right class. You must ensure that you have enough save media
(also sometimes known as scratch volumes) before you begin the save operation.
Beginning with V3R2 and V3R6, you can use the Check Expired Media for BRM
(CHKEXPBRM) command to check that you have sufficient media for your
backups based on the media class or media location. You can run the
STRBKUBRM command for a particular backup control group. In our example,
we used the backup control group of SETUPTEST that contains some user
libraries for test purposes (Figure 32). We recommend that you perform a total
system save using BRMS/400.
------------------------------------------------------------------------------
Volume D09002 expired.
Begin processing for control group SETUPTEST type *BKU.
Selecting devices with density *QIC120 for control group SETUPTEST type *BKU.
Devices TAP01 will be used for control group SETUPTEST type *BKU.
Interactive users are allowed to stay active.
Starting SAVSECDTA to device TAP01.
All security objects saved.
Save security data (SAVSECDTA) complete.
Starting save of library A960103D to devices TAP01.
8 objects saved from library A960103D.
Control group SETUPTEST bypassed automatic save of media information.
SETUPTEST *BKU 0030 *EXIT SNDMSG MSG('Backup SETUPTEST ENDED') TOUSR(*SYSOPR)
Control group SETUPTEST type *BKU processing is complete.
Last run date for BRM maintenance was 06/05/00.
Hint
A PTF is provided to include all CPF37xx messages in the BRMS/400 log.
These messages provide information on objects that are not saved. Without
these PTFs, you either have to retain object-level information on the backup
control group, or review the system job log. The PTFs, which were correct at
the time this redbook was published, include:
V3R1 SF33794
V3R2 SF33795
V3R6 SF33797
V3R7 SF33798
Note: Providing this information may affect system performance. If you want to
disable this function, you may do so by typing a '1' in position 213 of the
Q1APRM data area in the QUSRBRM library. You can re-enable this function
by changing position 213 of the data area back to ' ' (blank) as shown in the
following example:
Backup
Seq Items Exit command
The Recovery Analysis report is printed by default with the Start Maintenance for
BRM (STRMNTBRM) command. The recovery analysis report can also be
generated by the Start Recovery using BRM (STRRCYBRM) command. It is good
practice to run these reports at the end of the daily save and to include the most
up-to-date recovery analysis report with the media when you move your system
backup off-site. See 10.1.1, “Synchronizing maintenance, movement, and
recovery reports” on page 193, for additional information.
It is also possible to run media movement using the Run media movement
parameter during the maintenance. However, for several reasons, particularly in a
networking situation, you should avoid setting this parameter to *YES. The media
movement is done separately using the Move Media (MOVMEDBRM) command.
In a complex BRMS/400 environment with many daily changes, performing the
STRMNTBRM command with MOVMED(*YES) can also take some time to
complete (Figure 34). See 4.1.5, “Moving media” on page 60, for more
information on media movement.
If you decide to manually verify media movement by setting the Verify moves
parameter to *YES in your move policies, you should use the Verify Media Moves
( VFYMOVBRM) command (Figure 35).
Position to Date . . . . .
It is worth noting that the WRKMEDIBRM display shows the most recent entries
by save date and time on the display. That is, it positions itself at the bottom of
the list. You must page back to see earlier backup activity. You can also produce
a report by specifying OUTPUT(*PRINT) for the WRKMEDIBRM command.
Note
If your backup control group processing ends abnormally, you may find that
some of the entries for the Type value in the Work with Media Information
display is set to *FILE. When you display these entries, they will have a value
of zero for the number of objects saved. At present, BRMS/400 does not allow
for *FILE entries to be recovered, and you media volumes will not appear on
the Recoverying Your Entire System report. We recommend that you restart the
control group save again. See 3.13.3.1, “The ADDMEDIBRM command” on
page 45, for more information on recovering from control groups that have
terminated abnormally.
You can also use the WRKMEDBRM command to display or print the current status of
your media inventory as shown in Figure 37. You can selectively display or print
volumes that are active, expired, or both. You can use this display to change the
media class of your tapes or display the contents of your tapes. This display can
also be used to list the tapes that have expired and are available for re-use.
You should also use the Display Backup Plan (DSPBKUBRM) command to display a
summary of all of your backup control groups that you set up and the backup
items that you specified for each of your backup control groups as shown in
Figure 38.
This report should be produced after the daily movement procedures are
completed.
With libraries, such as the 3494 Automated Tape Library Data Server, you
depend on scratch media being inside the library when BRMS/400 requests it. If
moves are being performed correctly, this should always be the case. However,
sometimes cartridges are manually ejected, and the BRMS/400 records are not
updated to reflect this move. When this happens, the Library Manager and
BRMS/400 become out of synchronization. It is worth checking before each
backup to see that the two databases agree. You can do this by running the
WRKMEDBRM and WRKMLMBRM commands and comparing the outputs.
However, this can be quite a task if you have a large library. See Appendix E,
“Media missing from the 3494” on page 309, for a sample program and query that
you can use to more easily highlight the differences.
For attended saves, you can use the Start Backup using BRM ( STRBKUBRM)
command and select the backup control groups that you want saved. For saves
that are submitted to a job scheduler, check to ensure that the save job has been
submitted and that it is in an active state.
However, since SAVSAVFBRM did not save the recovery information, if you
perform a recovery using BRMS/400, BRMS/400 prompts you for save files or for
different tapes than those in your recovery report. That is because BRMS/400 is
using the older version to recover. Also, if you did not create a new recovery
report after you ran the SAVSAVFBRM command, your recovery report indicates
that certain objects were in save files (now gone), and you have to find the
objects on the tape.
You must always run the SAVMEDIBRM command after you perform the
SAVSAVFBRM command and produce a new recovery report. See 10.1,
“Overview of BRMS/400 recovery” on page 191, for additional information.
The rules for moving media are defined in the move policy. The instructions for
moving media are produced when the Move Media using BRM (MOVMEDBRM)
command is performed, either as part of maintenance or on its own. Each time
media movement is run, BRMS/400 calculates in which location the media should
be (according to the move policy), checks the location where it actually is, and if
the two are different, issues a move request to move the media to the correct
location.
Media can be moved using option 8 on the Work with Media using BRM
(WRKMEDBRM) command. However, if the media is under control of a move
policy, the next time the MOVMEDBRM command is run, an instruction may be
issued to move it back. This sort of situation can occur if media is retrieved from
another location to restore objects from it.
If you are confident that media moves scheduled by the MOVMEDBRM command
are always physically carried out, you can choose to have the media location
updated when the MOVMEDBRM command is run. However, we recommend that
you choose the option to Verify Media Movement before you update the
BRMS/400 records. This can be done by running the Verify Moves using BRM
(VFYMOVBRM) command and confirming that the media has actually been
moved.
If you have a media library, running the MOVMEDBRM command causes the
RMVTAPCTG command to be issued to the library to eject the cartridge.
Depending on the library type, and whether the system is a CISC or a RISC
system, this may physically eject the cartridge or merely change its category to
*EJECT.
BRMS/400 is shipped with this value set to blank. To find out which value you are
currently using, use the command:
DSPDTAARA DTAARA(QUSRBRM/Q1APRM)
Using the data area and Verify Moves *YES/*NO provides four setups:
• Q1APRM blank, verify moves *NO: Volumes that are scheduled to leave the
MLB are ejected when the MOVMEDBRM command is run and they are
“moved” in the BRMS/400 database. Volumes that are scheduled to return
need to be physically placed into the library prior to the move being run. Once
inserted, they have a category of *INSERT and when MOVMEDBRM is run,
they are changed to *NOSHARE or *SHARE400 depending on the value in the
Shared media parameter on the media class.
• Q1APRM blank, verify moves *YES: Volumes that are scheduled to leave
the MLB are ejected when the MOVMEDBRM command is run. However, they
are not moved in the BRMS/400 database until the Verify Moves using BRM
(VFYMOVBRM) command is run. For volumes that are scheduled to return,
the MOVMEDBRM command is run first. The volumes need to be physically
placed into the library. Once inserted, they have a category of *INSERT. When
the VFYMOVBRM command is run, they are changed to *NOSHARE or
*SHARE400 depending on the value in the Shared media parameter on the
media class.
• Q1APRM '1', verify moves *NO: This setup operates in exactly the same way
as the first setup in this list.
• Q1APRM '1', verify moves *YES: The MOVMEDBRM command is run first,
which sets the volumes that are scheduled to leave the MLB up for
verification. When the VFYMOVBRM command is run, the volumes are
ejected and moved in the BRMS/400 database. For volumes that are
The MOVMEDBRM command can be run on any system in a network, and the
resulting database updates are propagated around the network. It is clearly not
desirable to have all systems moving media for all systems so either movement is
run on each system for that system's media only, or movement is run on one
system in the network for all systems.
We recommend that you run the Move Media using BRM ( MOVMEDBRM) command
separately on each system. This is accomplished by specifying *LCL in the
SYSNAME parameter of the MOVMEDBRM command.
You can run the MOVMEDBRM command on a “central” BRMS/400 system for all
systems. This is a practical solution for many enterprises. However, if you have
more than one tape library, and they are attached to different systems, you must
run the command separately. The reason for this is that although the
MOVMEDBRM command updates the BRMS/400 files for all systems, the
associated RMVTAPCTG command only ejects cartridges on the library attached
to the “central” system.
The operations tasks associated with moving media include printing reports,
physically moving the media, and if required, verifying that the media has been
moved. These tasks may be summarized as follows:
• Reports: Prior to performing any physical tape movement, direct the required
reports (some of which may have been produced earlier) to an appropriate
output queue and print them.
In a networked environment where the individual processes can be scheduled
and controlled as a single procedure, the controlling job should distribute the
Recovery Volume Summary Report and the Disaster Recovery Report directly
to the central system for printing. This is achieved using the Send Network
Spooled File (SNDNETSPLF) command over SNA distribution services
(SNADS). This way, each system also keeps copies of the two recovery
reports for possible reference during an emergency.
REPORT NAME CONTEXT SPLF NAME PRODUCED BY
For media libraries, such as the 3494 Automated Tape Library Data Server or
where the home location is convenient to the tape drive, this is a question of
having sufficient quantities of usable media. Where the media is stored
elsewhere (for example, in a fireproof safe or off-site), it is also a question of
selecting and moving the media.
In V3R6, V3R7, and V3R2, two new parameters on the Media Policy influence
media management. The Required volumes parameter ensures that the save
does not start if there are fewer media available than indicated. The Mark
volumes for duplication parameter causes media to be duplicated when the
DUPMEDBRM command is run with the VOL(SEARCH) option.
To be certain that you have sufficient media, the value can also be checked by
user jobs using the Check Expired Media for BRM (CHKEXPBRM) command. For
example, the CHKEXPBRM command can be incorporated into a job scheduler to
determine, at various times, if there are enough expired media volumes available
for a save operation. Figure 39 shows how the CHKEXPBRM command checks
for a specific number of volumes.
Figure 40. The message indicating that the request was successful
Although you should always monitor for the availability of media volumes, there
may be times when additional volumes need to be introduced to complete the
save.
Automatic enrollment of media allows you to automatically add new media used
in output operations to the media inventory if the request has been done using a
BRMS media class and is on this device.
To enable this function, set the Auto enroll media parameter to *SYSPCY or *YES in
the BRMS/400 device description. If you are enabling this globally, you should set
the Auto enroll media parameter in the system policy to *YES.
You should also ensure that you have enough licenses to allow for any additional
media.
Note: If you are using a media library, such as the 3494 Automated Tape Library
Data Server, automatic enrollment of media during a save operation does not
occur because BRMS/400 has to specify a volume to be mounted.
One reason is to provide the flexibility to start and stop various subsystems, hold
job queues, save spooled files, or even use the save-while-active function to
perform some of your backups. Another reason is to satisfy requirements to
perform different tasks at different times (daily, weekly, at period end, and so on).
We recommend that you do not change the default BRMS/400 control groups.
You should first copy them and change the new control groups, rather than
making changes to the original control groups.
There are also logical files and out files used for communications to the 3494
Automated Tape Library Data Server.
Use the WRKCTLGBRM command to create a backup control group called WKLIBM09
as shown in Figure 41.
Group . . . . . . . . . . : WKLIBM09
Default activity . . . . : *BKUPCY
Text . . . . . . . . . . : M09: Weekly Save Control Group
It is also important to ensure that you omit libraries that are saved as part of
*ALLUSR, when you are planning to save them outside the *ALLUSR control
group entry.
In the example in Figure 41, notice that sequence number 100 is added to save
spooled files. In our example, we used a backup list called SAVEOUTQ that
contains a list of output queues that are specified as sequence numbers, which is
the same as the exit programs. You can have multiple output queues within one
backup list item. For additional details on how to use BRMS/400 for spooled file
saves, see 4.4, “Saving spooled files using BRMS/400” on page 84.
If you plan to perform the restore using BRMS/400, the restore is seamless.
However, if you plan to perform the restore operation outside BRMS/400, such
as using the OS/400 native RSTLIB LIB(*ALLUSR) command, you do not
recover libraries QGPL, QUSRSYS, and QUSRBRM. These libraries were
saved separately so you must restore them separately.
TOUSER(*SYSOPR)
Tab down to each user exit sequence number that you have specified, and use
F10 to assign a command that you want to process. The commands that are
executed by the remaining sequence numbers in our WKLIBM09 backup control
group are:
Seq No. Command
------- ------------------------------------------------------
120 SBMJOB CMD(STRMNTBRM) JOB(STRMNTBRM) JOBQ(BRMSJOBQ) OUTQ(BRMSOUTQ)
130 SBMJOB CMD(DSPLOGBRM OUTPUT(*PRINT)) JOB(DSPLOGBRM) JOBQ(BRMSJOBQ)
OUTQ(BRMSOUTQ)
140 SBMJOB CMD(PRTMEDBRM VOL(*EXCP)) JOB(PRTMEDBRM) JOBQ(PRTMEDBRM)
OUTQ(BRMSOUTQ)
The above example includes various exits that make up a series of commands
that are executed after the saves have completed. Rather than specifying a
series of user exits, you may want to create a simple CL program that includes all
of the commands that you want to process and include this CL program as a
single user exit.
The same as a post-processing exit, you can also add a preprocessing exit. See
Figure 45 on page 76 for an example.
For example, if you have a 3494 Automated Tape Library Data Server installed on
a CISC system, you probably have made a special provision for backing up
critical QMLD and QUSRMLD libraries together with the QGPL, QUSRSYS, and
QUSRBRM libraries. See 4.2.5, “Control group to save QMLD and QUSRMLD” on
page 68, and Appendix D, “Performing restricted saves to a 3494 on CISC” on
page 305, for more information on this. It is not necessary to back them up a
second time as part of *ALLUSR, so they should be omitted.
Use F10 from the Work with Backup Control Groups display to go directly into
Work with Libraries to Omit from Backups display shown in Figure 43.
*ALLUSR QGPL
*ALLUSR QUSRBRM
*ALLUSR QUSRSYS
*IBM QMLD
*IBM QUSRMLD
The *EXIT does not have anything in it. It is there in case you want to specify
other libraries after QUSRMLD. In that case, the *EXIT causes BRMS/400 to start
a new SAVLIB, and locks on key files are minimized. When *SAVSYS has
completed, BRMS/400 starts QMLDSBS. This may cause some object locks in
QMLD and QUSRMLD, but the significant objects are saved. See Appendix D,
“Performing restricted saves to a 3494 on CISC” on page 305, for information on
how to save using the 3494 Automated Tape Library Data Server while the
system is in a restricted state.
If the BRM commands are used in a CL program, use the following commands
(use the DEV and MEDPCY parameters as appropriate):
SAVSYSBRM DEV(xxxxx) MEDPCY(xxxxxx) STRCTLSBS(*NO)
STRCTLSBS(*NO)
SAVLIBBRM LIB(QMLD QUSRMLD) DEV(XXXXX) MEDPCY(XXXXX)
SEQNBR(*END)
The backup control group attributes allow you to add backup information (for
example, media policies and devices to use) and to override the default backup
policy settings based on your overall backup and recovery strategy. Some of the
attributes require careful planning before they are changed either in the backup
control group attributes or in the backup policy. The key attributes are:
• Media Policy: Enter here the media policies, full and incremental, that you
want to use for this control group.
• Backup devices: Backup devices specify the name of the backup device you
want to use for this control group. You can specify up to four backup devices.
If more than one device is specified, they must have the same characteristics.
This feature is less widely used now that tapes are written in both directions
(no rewind time) and when successive tapes can be automatically loaded by a
tape drive in sequential or random mode, or by an automated tape library. The
*MEDCLS special value specifies that any available device that supports the
media class specified in the media policy may be selected. BRMS/400
searches for a device alphabetically according to the BRMS/400 Device Table.
• Sign-off interactive users: This is useful to advise users that a backup is
about to take place and to sign them off. You can specify exceptions to this,
either devices or users, in the system policy. Messages can be issued at five
Note
If you select the *OBJ parameter for the Automatically backup media
information field, you should ensure that you are saving objects at the
object level in your control groups. To verify whether you are saving at the
object level, go to the Edit Backup Control Group display for the control
group, and review the Retain object detail field for each backup item. Those
backup items that show *YES, *OBJ, or *MBR in the Retain object detail
field keep object detail. Additionally, those items that do not display a Retain
object detail field indicate that object-level detail is automatically kept.
The following files are also saved if you save object-level information:
QA1ADI IFS directory information
QA1ALI IFS object link information
QA1AOD Object detail
If your application does not use journaling or commitment control, and for ease of
recovery, we recommend that you shut down your application until a
save-while-active synchronization (also known as checkpoint) is reached. Once
synchronization is reached, the system releases the exclusive locks on the library
you are saving, and users can resume normal activity. The system continues to
save the data to a tape device as a background task. This is where you benefit
most from the save-while-active function. The data in your library can be used by
your users without having to wait until the entire library is saved on a tape device.
The gain is the time it takes to write your data to the tape device from the point of
reaching synchronization.
In general, if you have large libraries with single member physical files, the time
to establish the checkpoint can be small compared to the time to write to the tape.
For example, assume that the entire save takes one hour at present, and the
library contains single member physical files. Without the save-while-active
function, the entire library is locked for one hour and users are not allowed to use
any file in that library until the save is complete. With the save-while-active
function, you may find that the checkpoint is established within 20 minutes, for
example.
You can monitor for the checkpoint message and allow users to continue using
the files in the library. This increases your application availability by 40 minutes.
BRMS/400 also provides the Monitor Save While Active for BRM (MONSWABRM)
command that can be used through an exit in the control group. This command
monitors for checkpoint messages and allows you to process another command,
once the checkpoint message has been monitored. For example, you can restart
a subsystem or an application or send a message to your users indicating that
activity related to the application can be restarted. See 4.3.3, “Using the
MONSWABRM command” on page 75, for more information. Figure 44 shows an
example of creating an *EXIT on the Edit Backup Control Group Entries display.
Group . . . . . . . . . . : SWA
Default activity . . . . . *BKUPCY
Text . . . . . . . . . . . Save While Active Control Group
10 *EXIT *DFTACT 2
20 *EXIT *DFTACT 3
30 LIBA FFFFFFF *NO *SYNCLIB *LIB
40 LIBB FFFFFFF *NO *SYNCLIB *LIB
50 *EXIT
Figure 44. Edit Backup Control Group Entries display: Creating an *EXIT
Refer to 4.3.5, “Examples of using save while active with BRMS/400” on page 78,
for more information. This section addresses several examples of using the
save-while-active function with BRMS/400, including the use of the
MONSWABRM command.
Note
Only physical files with members have the same save active date (and time)
time stamp. Libraries with thousands of objects may be too large for this
option.
• *SYNCLIB: Objects in a library can be saved while they are in use by another
job. All of the objects and all of the libraries specified within a backup control
group reach a checkpoint together and are saved in a consistent state in
relationship to each other.
If you use *SYNCLIB for saves within a BRMS/400 control group, and the
media policy specifies that the saves are to be done to save files, you need to
understand the following points:
– When saving to save files, OS/400 restricts you to save a single library to
save files. BRMS/400 adopts the same restrictions.
– The control group uses *LIB level synchronization instead of *SYNCLIB.
Notes
• *SYSDFN: Objects in a library can be saved while they are in use by another
job. Objects in a library may reach checkpoints at different times and may not
be in a consistent state in relationship to each other. If you are going to use
the Monitor Save While Active for BRM (MONSWABRM) command to perform
operations when a checkpoint has been reached, the *SYSDFN option may
not be convenient to use. You cannot be sure which database network within a
library has reached a checkpoint. This makes it difficult to release the library to
users for normal work.
Note: Specifying this value eliminates some size restrictions and can allow a
library to be saved that cannot be saved with SAVACT(*LIB). However, there is
a concern with the ability to recover to a known state.
Figure 45 on page 76 shows you an example of how you can use the
MONSWABRM command through an exit from the control group.
Sequence number . . . . . . . : 20
Where used . . . . . . . . . : *EXIT
Weekly activity . . . . . . . : *DFTACT SMTWTFS
Command . . . . . . . . . . . . MONSWABRM LIB(LIBA) CMD(STRSBSBRM GROUP(SWA
))
F4
You can use the LIB parameter to specify the message queue that you are
monitoring for synchronization messages to arrive. You can also specify a value
of *MSGQ, followed by specifying the name of the message queue in the MSGQ
parameter. The *MSGQ value and the MSGQ parameter are not available in
V3R1.
You can use the CMD parameter to execute a command, once the
synchronization message has arrived. In the preceding example, we chose to run
the Start Subsystem using BRM (STRSBSBRM) command after synchronization
occurred for the libraries we are saving. This makes it possible to quiesce an
application only until synchronization has occurred. It also makes it available to
end users while the save process continues writing data to tape.
Note
Instead of the STRSBSBRM command, you can use the native STRSBS
command, in which case you specify the name of the sybsystem to be started.
The advantage of the STRSBSBRM command over STRSBS is that you do not
need to remember which subsystems need to be restarted. BRMS/400
automatically restarts those subsystems that it had ended prior to starting the
control group processing. These subsystems are specified as part of the
control group setup.
If you split the library by using special operations, such as an *EXIT or a *LOAD,
BRMS/400 processes the sets separately as shown in Figure 46.
10 *EXIT *DFTACT
20 LIBA FFFFFFF *NO *SYNCLIB *LIB
30 LIBB FFFFFFF *NO *SYNCLIB *LIB
40 *EXIT
50 LIBC *DFTACT *YES *SYNCLIB *LIB
60 LIBD *DFTACT *YES *SYNCLIB *LIB
In the example in Figure 46, libraries LIBA and LIBB are synchronized together.
Libraries LIBC and LIBD are synchronized later. The *EXITs each perform a
MONSWABRM command, which monitors for the synchronization point. LIBA is
used for the first set, and LIBC is used for the second set for save-while-active
synchronization point messages.
Important
In this example, the SWA Message Queue value in the control group is left as
*LIB. Because of this, it is important that you use the name of the first library in
the LIB value for the MONSWABRM command. If you use a name other than
the first library name, the MONSWABRM command cannot monitor for the
save-while-active synchronization message. In the meantime, your control
group has already finished processing, and you do not benefit by using the
save-while-active message queue function.
One of the advantages of splitting the libraries into two sets is that it allows you to
specify different weekly activity or retain object detail information for LIBA and
LIBB compared to LIBC and LIBD.
If you use generic names for the libraries, such as A*, B*, and C*, and you specify
*SYNCLIB, BRMS/400 groups all of the libraries together and performs a single
save operation. You receive a single synchronization message. A single save
command supports up to 300 libraries to be entered as a list. This is an OS/400
restriction. If you have more than 300 libraries, BRMS/400 issues another save
command to process the remaining libraries.
Note
By default, the MONSWABRM command waits for 3600 seconds (one hour) for
the synchronization message issued by the system. You must ensure that you
increase the save-while-active wait time in the MONSWABRM command if your
libraries require over one hour to reach synchronization. Remember that, in the
release covered in this redbook, OS/400 has a restriction of up to 300 libraries
that can be specified in the list of libraries to be saved. If your list of libraries is
*ALLPROD or *ALLTEST, or if the number of generic libraries exceeds 300,
BRMS/400 issues another save command to save the remaining libraries.
4.3.5.1 Example 1
This example is for V3R1 of BRMS/400. It does not contain the SWA Message
Queue field on the control group, and the MONSWABRM command does not
have the MSGQ parameter or *MSGQ value for the LIB parameter. Figure 47
shows you how to save all of the libraries specified within your backup control
group with a single save command. The synchronization point is monitored by the
MONSWABRM command.
When you submit the save of the preceding control group, BRMS/400 first
acquires a volume and begins control group processing. It submits the
MONSWABRM job in QBATCH subsystem. The MONSWABRM command
creates a message queue of LIBA 2 in library QUSRBRM and waits for the
system to send a message when the synchronization point is established by the
libraries in the control group. It waits for a default of one hour for a message to
arrive. The job goes into a MSGW status.
BRMS/400 checks the control group entries and sees that they are all identical for
1 *SYNCLIB processing. It builds a list of libraries to be submitted internally to the
save process. In this example, a single synchronization point is established. The
system sends the synchronization message to LIBA message queue. The
MONSWABRM command receives this message queue and processes the
command specified in the CMD value. The MONSWABRM command deletes the
message queue it created in QUSRBRM and ends the job.
When you perform a full save, BRMS/400 always uses the first library name as
the message queue that receives the synchronization message. Therefore, it is
important that you use the first library name in the 2 MONSWABRM command.
4.3.5.2 Example 2
This example shows you how to obtain synchronization messages for every
library that you save in your control group. This example assumes that you are
performing a full save. The MONSWABRM command is used for monitoring
synchronization messages (Figure 48).
10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 LIBA *DFTACT *NO *LIB ACCOUNTS
40 *EXIT *DFTACT
50 LIBB *DFTACT *NO *LIB SALES
60 *EXIT *DFTACT
70 LIBC *DFTACT *NO *LIB PAYROLL
80 *EXIT *DFTACT
90 LIBD *DFTACT *NO *LIB MFG
The exits have the following settings for the MONSWABRM command:
20 - MONSWABRM LIB(ACCOUNTS)
CMD(SNDMSG MSG('Account Libraries have been synchronized.')
TOUSR(*SYSOPR))
40 - MONSWABRM LIB(SALES)
CMD(SNDMSG MSG('Sales Libraries have been synchronized.')
TOUSR(*SYSOPR))
60 - MONSWABRM LIB(PAYROLL)
CMD(SNDMSG MSG('Payroll Libraries have been synchronized.')
TOUSR(*SYSOPR))
80 - MONSWABRM LIB(MFG)
CMD(SNDMSG MSG('Manufacturing libraries have been synchronized.')
TOUSR(*SYSOPR))
For example, when the LIBB is synchronized, OS/400 sends the synchronization
message to message queue SALES. The SALES message queue is monitored by
the MONSWABRM command and is created in the QUSRBRM library when the
control group processing is started. This message queue is automatically deleted
when the SNDMSG command defined in the MONSWABRM command is
processed. The SNDMSG command sends a message to QSYSOPR informing
you that the application can be used.
Instead of invoking the SNDMSG command, you can start another process such
as release a job queue, start a subsystem, or call a program. You may not want to
use the STRSBSBRM command until the last exit, because this starts all of the
subsystems that were ended by the control group. This assumes that you defined
the subsystems to end in your control group.
The preceding example allows you to release applications to the users as and
when they are available. The disadvantage here is that BRMS/400 has to perform
four separate save commands to save the four libraries.
Note
By default, the backup control group job and all of the MONSWABRM jobs are
submitted to QBATCH subsystem. You must ensure that you have enough
activity levels to perform your control group save and process all of the
MONSWABRM commands. If you prefer, you can use another subsystem by
specifying the job queue name or the job description name in the STRBKUBRM
or the MONSWABRM commands.
4.3.5.3 Example 3
In this example, the MONSWABRM command is not used at all. This is only
possible if you are at V3R6 or later or at V3R2. If all you want from the
save-while-active function is the message when the libraries reach
synchronization point, you can use SWA Message Queue as shown in Figure 49.
The OPER01 message queue is used by the system to log the following
messages:
0 of 4 libraries processed. Started LIBA at 02/03/01 10:20:06.
1 of 4 libraries processed. Started LIBA at 02/03/01 10:20:07.
BRMS/400 uses the first message queue to monitor for the synchronization. Even
if you were to specify OPER02, OPER03, and OPER04 as the message queues
for LIBB, LIBC, and LIBD, the save-while-active synchronization goes to message
queue OPER01 as previously shown.
Important
At the time this redbook was written, BRMS/400 required the message queue
to exist in QUSRBRM when processing the save.
If you are using the MONSWABRM command, you do not have to create any
message queues. If you are not using the MONSWABRM command, you must
ensure that you create a message queue in the QUSRBRM library with the
same name as that value you specified in the SWA Message Queue field.
Until the PTF is available and applied, you must create a message queue in the
QUSRBRM library to match the message queue value you used in the control
group. Use the Create Message Queue ( CRTMSGQ) command to create a
message queue such as SWAMSGQ.
4.3.5.4 Example 4
The MONSWABRM command is not used in this example. The objective here is
to use multiple message queues to monitor for save-while-active synchronization.
See Figure 50 on page 82.
In the example in Figure 50, BRMS/400 performs three save operations. The first
save operation saves LIBA and LIBB and sends the synchronization message to
OPER01 message queue. BRMS/400 processes LIBC and sends the
synchronization message to OPER02 message queue. LIBD and LIBE libraries
are processed last and a single synchronization message is sent to the OPER03
message queue. In all, BRMS/400 performs three separate save operations for
this control group.
You see that in the preceding example, we did not use an *EXIT or a *LOAD
operation to separate the saves in the control group. BRMS/400 automatically
issues another save operation when it detects a change in the way you want to
perform your save-while-active operation. In this example, it detected a change in
the Save-while-active field.
4.3.5.5 Example 5
In the example shown in Figure 51, we use special values, such as *ALLPROD or
*ALLTEST, in the MONSWABRM command with the save-while-active function.
10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *ALLPROD *DFTACT *NO *SYNCLIB PRODMSGQ
40 *EXIT *DFTACT
50 *ALLTEST *DFTACT *NO *SYNCLIB TESTMSGQ
The exits have the following settings for the MONSWABRM command:
20 - MONSWABRM LIB(PRODMSGQ)
CMD(SNDMSG MSG('All production libraries are synchronized.')
TOUSR(*SYSOPR))
40 - MONSWABRM LIB(TESTMSGQ)
CMD(SNDMSG MSG('All test libraries are been synchronized.')
TOUSR(*SYSOPR))
When the *ALLPROD set of libraries reaches a synchronization point, the system
sends the message to PRODMSGQ. PRODMSGQ is monitored by the
MONSWABRM command. As soon as it receives the message from the system, it
processes the command specified in the CMD value. The control group goes on
to process the *ALLTEST libraries and performs similar tasks as for *ALLPROD
processing.
This is normal. BRMS/400 saves library QUSRBRM at the end of the save
operation, so there are no libraries that require to be saved after the
QUSRBRM library.
The advantage of using this approach, where the SWA Message Queue value
matches with the LIB value on the MONSWABRM command, is that you do not
have to remember the name of the first library that appears in your list. You also
do not need to know how BRMS/400 builds the list of libraries for save
processing. This list may not always appear in alphabetical sequence when
BRMS/400 is performing an incremental save.
For example, you have libraries APROD, BPROD, and CPROD as your
production libraries. You know that BRMS/400 always uses the first library in
sequence to check for save-while-active messages. Your MONSWABRM
command contains APROD for the LIB value, and the control group defaults to
*LIB for SWA Message Queue. You already performed a full save on Sunday.
Between the full save and the next incremental save, you created a new library
called AAPROD and have not updated the exit for the MONSWABRM command.
When you process the control group on Monday for incremental saves,
BRMS/400 looks at the last save date and time for all of the libraries and builds a
list of libraries for the save operation. This list has AAPROD ahead of APROD
library. Thus, your MONSWABRM command does not receive any
save-while-active messages to libraries reaching synchronization. Therefore, we
recommend that you specify a name of a message queue in the SWA Message
Queue field and use the same name for the LIB value in the MONSWABRM
command. This always ensures that you get synchronization messages,
regardless of how BRMS/400 builds a list of libraries for save processing.
Use . . . . . . . . . : *BKU
List name . . . . . . : SAVESPLF
Text . . . . . . . . . Output Queue to be Saved by BRMS
Figure 52. Including and excluding spooled file entries in backup list
Within a single spooled file list, you can add multiple output queues that you want
to save by selecting multiple sequence numbers. When you add the output
queues, you can select the type of spooled file names, job names, or user names
that you want to save. For example, if you only want to save spooled files that
belong to USERA, you can specify the name of this user in the User field. You
can also select generic names or job names.
This example saves output queue SAVEOUTQ from library QGPL. You can leave
the OUTQ default to *ALL. In this case, BRMS/400 saves all spooled files from all
output queues from the QGPL library.
If you want to omit an output queue, you can use the *EXC value to exclude it.
Once you have set up a backup list, you can add this list to your daily, weekly, or
monthly backup control group as a backup item and a list type of *SPL. BRMS/400
automatically saves the spooled files whenever the control group is processed for
backups. Figure 53 shows a backup control group especially created to save
spooled files using the backup list that was created earlier.
Group . . . . . . . . . . : BKUSPLF
Default activity . . . . . FFFFFFF
Text . . . . . . . . . . . Control Group to Backup Spooled Files
Once you have successfully saved the spooled files, you can use the Work with
Spooled Files for BRM ( WRKSPLFBRM) command to display the status of your saves.
You see that your spooled files are organized in the date and time order in which
they were created on the system (Figure 54).
Position to date . . . .
Important
BRMS/400 does not automatically create the spooled files that you saved when
you restore your user data on your system. You have to recover your spooled
files using the WRKSPLFBRM command and perform the appropriate actions to
restore the spooled files.
From the Work with Saved Spooled Files display, select option 7 to restore the
spooled files that you want to recover. This takes you to the Select Recovery
Items display (Figure 55).
..............................................................................
: :
: Restore Command Defaults :
: :
: Type information, press Enter. :
: Device . . . . . . . . . . . . . . *MEDCLS Name, *MEDCLS :
: End of tape option . . . . . . . . *REWIND *REWIND, *LEAVE, *UNLOAD :
: Restore to output queue . . . . . . *SAVOUTQ Name, *SAVOUTQ :
: Library . . . . . . . . . . . . . ________ Name, *LIBL :
: :
: F12=Cancel :
: :
: :
:............................................................................:
By default, BRMS/400 restores your spooled data into the output queue from
which it was saved. You may override the defaults by selecting function key F9
from the Select Recovery Items display to change the recovery defaults.
During the save and restore, BRMS/400 retains the spooled file attributes, file
name, user name, user data field, and, in most cases, the job name. OS/400
assigns new job numbers, a system date, and a time of the restore operation. The
original date and time cannot be restored. Once you restore the output queue,
you can use the WRKOUTQ command with OPTION(*PRINT) to spool the contents of
the output queue. You can use this report to compare with the original report that
you produced after saving the output queue.
BRMBKU Backup
System: SYSTEM05
Select one of the following:
1. Backup planning
2. Perform backup
3. Display backup activity
4. Start console monitor
If you are on the system console, you can start the console mode with option 4
from the BRMBKU menu. Once you start the console monitor, the console waits
for a BRMS/400 command to be processed (Figure 57).
Console Monitor
Figure 58. Submitting a system save to batch using the console monitor
If you want to interrupt the console monitor, press F9 and enter your password. If
you entered the correct password, a pop-up window is shown where you can
enter OS/400 commands (Figure 59).
..............................................................................
: Command :
: :
: ===> :
: F4=Prompt F9=Retrieve F12=Cancel :
: :
:............................................................................:
When the console monitor is interrupted, any requests submitted through the
console monitor are queued and not processed until you complete your command
and return to the console monitoring status. If you forget to return from the
command line, BRMS/400 does not process any queued backups that were
submitted.
To avoid this security exposure, you should create a new user profile (for
example, CONSOLE) that has QBRM as the current library, calls the console
monitor program (Q1ACCON) as its initial program, and uses the *SIGNOFF
menu as its initial menu (Figure 60).
Signing on at the system console with this user profile starts the console monitor.
You can use F9 to enter commands on this display only if you enter the
CONSOLE profile password. Any attempt to end the console monitor results in a
sign off.
In V3R2, if you exit the console monitor with F3 or F12, the Console Monitor Exit
display is shown to enter a password (Figure 61).
You can add a control group to the schedule by entering 6 in the Opt column for
the relevant control group 1. You may also enter 6 in the option column of the first
line of the display and the name of the control group in the 2 Control Group field.
This takes you to the OS/400 Add Job Schedule Entry display as shown in Figure
63 on page 92, where BRMS/400 automatically completes the job name and
command to run fields. You should enter scheduling details in the lower half of the
display and any additional parameters (F10=Additional parameters) not shown on
the initial display.
Only those jobs that do not generate an interactive display can be submitted to a
job scheduler. This precludes scheduling recovery with the STRRCYBRM
command, but allows you to schedule the recovery report.
Next
-----Schedule------ Recovery Submit
Opt Job Status Date Time Frequency Action Date
BRMSAVE SCD *NONE 23:30:00 *WEEKLY *SBMRLS 05/06/00
QBRMBKU SCD *ALL 22:00:00 *ONCE *NOSBM 06/06/00
The Work with BRM Job Schedule Entries display allows you to change, hold,
remove, work with, or release scheduled jobs. It is similar to the OS/400 Work
If you choose option 4 (Remove) in the Work with BRM Job Schedule Entries
display (Figure 64), a confirmation display is not shown. Your selected entries are
removed immediately.
You can also access scheduled jobs from the BRMS/400 Scheduling menu.
Option 1 on the BRMS Scheduling menu shows all BRMS/400 scheduled jobs
(including those added manually to the scheduler) as shown in Figure 64. Option
2 shows all scheduled jobs.
Job scheduler for OS/400 already works with BRMS/400, and BRMS/400 allows
you to tailor its functions so that job scheduler for OS/400 commands are
automatically invoked when certain BRMS/400 options are selected. Use option 3
(Change Job Scheduler) from the BRMS scheduling menu or the Change Job
Scheduler (CHGSCDBRM) command with a prompt. You are prompted with the
display shown in Figure 65.
In V3R2 and V3R7, the *IJS option was added for the Scheduler type parameter
on the CHGSCDBRM command. If you are using job scheduler for OS/400 and
are happy with the BRMS/400 defaults, you should choose this option. No further
options are shown.
If you are using a release other than V3R2 or V3R7, or if you are using a non-IBM
scheduler, you should use the *USRDFN value. There are three parameters where
you can define non-IBM scheduler CL commands to be executed. For each
parameter, you can also specify whether you want to be prompted for the
command at execution time.
Not all variables apply in each case. If the variable name is not relevant, an
asterisk (*) is placed in the variable (Figure 66).
Before you can use &APPL, which contains “BRMS”, you need to set up the
application in job scheduler for OS/400. You do this by selecting option 4 (Job
Controls) from the main job scheduler for OS/400 menu and option 6 (Work with
Applications).
Figure 67 and Figure 68 show the prompts for creating the application BRMS. You
are asked for contact names and other information, but you can create these by
drilling down (the same as with BRMS/400).
Application .. . . . . . . . . . . BRMS
Application contact one . . . . . .
Application contact two . . . . . .
Application contact three . . ........................................
Application contact four . . : Select Application Contact :
Application contact five . . : :
Text . . . .. . . . . . . . : Type options, press Enter. :
: 1=Select :
: Opt Application contact :
: 1 Derek McBryde :
: Sejal Dave :
: Genyphyr Novak :
: Debbie Saugen :
: :
: Bottom :
: F9=Work with application contacts :
: F12=Cancel :
: :
F3=Exit F4=Prompt F12=Ca :......................................:
On Saturday, the month-end job overruns and does not complete before
midnight. The backup job, therefore, does not run until after midnight, which is on
Sunday in our scenario.
To add to this, when the scheduler submits the control group to run again at 23:00
on Sunday evening, another full backup of the FILELIB* libraries is taken. If these
saves are to save files, you can experience space problems. If you are saving to
tape, you can run out of tapes.
Each AS/400 system that is a member of a network group receives updates to the
media inventory, regardless of which network member makes the change.
Therefore, if you have a network of four AS/400 systems (SYSTEM01,
SYSTEM02, SYSTEM03, and SYSTEM04), and you add a media volume (A001)
on SYSTEM01, the information about this new volume is propagated on all other
systems. Information shared between systems in the shared media inventory
environment includes:
• Media inventory
• Media class
• Media policy
• Container inventory
• Container class
• Move policy
• Network group
• Storage location
• Duplication cross reference
Before you set up your network, it is extremely important that you have installed
on your system the PTF related to the enhancements made to the Copy Media
Information using BRM (CPYMEDIBRM) command. The CPYMEDIBRM
command copies media inventory information to a work file or copies the contents
of the work file to the media inventory. The actual usage of this command in a
BRMS/400 network group is discussed later in this chapter. Based on the version
and release you are using, you should have the following PTF installed for your
version and release:
• V3R1 - SF34449
• V3R2 - SF34452
• V3R6 - SF34453
• V3R7 - SF34454
With the PTF applied, the CPYMEDIBRM command saves the following
information:
• Containers, container classes, move policies, move policy rules, and locations
are now included in the *TOFILE function.
• If they do not already exist, containers, container classes, move policies,
move policy rules, and locations are added to the *FROMFILE functions. This
Note
Media and history records that are added have the system name changed to
the new system name with the *FROMFILE function.
The *TOFILE function copies the media and history records owned by the
current system.
You should also ensure that you have the latest BRMS/400 PTFs applied on your
system.
Note: The subsystem descriptions, job descriptions, and the job queue that
BRMS/400 uses are stored in the QBRM library.
updates
Creates a
QA1AMM file QJ1ACM journal
new record
Q1ACNETl
Q1A1ARMT file
QBRMSYNC job Q1A1ARMT file contents:
in Q1ABRMNET sbs contents: SYSTEM01
Reads then SYSTEM02 A001 SYSTEM02
deletes if SYSTEM03 A001 SYSTEM03
successful
BRMS/400 uses the following process to update data across the network.
BRMS/400 journals the files containing the shared resources. These files are
QA1AMM for the media and QA1A1RMT for the systems in the network group.
When SYSTEM01 updates media, a policy, or any shared resources, an entry is
logged in a BRMS/400 journal QJ1ACM in the QUSRBRM library. BRMS/400
captures both before images and after images in the journal receiver for any
changes that are made related to media inventory on the systems in the network.
However, only the after images are used to update the shared media inventory.
Hint
The interval (or delay) value used to synchronize media information within a
BRMS/400 netowk can be set between 30 and 9999 seconds using the
Shared Inventory Delay parameter in the System Policy for V3R2, V3R6, or
V3R7 systems. For V3R1 systems, this delay is fixed at 60 seconds and
cannot be changed.
When there is data in the QA1ANET file, it submits the QBRMSYNC job
through the Q1ABRMNET job queue. The QBRMSYNC job uses a job
description of QBRMSYNC and calls the Q1ACSYN program.
Using QA1A2NET as a key, records are read from the QA1ANET file. A
Distributed Data Management (DDM) link is established with the remote
system to update the corresponding file on the remote system. The DDM files
can be recognized in the QTEMP library because they have the name QA1A--D,
where “ --” refers to the file name such as QA1AMMD for media inventory. The
suffix of “D” indicates that it is a DDM file.
– Before performing the update, it first checks the date and time stamp of the
record to be updated with the date and time stamp of the update itself.
– If the update has an older time stamp, the update request is rejected.
Once this update is done, Q1ACSYN deletes the record from the QA1ANET
file and reads the next record until all of the records have been processed.
The QBRMSYNC job ends when the QA1ANET file is empty.
If you have any doubt that this process is not working satisfactorily, you can
display the QA1ANET file to see if it contains any records. If the number of
records is not zero, or is not decreasing, you may have a problem with the
network.
Check that there are no messages on the QSYSOPR message queue on all of
the networked systems. You also need to check that:
• Subsystem Q1ABRMNET is started.
• Job queue Q1ABRMNET is released.
• APPC controllers are varied on.
• QBRMS user profile is not in the *DISABLED state.
If you are using APPN with auto configuration, communications between AS/400
systems should be relatively simple. If display station pass through works fine
and you can use SNA distribution services (SNADS) successfully, there is every
chance that BRMS/400 networking will also work.
Also with APPN, and auto configuration enabled, you do not have to manually
re-create the APPC controller and APPC device descriptions if you decide to
change your system name or your network identifier. You can simply vary off and
delete the old controller and device descriptions and allow APPN to automatically
re-create the definitions for you.
If you use APPC communications, you have to create your own APPC controllers
and devices. You must ensure that you specify correct information regarding the
remote system when creating the controller description. For example, the Remote
network identifier, Remote Control point, and Remote System Name values relate
to the remote system. You also need to ensure that you are using the QBRM
mode for the Mode parameter on the APPC device description. The default for
this value is *NETATR, which uses the BLANK mode description, and your
BRMS/400 network will not work.
With APPC, you also need to ensure that you change your APPC controller
device descriptions if you decide to change the name of your network or the local
location name at a future date. The reason you have to do this is because you
cannot delete and allow the system to automatically re-create your definitions as
in APPN.
You need to understand the following information when you have a mixture of
V3R1, V3R6, V3R2, and V3R7 in a BRMS/400 network:
• For APPN networks, check to see whether you are using secured locations or
non-secured locations for your network. You can do this by using the Work
with Configuration List (WRKCFGL *APPNRMT) command.
Check the Secure Loc value. Figure 71 on page 102 shows an example. If the
secure location is set to *NO, you are using a non-secured network. If the
secured location is set to *YES, you are using secured location network. For
On the target system (SYSTEM02), which is at V3R2, you can use the Work with
Configuration Status ( WRKCFGSTS) command to observe the status of your APPC
device and controller. You notice that a mode is attached under the device. The
mode that BRMS/400 uses is QBRM. You also notice that the mode uses the
QPGMR user profile rather than QBRMS. From the Work with Configuration
Status display, type option 5 next to the QBRM mode to work with the job,
followed by option 10 to see the job log. You can see the error condition in Figure
74.
As the message suggests, you must have the appropriate authority to access
files in the QUSRBRM library on the target system.
Although the steps are fairly easy, you should take every precaution to ensure
that proper planning has taken place and that you fully understand the
implications of adding and removing systems from the BRMS/400 network. Some
of the planning considerations that you should be aware of are:
• Ensure that you have a full backup of the QUSRBRM library on all of your
AS/400 systems that you plan to place in the network group. The BRMS/400
network setup modifies some critical files in the QUSRBRM library. You may
have to restore the QUSRBRM libraries to their original state if things do not
work out.
• Check with your Support Center to ensure that you are up-to-date with your
PTFs for BRMS/400 and dependant PTFs for OS/400 and Licensed Internal
Code.
• Ensure that there is no BRMS/400 activity on the systems that you are
planning to network within the network group. All BRMS activity must be
stopped prior to starting the network connection.
• If you already have BRMS/400 operational on individual systems, ensure that
the operation is error free and that there are no outstanding issues with the
normal operations. It is also important to sit down and think about volume
names, media policies, containers, and classes. Duplicate volume names are
not allowed within a shared media inventory. See 2.1.3, “Media naming
convention” on page 8, for suggestions on how you should define a naming
convention for your BRMS/400 volumes.
• If you are adding a new system to a network group, make sure your media
license covers the additional media. See 2.2.1, “Updating BRMS/400 license
information” on page 13, for additional information.
Figure 75 provides a high-level overview of the steps that you need to follow
when setting up a BRMS/400 network. The example assumes that one system
is at V3R6 (SYSTEM05), and the other system is at V3R2 (SYSTEM09). We
want to add SYSTEM05 to the network using SYSTEM09 as the master
system. Both systems currently have BRMS/400 fully operational and have
their own media inventory. They both also have unique volume names. We
also verified that the LCLLOCNAME is the same as the system name and that
the LCLNETID on both systems is set to ITSCNET.
Notes:
= Execute the step on SYSTEM05.
• For systems that are completely new, the process to add them into the existing
BRMS/400 network group is extremely simple. This is because the new
system does not yet have its own media inventory. This removes the
requirement to run the CPYMEDIBRM command to save and later reload the
media information.
You can change the Receive media information field at any time, and depending
on the number of media information records you have, the synchronization
process may take a long time.
Note: We, therefore, recommend that you do not change the Receive media
information field frequently.
If you have a 3494 media library device attached to multiple AS/400 systems in a
BRMS network, we recommend that you have the library names the same across
all of the AS/400 systems.
Once you set up a BRMS/400 network, it is important that you verify on a regular
basis that the network is working for you. See 5.9, “Verifying the BRMS/400
network” on page 120, for additional information.
c. Press Enter. BRMS/400 searches the network for the system name that
you specified. Depending on your network configuration and the number of
systems you have in the network, this can take a few minutes. When the
system is found (in our example, SYSTEM05), it is added to *MEDINV (the
BRMS/400 network group name). As shown in Figure 77, the display is
refreshed with the entry for SYSTEM05 added to the network group.
SYSTEM05 is shown as an inactive member of a network group and is not
sharing media files with other active network systems in the group at
present. To change the inactive status to active, media files must be copied
to the system that is being added to the network group. The process to
copy media files and media content information occurs in step 10 on page
108.
Bottom
F3=Exit F5=Refresh F12=Cancel
System SYSTEM05 network group ITSCNET added.
9. On SYSTEM05, use the Work with Media ( WRKMEDBRM) command to see if you
have any media information. If media information is not present, go to step 10.
F3=Exit F12=Cancel
The media management files that are copied to the inactive system are:
• QA1AMM: Media inventory
• QA1AMT: Media class attributes
• QA1ACN: Container status inventory
Hint
It is important to ensure that the user profile QBRMS is not in a *DISABLED
state. Communication entries in the Q1ABRMNET subsystem use this user
profile. If it is disabled, you cannot establish a DDM connection. During our
tests, we noticed that the profile was disabled. A CPF4734 message was
logged on the system operator’s messge queue indicating that an evoke
function for the QCNDDMF file in the QSYS library device DDMDEVICE
was rejected. The SNA error code was X’080F6051, indicating that the
security code specified by the source program or the default values
supplied by the system are not correct.
Upon checking everything, we found that the QBRMS user profile was
disabled. We enabled the profile and restarted the INZBRM process. The
error was resolved.
When the system is added to the network, several things happen. First, the
media inventory files from the network are copied to SYSTEM05.
Second, as shown in Figure 79 on page 110, an entry for SYSTEM09 is
automatically created on SYSTEM05 with the status of Active. If you now
check the entry for SYSTEM05 that was created on SYSTEM09, you see that
this also has a status of Active.
QBATCH 0 2
QCMN 0 2
QCTL 0 2
QINTER 0 2 4
QSERVER 64000 2 5
QSNADS 0 2
QSPL 0 2 3
QSYSWRK 0 2
Q1ABRMNET 0 2
11.On SYSTEM05, check the system value QDATE, and make any corrections.
12.On SYSTEM09, check the system value QDATE, and make any corrections.
13.On SYSTEM09, issue the Initialize BRMS/400 (INZBRM) command as
follows:
INZBRM OPTION(*NETTIME)
The time of the system that issues the INZBRM command is used to
synchronize the rest of the systems in the network group.
Alternatively, use option 8 (Set time) from the Change Network Group display
to synchronize the times to selected systems within the network group. The
selected systems use the time of the issuing system. This option is useful if
you just want to synchronize the time of one system, rather than all of the
systems. For example, you may want to synchronize the time of a system that
was shutdown for maintenance. Usually, you need to reset the time when you
perform a manual IPL, or where you are operating in different time zones, and
Note
It is important that network times remain in sychronization and the INZBRM
command should be run periodically. Remember that a common media
inventory update depends on the fact that a precise chronological sequence
of media information is recorded across all systems in the network group.
The INZ OPTION(*NETTIME) command ensures that the times match to within
five seconds across the systems.
Use care if times are synchronized near midnight because the command
does not take date into account.
14.Go to SYSTEM05. You can now merge the media inventory data that was
saved prior to adding the system to the network under step 9. Enter the
following command on SYSTEM05:
CPYMEDIBRM OPTION(*FROMFILE)
Note: This step is only necessary on systems that previously had BRMS/400
media inventory. Make sure you change the default from *TOFILE to *FROMFILE.
Any media information that is inconsistent with the new network level media
information is ignored. All entries that are not duplicates are added to the
network media inventory. If duplicate media contains active files, you must
keep track of the information. If no active files are present, you should
re-initialize the tape with a new volume ID.
Note
When the media inventory has been copied back from the temporary file
(QA1AMED or a file name that you designate), you need to review common
classes for inconsistencies. For example, it is possible that Media Class
SAVSYS on one system uses a media density of *QIC120, while the same
media class on the other uses *FMT3490E. All media density now belongs
to the network class SAVSYS.
15.Enter the WRKMEDBRM command on SYSTEM05. You see the media inventory of
SYSTEM09 and SYSTEM05.
16.Enter the WRKMEDBRM command on SYSTEM09. You see the media inventory for
SYSTEM05 and SYSTEM09.
We strongly recommend that you check on a daily basis to see if your network is
operational and that the media information is moving across it. See 5.9, “Verifying
the BRMS/400 network” on page 120, for additional information.
Remote Receive
Opt System Network ID Media Inf Status
4 SYSTEM01 ITSCNET *NONE Active
4 SYSTEM02 ITSCNET *NONE Active
2. On any system remaining in the network group, select option 4 (Remove) for
the system name being removed from the network group on the Change
Network Group display. This removes the system name from all systems
When changing the system name using BRMS/400, you need to check two items:
• Is your system running under V3R1?
• Is your system running under V3R2, V3R6, or later?
Information on changing system names for systems that are at V2R3 or V3R0.5 is
documented in Backup Recovery and Media Services for OS/400 (part of the IBM
Online Library SK2T-2171) for V3R7. Please note that the V2R3 and V3R0.5
releases are no longer supported by IBM.
Note: You may need to perform additional steps when you change your system
name or network ID. The steps described here are required for BRMS/400 only.
1. Save library QUSRBRM on OLDSYSN.
2. If OLDSYSN is part of the BRMS/400 network, remove all the networked
systems from OLDSYSN using the following steps. Otherwise, go to step 3.
a. On OLDSYSN, enter:
GO BRMSYSPCY
b. Select option 4 (Change Network Group).
c. Enter option 4 next to all network systems from the Change Network Group
display.
d. On the Confirm Remove of Network display, select *YES to remove media
information.
If you have a system name different than your local location name (such as
SYSTEM01, LOCA), and you want to change both of these to new values (such
Important
After you change the system name and IPL the system, you must ensure that
you change the BRMS/400 network immediately. The BRMS/400 media files
still have not been updated to reflect the system name change. The BRMS/400
media volumes are still owned by the old system name. In addition, the other
systems in BRMS/400 network still try to communicate with the old system
name because they are not yet aware of the rename.
To avoid any missing information in the shared media inventory data, you must
change the BRMS/400 network immediately after the system IPL. Also, make
sure that no BRMS/400 activity occurs between the IPL and adding your
system to the BRMS/400 network.
Figure 83. Removing the old system name from the network
Remote Receive
Opt System Network ID Media Inf Status
4 OLDSYSN APPN *NONE Inactive
5.6.3.1 Example 1
You have a system that is at V3R1 or later. You are going to move to a new
system that has a new name. Let us assume that you are going from a V3R1 to a
V3R2 system. The steps outlined here relate to BRMS/400 only, and not for a
complete migration to V3R2.
1. On your V3R1 system, save the QUSRBRM library.
2. On your V3R2 system, complete these steps:
a. Delete the BRMS/400 (5763BR1) licensed program. You do not need to do
this if you are not changing an OS/400 release.
b. Restore QUSRBRM.
c. Use the RSTLICPGM command to restore the BRMS/400 licensed program if it
is not already installed. The RSTLICPGM process performs any file
conversions that may be required in the QUSRBRM library. File
conversions generally involve adding new fields to database files or adding
new files or data areas. File conversions can only happen when you are
installing a licensed program. A restore operation does not perform any file
conversions.
d. You see that the old system name is still shown on the Change Network
Group display.
e. Select option 4 to remove the old system name from the network (although
you really do not have a network).
f. On the Confirm Remove of Network Systems display, select the option to
*RENAME the media. This renames all your media information from your old
system name to the new system name.
g. Use the WRKMEDBRM command to check your media information.
add SYSTEM1
on SYSTEMA
SYSTEMA INZBRM *NETSYS
on SYSTEM1
SYSTEM1
SYSTEMB
SYSTEM2
SYSTEMC
Network 1 Network 2
SYSTEM1
SYSTEM1
Break NETWORK 2
SYSTEM2
SYSTEM2
NETWORK 2
add SYSTEM1
& SYSTEM2
on SYSTEMA
SYSTEMA SYSTEM1
INZBRM
*NETSYS
SYSTEMB
SYSTEMC SYSTEM2
INZBRM
*NETSYS
Network 1
We, therefore, recommend that you always review the control group even after
the copy. You may need to tailor the values based on the operational
requirements for that particular system.
Assuming that today's date is 06 July 2000, the WRKMEDBRM command for
each system should display the information shown in Figure 87.
If you see the information shown in Figure 88, you can conclude that SYSTEM01
did not receive the SYS04 media update.
The files can reside on the local Integrated PC Server (formerly known as the
FSIOP) or on a remote server. This ability makes the AS/400 system a powerful
part of the domain. You can use the AS/400 system to save the server data from
any server system in the domain such as LAN Server/400.
To save or restore the IFS data, you have to use the Save Object (SAV) command
and the Restore Object (RST) command on the AS/400 system. Using these
commands, you can save or restore the entire integrated file system. As such,
For additional information on how to save and restore using the SAV and RST
commands, see the Backup and Recovery - Basic, SC41-4304. For information
on IFS, see Integrated File System Introduction, SC41-5711.
A major benefit of the Integrated PC Server and LAN Server/400 is the ability to
include your LAN Server/400 backup procedure into your AS/400 backup
procedure. However, when you use the Integrated PC Server, you create
additional objects on the AS/400 system that need to be saved outside the control
of the SAV and RST command. They are:
• Configuration objects associated with the Integrated PC Server
• Licensed program product libraries
• Network server storage space associated with the network description
• Storage spaces shared by all Integrated PC Servers on the AS/400 system
When you design a solution to save IFS, especially when you have the Integrated
PC Server, you need to consider how you back up the objects in the above list.
We use the LAN Server/400 environment as an example to define the save and
restore strategy for IFS using BRMS/400. The rest of this chapter is divided into
two parts. The first part contains an overview of the different components that are
created when you use the Integrated PC Server for LAN Server/400. It discusses
the importance of ensuring that you have proper authority to save and restore
information. It also discusses the performance implications on your save and
restore operation when you use the Integrated PC Server.
The second part of this chapter addresses how you can use BRMS/400 to save
and restore various objects that are created when you have the Integrated PC
Server installed and configured on your system to be used by LAN Server/400.
Storage spaces contain your LAN data. You may decide to create two or more
storages spaces for each network server description. In this way, you can store
data, such as PC programs, that does not change often in one storage space.
And you can store user data that changes often in another storage space. Now,
Save and restore for the server storage spaces can be done using the
SAVOBJBRM command and the RSTOBJBRM command, or through the
SAVLICPGM command and the RSTLICPGM command. These storage spaces
are stored in library QUSRSYS and QXZ1.
Network server storage spaces are often simply called “storage spaces”. The
server storage spaces are often referred to as the C: drive, D: drive, and E: drive.
Throughout this chapter, the term “storage space” refers to network server
storage spaces unless indicated otherwise.
Library QXZ1
QXZ1 holds a number of objects, three of which are the base from which the
AS/400 system creates network server descriptions when the CRTNWSD
command is used. These storage spaces are:
• QFPHSYS1
• QFPHSYS2
• QFPHSYS3
Library QUSRSYS
This is where the disk images for each network server description are stored. You
find that there are two “server storage” areas for each network server description
that is created.
For the network server description “SRVLS40A” shown in our example in Figure
89 on page 126, the two server storage spaces are called SRVLS40A1.SVRSTG
(also referred to as your C: drive) and SRVLS40A3.SVRSTG (also referred to as
your E: drive). The names consist of the server name followed by a suffix of 1 or
3. SRVLS40A1 holds the files and programs to boot the Integrated PC Server.
SRVLS40A3 holds the domain control database information.
QSYS.LIB
QFPHSYS1.SVRSTG
QXZ1.LIB QFPHSYS2.SVRSTG (D drive read only)
QFPHSYS3.SVRSTG
QSYS.29nn Secondary language version
SRVLS40A
DSK
APPL
X FILE
MYFILE
L
A
SRV0S2A DSK B (Drives on
C remote server)
Please ensure that you are not affecting other operations on the system by taking
memory for the save operation. Other factors, such as the size of your files, tape
speed, disk arms, and your processor feature also influence the speed at which
the AS/400 system can save or restore your data. For more information on
managing system activities, see Work Management, SC21-8078.
If less than the recommended memory is allocated to the pool where the save is
running, the save operation may take significantly longer. Also, if there is other
work being run in the pool, you may have to increase the pool size.
Hint
We recommend that you create a group profile for your Integrated PC Server
(for example, FSIOP) and make the users part of the FSIOP group profile. This
way, only users that belong to the FSIOP group profile are registered on the
LAN server. If you want to perform backup and restore functions on individual
files, you must have administrator authority on the LAN server to ensure all
user data is saved. If the user does not have administrator authority on the
LAN server, they can only save and restore files to which they have authority.
You must remember to change the QBRMS user profile to have the correct
group profile.
Some of the most common errors that you may come across are related to
improper authorities that you may or may not have on your user profiles when
saving IFS information. A common occurrence is when you do not have *ALLOBJ
special authority to save IFS information or when you are not registered as a LAN
administrator. For example, if you belong to the *SYSOPR user class and are not
part of the Integrated PC Server group profile and you are not enrolled to the LAN
Server as an administrator, when you try to save IFS directories, you see
messages similar to those shown in Figure 91.
Notice in example 2 in Figure 91 that the backup control group within BRMS/400
starts and completes successfully. However, the IFS information has not been
saved because the user OPER1 was not authorized to the system.
Remember
When you create a user profile, it is important to understand that the LAN
server can only accept an 8-character user profile, where the AS/400 system
can accept a 10-character user profile.
We now look at the ways in which authority to IFS information can be granted so
that the save and restore functions can be completed. Our examples are based
on using IFS with LAN Server/400 with an Integrated PC Server. At the time this
redbook was written, we were unable to perform our tests using the Integration of
Novell NetWare for OS/400.
Notes
In this example, both the FSIOP group profile and the OPER1 user profile
were of the *USER user class. However, when the OPER1 profile was enrolled
in the LAN server, it contained ADMIN privileges, which are required to
perform the save and restore functions of the LAN Server/400 information.
The reason the LAN server enrolled the user with ADMIN privileges is due to
the fact that the user contained *ALLOBJ special authority.
Note
This method grants the user ADMIN privileges on the LAN server as well as
gives them authority to all objects on the AS/400 system. For that reason, it
may be undesirable from a security standpoint to use this approach.
With this approach, you do not need to grant *ALLOBJ special authority to
OPER1 user profile or enroll the user profile to the FSIOP group.
Note
This authority is overwritten if the user profile is changed on the AS/400
system. You must run the SBMNWSCMD command again each time the profile
changes when you vary on the Integrated PC Server.
*SAVSYS special authority specified on an AS/400 user profile does not have any
effect on the ability to save or restore objects using the LAN Server for OS/400
file system.
If you find QSECOFR in the list, change its profile to be a member of the group
that is downloaded to the LAN server if this user ID is to perform save or restore
operations.
Before you save or restore the local files for LAN Server/400, we recommend that
you put the AS/400 system into a restricted state. A restricted state prevents
workstations and jobs from using the system and, therefore, ensures that no
changes can be made to the QLANSrv files during the save or restore process.
You can put the AS/400 system into a restricted state by ending all of the
subsystems. You can put only the Integrated PC Server into a restricted state by
ending the monitor job.
Note
When you put the AS/400 system into a restricted state, the Integrated PC
Servers also enter a restricted state. When the Integrated PC Server is in a
restricted state, the network server running on the Integrated PC Server is
running, but it cannot be accessed by requesters. However, the network server
can be accessed by functions running on the AS/400 system. This restricted
state is equivalent to stopping the NETLOGON service on an OS/2 LAN server
to perform backup functions.
This leaves only the system console operational. If you cannot put the AS/400
system into a restricted state, you must verify that no files are open using the
You should put the AS/400 system into a restricted state only when you want to
save files that are stored on the AS/400 system itself.
To put only the Integrated PC Server into a restricted state, end the monitor job.
The monitor job runs in the QSYSWRK subsystem, and the job name
corresponds to the name of the Integrated PC Server it is running. Figure 92
shows the domain controller, DCL10NWS, as active. Server ASL10NWS is in a
pending state. In Figure 93 on page 134, you can see a monitor job for each of
these servers. To end the monitor job, type 4 in the Options column.
Domain
Opt Server Status Text
__ SYSAS400 Network server domain
__ ASL10NWS PENDING *BLANK
__ DCL10NWS ACTIVE *BLANK
__ L10SRV INACTIVE Another Network Server
__ TST10NWS INACTIVE *BLANK
__ RJFTEST INACTIVE *BLANK
Bottom
Parameters or command
===> wrkactjob
F3=Exit F4=Prompt F5=Refresh F6=Print list F9=Retrieve
F11=Display type F12=Cancel F17=Position to
6.2.6.1 Varied ON
The Integrated PC Servers should be varied on when you want to access the data
through the QLANSrv to save individual files or directories.
You should wait to see the all of the following messages before you start your
save operation:
CPC2665 - Vary off complete for network server SRVLS40A
CPC2608 - Vary off complete for line ITSCTRN
CPIA407 - Monitor job for network server SRVLS40A ended
In this section, we show you how to back up the LAN server files. You need to
incorporate these procedures into your normal AS/400 backup procedures so that
they become routine.
The most important single point about backing up your LAN server files is to be
clear why you are saving objects and under which circumstances you plan to
restore them. The ways in which you plan to restore objects determines how you
should save them.
You can also save your LAN Server/400 data by saving the entire storage space
or you can save a portion of the storage space such as a directory or a file.
However, if you must later restore the data, you must restore the entire storage
space. If you save only a portion of the storage space, you can restore only the
files you need. Also, you do not have to vary off the Integrated PC Server to
perform this type of save operation.
Finally, note that if you save or restore a directory from a storage space,
performance is 2.5 to 3 times slower than saving a folder and its documents
using the SAVDLO command and the RSTDLO command.
* Note: The actual data rate achieved depends on a number of factors. Things
that affect results are the CPU model, the tape drive you are using, the pool
size, and the size of the files you are saving.
It is important that you plan the frequency of your saves to ensure that you
always have a usable backup available in the event of a system failure or
disaster. For example, you may decide on the following strategy to ensure that
your user data is thoroughly backed up.
BRMS/400 limitations
BRMS/400 currently does not have the ability to perform incremental saves or
to save changes since the last time you performed a full save using the backup
list items. In addition, BRMS/400 does not allow you to perform saves for IFS
information on remote systems. Both of these functions are available through
the standard AS/400 interface using the SAV command. When designing your
backup and recovery strategies using BRMS/400, you must consider these
important limitations.
Save recommendations
Save the network server storage spaces as a complete entity. This allows you to
restore the majority of your data with one command. See LAN Server/400
If your environment involves a significant amount of daily change, you may find it
better to save the entire storage space daily.
Consider saving the domain control database (DCDB) or the E: drive either
weekly or whenever you have made significant administration changes that
include alias creations. See LAN Server/400 Administration (part of the IBM
Online Library SK2T-2171) for detailed information.
Consider saving your E: drive daily to a save file while the Integrated PC Server is
varied off. This allows you to save any data that was in cache. If you do not make
many changes to user profiles or aliases, keep fairly current copies of the E: drive
on hand.
If your data changes frequently, and you must keep the Integrated PC Server
running, you must save at the directory level. If the AS/400 system takes too long
to save at the directory level, consider saving the entire storage space (for which
you must vary off the Integrated PC Server). Restoring individual directories with
this technique is not easy. One way to restore directories (if you do not need the
entire storage space) is to first create a temporary storage space in the QLANSrv
directory. You can restore into the temporary storage space and selectively
restore required files from the temporary storage space. After the restore is
completed, you must delete the temporary storage space.
Hint
To avoid wide variances in save time for QLANSvr, vary the Integrated PC
Server off and back on. This cleans up OS/2 cache data, for example, which
can cause the save times to increase.
Besides using the default BRMS control groups, you can create your own control
groups and backup list items to meet your save and restore requirements.
You can create your own backup list to customize how you want to save the IFS
directories. Once you have created your own backup list name and have added
the entry of what you want to save in the list that you have created, you can use
the list in a backup control group to save the IFS directories.
A good example here is that you may want to create two backup lists: one that
indicates a save when the Integrated PC Server is varied on and another list that
indicates when the Integrated PC Server is varied off. We briefly address these
considerations in 6.2.6, “Integrated PC Server on or off?” on page 134.
In the example that follows, a backup list called FSOFF (backup list to save the
/QFPNWSSTG storage space for LAN Server/400 when the Integrated PC Server
is varied off) is added using option 1 (Add) from the list management function
using the WRKLBRM command. This backup list shown in Figure 94 that we are
creating is exactly the same as LINKLIST that BRMS gives you.
List entries are added to the list using option 2 (Change) from the Work with Lists
display to include the contents of the IFS directories that need to be saved or
omitted. This list entry maps to the SAV command when the backup control group
is run. Figure 95 shows the settings that we use for the FSOFF link list. Notice
that in addition to the QSYS.LIB and the QDLS file systems, we also omit the
/QLANSrv file system from the save since we are only interested in saving the
entire server storage space in /QFPNWSSTG.
You can now add the backup list entries as a backup item in a backup control
group. The BRMS/400 default backup group *BKUGRP contains the default list
item LINKLIST. In our example, we add the FSOFF list item to the ITSOBKUP
backup control group (Figure 96).
Group . . . . . . . . . . : ITSOBKUP
Default activity . . . . . *BKUPCY
Text . . . . . . . . . . . ITSO Backup Control Group
You can create similar backup link lists to save the file and directory information
in /QLANSrv in the same manner that we created a separate backup link list to
save the storage spaces only when the Integrated PC Server is varied off. In this
case, you can omit the /QFPNWSSTG directory from your save since you cannot
save this when the Integrated PC Server is varied on.
Group . . . . . . . . . . : *BKUGRP
Default activity . . . . . *BKUPCY
Text . . . . . . . . . . . Entry created by BRM configuration
........................................................
Backup : Backup Items - Help :
Seq Items : :
: o *ASPnn - save an ASP :
10 *SAVSECDTA : o *IBM - save all IBM libraries :
20 *SAVCFG : o *LINK - save all integrated file system :
30 *ALLUSR : libraries :
40 *ALLDLO : o *QHST - save history information :
50 *LINK : o *SAVCAL - save calendar information :
60 *EXIT : o *SAVCFG - saves configurations :
: o *SAVSECDTA - save security data :
: More... :
: F2=Extended help F11=Search Index F12=Cancel :
F3=Exit : F20=Enlarge F24=More keys :
F11=Display exits : :
:........................................................:
Figure 97. Example of the *LINK list in the V3R7 control group
Once your save has completed, we strongly recommend that you check your job
log and use the DSPLOGBRM command to ensure that the save has completed
normally, and most importantly, that you do not have any authority problems. You
should use the DSPLOGBRM command, the WRKMEDIBRM command, the WRKMEDBRM
command, and the WRKLNKBRM command to verify your save. You can find some
information in the QSYSOPR message queue or in the job log.
Position to Date . . . . .
You can see the saved information using the WRKLNKBRM command (Figure
100).
Opt Directory
9 /QFPNWSSTG
/QFPNWSSTG/DRIVEK
/QFPNWSSTG/DRIVEL
/QLANSrv
/QLANSrv/NWS
/QLANSrv/NWS/RCHPID
For additional information on security considerations for IFS, see LAN Server/400
Administration (part of the IBM Online Library SK2T-2171).
In the example shown in Figure 102, we want to restore (from the BRMS/400 link
list) using the command:
/QLANSrv/NWS/RCHPID/DSK/K/edel_k/BRMS
Opt Directory
/QLANSrv/NWS/RCHPID/DSK/K/edel_k
/QLANSrv/NWS/RCHPID/DSK/K/edel_k/ADSMSERV
/QLANSrv/NWS/RCHPID/DSK/K/edel_k/ADSMSERV/DLL
/QLANSrv/NWS/RCHPID/DSK/K/edel_k/ADSMSERV/DOC
9 /QLANSrv/NWS/RCHPID/DSK/K/edel_k/BRMS
/QLANSrv/NWS/RCHPID/DSK/K/edel_k/PMSX
Note
The WRKLNKBRM command provides the ability to restore a single directory
or multiple directories within the path. All of the directories are displayed in a
hierarchy, and each of these directory paths can be restored individually. This
is a different view to what you get using the native Work with Links (WRKLNK)
command, where you have to select options to go to the next level in the
hierarchy.
Figure 103 identifies the versions of the saves that BRMS/400 is aware of for the
directory that we are planning to restore. If you are not planning to restore the
entire directory, you can continue to “drill down” to the next level of information.
You can now work with the objects that were saved and decide on which ones
you want to restore from the list as shown in Figure 104 on page 144.
Volume
Opt Object Serial Size
ARC.SH ABC130 263213
BACKUP.SH ABC130 220739
BRM.EXE ABC130 459040
BRM.SH ABC130 688769
COST.SH ABC130 53792
Our example shows the display in Figure 104 for information only. We restore the
entire directory from the Work with Directory Information display using the latest
version (volume ABC130). See Figure 105 and Figure 106.
As you can see, restoring the IFS information through BRMS/400 is relatively
easier than restoring the same information using the AS/400 system RST
command interface. With the RST command, you are required to type various
command parameters correctly, along with the directory syntax, which often leads
to several attempts before the restore function will work for you. For additional
information on the SAV command and the RST command, see Backup and
Recovery - Basic, SC41-4304.
Volume
Opt Object Serial Size
7 DRIVEK ABC592 34816
7 DRIVEL ABC592 29184
Select option 7 on the Work with Objects display to restore the drives and the
storage spaces in those drives. You can verify if the storage spaces have
restored successfully by using the Work with Network Server Storage Spaces
( WRKNWSSTG) command (Figure 109 on page 146).
Percent Drive
Opt Name Used Size Server Letter Text
You now need to link the storage names with appropriate drive letters using the
Add Server Storage Link ( ADDNWSSTGL) command or by selecting option 10 on the
WRKNWSSTG display.
You can now vary on the Integrated PC Server. This can take several minutes.
Once the Integrated PC Server is active, you should check your LAN Server/400
environment with the WRKLNK command and by trying a few options from the
NWSADM menu to ensure that everything is working correctly.
To recover the IFS data, add a step where you restore the data from the save files
into library IFSSAV after the BRMS/400 recovery is complete. Use the Restore
Objects in directories (RST) command as shown in the following example. Before
you perform the RST command, ensure that you have varied off the Integrated
PC server:
RST DEV('/QSYS.LIB/IFSSAV.LIB/IFS.FILE')
OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT))
6.6.1.1 Recommendations
Use the following process to restore your LAN Server/400 environment with
BRMS/400:
1. The configuration objects, licensed programs, and objects in QUSRSYS
restore in the normal way through the BRMS recovery commands.
Hint
With V3R1, restoring a configuration object for a network server description
fails since the CRTNWSD command creates the device configuration and
tries to copy QXZ1/QFPHSYS1 and QXZ1/QFPHSYS3 from QXZ1 to
QUSRSYS as C: drive and E: drive. Since QXZ1 is not there during the
restore operation, the RSTCFG command fails. This is because the
SAVCFG command does not save the contents of C: drive, D: drive, and E:
drive. All it does is save the description of the Integrated PC Server
(network server description). Informational APAR II088a56 documents this
restriction.
With V3R6, V3R2, and V3R7, this problem has been circumvented. The
RSTCFG command does not fail even when library QXZ1 does not exist.
Once the user objects and IBM licensed programs are restored, you can
re-run the RSTCFG command to restore the network server description
configuration.
2. During the recovery, let the Integrated PC Server remain in a varied off state.
3. Restore IFS information with default LINKLIST item in backup control group
*BKUGRP.
4. After ending all of the restore steps in conjunction with the BRMS/400
Recovery Report, vary on the Integrated PC Server with your first IPL after the
recovery.
5. Check the LAN Server/400 environment and try some options using the GO
NWSADM menu.
6. Use the ADDNWSSTGL command to link your storage spaces to drive letters.
7. Vary on the Integrated PC Server again.
8. Use the WRKLNK command to check the status of your data in the /QLANSrv
directory.
9. Use the WRKLNKBRM command to restore the latest save of your individual data
in /QLANSrv (for example, your daily saves).
Originally, the only media library available was the 3494 Automated Tape Library
Data Server. However, beginning with V3R1, other library devices, such as the
9427 tape library, 3590 tape library, and most recently, the 3570 Magstar MP tape
subsystem, can be attached.
Although the libraries attach to both CISC and RISC systems, only RISC systems
fully implement the media library. Functional differences may, therefore, exist on
the same library that is being shared by both CISC and RISC systems. We
attempt to outline these differences in this chapter and subsequent chapters.
Not all automated tape libraries can be attached to all models of the AS/400
system or used as alternate IPL devices. The announcement letters or your IBM
Marketing Representative can provide you the required information.
We recommend that you always refer to Automated Tape Library Planning and
Management, SC41-5309, to obtain latest hardware and software configuration
information relevant to the OS/400 release on which you are operating. This book
contains updates to the library management functions by their releases and
outlines the functional differences between the CISC and RISC OS/400 releases.
For additional information on the control unit models and storage unit models,
refer to the IBM announcement letters or the iSeries Handbook, GA19-5486.
The 3494 may be shared between eight AS/400 systems attached through the
Library Manager using RS232. An expansion attachment card (Feature #5229) is
required to support the fifth through eighth RS232 connections and the fifth
through eighth tape control units.
7.1.2.2 LAN
The 3494 can be attached to the AS/400 systems through the Library Manager
using either a token-ring LAN (uses Feature #5219) or an Ethernet LAN (uses
Feature #5220). Both TCP/IP and APPC connections are supported by the 3494,
but only APPC is supported by the AS/400 system. The 3494 LAN
communications cable limit is determined by the type of LAN implemented.
Typical LAN technology supports connections at a distance of up to 1000 meters.
If attaching through LAN, the 3494 can be shared between 16 AS/400 systems.
Appendix C, “Example LAN configuration for 3494” on page 303, provides an
example line, controller, and device configuration for attaching the 3494 to the
AS/400 through a token-ring.
The Tape Control Unit Expansion (feature #5228) expands the number of tape
control units that can be attached to the Library Manager. One feature converts
four RS232 host processor connections into four tape control unit connections on
either the base Library Manager or the expansion attachment card (feature
#5229). The following combination is possible:
Available Available
Number RS-232 ports Tape
of #5228 (for direct Control Unit
Features host attach) Connections Additional Features Required
-------- ------------ ------------ -------------------------------
0 4 4 None
0 8 8 #5229 Expansion Card
1 0 8 #5219 (#5220) LAN adaptor
1 4 12 #5229 Expansion Card
2 0 16 #5229 AND #5219 (#5220)
Note
*NOSHARE cartridges may only be changed by the owning system and can
only be seen with the WRKMLMBRM command by the owning system.
Note
With CISC AS/400 systems, you cannot use the 3590 tape as your preferred
IBM distribution medium for obtaining PTFs, licensed programs, or an OS/400
release. However, you are allowed to use the 3590 device as your Alt IPL
device through ordering a Request for Price Quotation (RPQ). See 7.3.1,
“Alternate IPL for the 3590” on page 154, for more information on the RPQ.
For RISC AS/400 systems, the 3590 is fully supported as your preferred
distribution medium and as an Alt IPL device.
The 9427 tape library supports up to two 7 GB, 8mm drives. It includes a barcode
reader that reads the labels on the cartridges to determine the cartridge identifier
without the need to load the cartridges in the tape drives. Unlike the 3494, the
9427 tape library does not have an input/output slot.
The 7 GB tape drive is based on the 7208 half-high product. Hardware changes
were made to support the 160 meter tape media. The 160 meter tape media is
required for 7 GB (uncompressed) data storage. The Initialize Tape (INZTAP)
command supports the new density type of *FMT7GB for the 160 meter tape. The
160 meter tape media cannot be written to or read by the 7208 models 002, 012,
and 232. The 7 GB drive also supports 112 meter tapes with formats *FMT2GB
and *FMT5GB.
Tape library commands and support are provided by OS/400 from V3R1.
BRMS/400 is the preferred application program that assists with tape library
manager and unattended operations.
The 9427 tape library must be put in the sequential mode where it acts as an
automated cartridge loader, when using it as an alternate IPL device. See IBM
9427 210 and 211 Operator’s Guide, SA26-7108, for information on how to set
the 9427 tape library in sequential mode.
Note
The cartridges are loaded from the bottom up. Tape cartridges must be
mounted in the 9427 tape library magazine in the correct order. The first data
cartridge of the installation must be placed in the first slot for the 9427 tape
library drive.
The 3590 model B1A device is used to attach the drive in a 3494.
The 3570 Magstar MP tape library models use a cassette loading and transport
mechanism (priority slot) to automatically transport the tape cassettes to and
from the cassette magazines and the tape drive.
In both the preceding cases, the 3570 was set up in random mode. If you use the
automatic cartridge loader (ACL) mode, the cassettes inserted using the priority
slot or the import/export slot are inserted in one of the empty slots in the
magazine. You should be in the ACL mode when you want to recover from your
SAVSYS tapes.
Note
Alternate IPL support for the 3590 is available on all RISC AS/400 systems and
the Advanced Series CISC AS/400 systems (Models 2xx through 3xx). The
support on CISC AS/400 systems is only available through RPQ 843910. This
RPQ ships IBM service instructions for attaching the 3570 as an alternate IPL
device and FULIC tape. You cannot obtain any IBM software distribution on the
3570 cassette, such as PTFs, OS/400 releases, and licensed programs.
The original media library was the 3494. However, beginning with V3R1, support
was added to OS/400 for library devices such as the 9427 tape library, the 3590
tape device, and most recently the 3570 Magstar MP tape subsystem.
AS/400 with 64-bit PowerPC technology (RISC) fully implements the media
library that gives greater flexibility to OS/400 to manage resources. However, it
introduces some considerations for BRMS/400, especially managing location,
media policies, and defining backup devices. As always, using the *MEDCLS
parameter in BRMS/400 for a backup device is the most flexible.
Another significant change in RISC is that the Media Library Device Driver
(MLDD) code is no longer required for the 3494.
The following chapters describe the functional areas of media library support. You
should refer to Backup Recovery and Media Services for OS/400 (part of the IBM
Online Library SK2T-2171), for each release, and to the most current edition of
Automated Tape Library Planning and Management, SC41-5309, for detailed
information.
There are also BRMS/400 workshops and support from IBM Availability Services
personnel. Check with your marketing representative for further information.
BRMS/400
BRMS/400 manages the media. It submits tape operations to the appropriate
interface as a result of a BRMS/400 command or as part of the BRMS/400 control
group process.
The MLDD software is shipped with the 3494 and is installed using the Restore
Licensed Program (RSTLICPGM) command. As a result, two libraries are
created: QMLD and QUSRMLD. The QMLD library contains commands and
programs. The commands are loaded into QSYS at installation time. The
QUSRMLD library contains user system configuration information. In addition to
the two libraries, a subsystem, QMLDSBS, is created.
Since the newest modification level of the MLDD and LM software contains all of
the known fixes from the previous levels, we highly recommend that you upgrade
these products when you upgrade OS/400.
To check what fix level you installed for the LM code, go to the Library Manager
PC in the 3494 and on the display, select Help. Then select the About option.
This displays your current level of LM software.
For information on new releases of the microcode (MLDD and LM), consult with
your country hardware second-level support. They can pass the request to the
3494 trained hardware engineers.
Library Manager
The Library Manager (which is effectively a PC) is located inside the 3494. It
manages the 3494 inventory and provides the interface to the accessor, or robot,
to make it functional. The software code is installed and maintained by IBM
Customer Engineers. See 8.4, “Library Manager for the 3494” on page 160, for
additional information.
Cartridge Store
Library Enter ATL
Manager Control commands
Vision Accessor Panel (full ATL
Media
Arm control)
Inventory
ATL:
Drive Drive Drive
Comms
or
IOPs LAN
AS/400:
Licensed Internal Code
Specific
MSE BRMS/400 MLDD driver programs
(separate libraries
(CISC) and subsystems
CL commands
Backup, Recovery, Archive,
Retrieve and media management
commands
Example command:
MLDD BRMS SAVLIBBRM for LIB(LIB1)
using VOL(VOL01)
OS/400
Figure 111. V3R1 or V3R2: OS/400 splits the command into MOUNT and SAVLIB
V3R2 works in the same way as V3R1 in that tape commands are issued to the
tape device and OS/400 uses MLDD for the 3494.
Another difference with CISC AS/400 systems is that you have to use the Display
Tape Status (DSPTAPSTS) command or the Work with Library Media using BRM
(WRKMLMBRM) command to manage your tape libraries. You do not have a
single command interface, such as the Work with Media Library Status
(WRKMLBSTS) command, available with RISC AS/400 systems.
OS/400
Licensed
Internal
Code
Device
LM
Figure 112. V3R6 LIC processes the MOUNT command instead of MLDD
V3R7 provides the same functions as V3R6. There are some ease-of-use
enhancements to the WRKMLBSTS command.
Note
When you use the stand-alone mode of operation with the AS/400 RISC
systems, you have to use the tape device description (TAPxx) and not the tape
library device description (TAPLIBxx or TAPMLBxx) to address the drive.
Within BRMS/400, you can use the WRKMLBBRM command to put the device
on hold if you want to use the library in a stand-alone mode.
Once the mount operation is requested, the Stand-alone Device Status window is
shown. This window displays the library manager activity, as shown in the
example in Figure 115 on page 162.
After the demount completes, you can select the mount of another cartridge using
the stand-alone mode shown in Figure 114 on page 161.
2. From this window (Figure 117), perform either of the following options:
• Enter the 3-digit device name as known by the library manager.
• Click the arrow to the right of the box, and select the 3-digit device name by
clicking it.
3. Select the Mount from Input Station operation.
4. Click the OK button.
The Mount from Input Station window in Figure 118 shows where you find the
instructions on how to continue the transient mode.
Once the mount operation is requested, the Stand-alone Device Status window is
shown. This window displays the library manager activity as shown in Figure 119.
The Reset stand-alone device operation unloads the mounted cartridge from the
selected device and makes the device ready for tape automation.
9.1 Configuring the 3494 Automated Tape Library Data Server for CISC
The 3494 differs from other libraries because it also requires separate
communications. To configure communications, use the Add Media Library
Device ( ADDMLD) command.
Figure 121 shows the Work with Active Jobs display with the 3494 Automated
Tape Library Data Server communications jobs running in the QMLDSBS
subsystem.
The communications line is varied on, and these jobs are started by issuing the
INZMLD command.
You can use the End Media Library Device (ENDMLD) command to end the jobs
if you need to perform a problem analysis or error recovery. You should use the
INZMLD command again to restart them.
After an IPL, or when the system is returned from a restricted state by using the
STRSBS QCTL command, this command is automatically re-issued in an
autostart job entry that runs when the QMLDSBS subsystem is started.
The MLDD commands operate differently than most other AS/400 commands.
They are asynchronous in nature in that you enter the command, and a
completion message is sent to a message queue after the requested process has
When using BRMS/400 with the 3494, BRMS/400 calls OS/400 commands (that
drive all ATLs). Where appropriate, some of these MLDD commands are called by
OS/400. Typically, operators and users never have to use the MLDD commands
explicitly.
For more information on the MLDD commands, see Automated Tape Library
Planning and Management, SC41-5309, or IBM 3494 User’s Guide: Media
Library Device Driver for the AS/400, GC35-0153.
Here, xx is the device name obtained from the WRKCFGSTS *DEV TAP* command. You
can also select your own tape library device name instead of using TAPMLB01.
Figure 122 shows the Create Device Media Library (CRTDEVMLB) display that
appears after you press the Enter key.
If the 9427 and the 3570 libraries have two tape devices and are attached to a
single AS/400 system, do not use the CRTDEVMLB command separately for
each tape device, but specify both here. If the 9427 or the 3570 library is being
shared between two AS/400 systems, each system must have a media library
description with one tape device.
After you create the media library device description, you must remember to run
the INZBRM OPTION(*DEVICE) command on a V3R2 system, or the INZBRM
OPTION(*DATA) command on a V3R1 system to add the media devices into
BRMS/400.
Note
3494 media library devices cannot be varied on until the ROBOTDEV (robot
device) parameter is updated. This parameter refers to the communications
line associated with the library manager PC and only applies to the 3494. See
9.3.3, “Creating a Robot Device Description (ROBOTDEV) for the 3494” on
page 170, for details.
The DSPHDWRSC *STG command provides the resource names associated with
the tape libraries, controllers, and devices (Figure 123 on page 168).
You can select option 9 to view resources. When you do, the Display Associated
Resources screen appears (Figure 124).
Figure 125 shows the Create Device Description for Media Library
(CRTDEVMLB) command display that is shown after you press the Enter key.
The reverse bold numbers that follow correspond to the reverse bold numbers
shown in Figure 125:
1 If the 3494 is auto-configured, it is auto-configured ONLINE(*NO) because you
should not attempt to vary it on until the ROBOTDEV parameter is filled in
correctly. For all other non-3494 tape libraries, the CRTDEVMLB sets the
ONLINE parameter to *YES.
For the 3494, you have to use the CFGDEVMLB command to define the
communications link. See 9.3.3, “Creating a Robot Device Description
(ROBOTDEV) for the 3494” on page 170, for details.
2 On AS/400 RISC systems, you issue such commands as SAVLIB to the media
library device. The media library device chooses the tape resource for you if
one is available. OS/400 queues requests until an appropriate tape resource
becomes available. The default is to wait for one minute, as specified by
*SYSGEN in the Maximum device wait time parameter (MAXDEVTIME). If a
tape resource is not available, you receive a message on QSYSOPR
indicating that the tape resource is not available.
The MAXDEVTIME parameter specifies the maximum number of minutes a
request will wait for allocation of a tape resource. If the time is reached, a
message is sent to QSYSOPR indicating device allocation time-out. If you
specify a value other than *SYSGEN, such as 120 minutes, OS/400 will queue
your tape resource request until a maximum of 120 minutes before sending a
message to QSYSOPR. The help text in V3R6 is misleading for this parameter
and suggests (wrongly) that this is the amount of time that the tape remains
loaded. See 9.3.5, “Allocating resources” on page 174, for more details on
resource allocation.
Specifying a value of *SYSGEN means that i1.DFTWAIT, the default wait time
of the job attributes, is used instead of a global value for all users using this
particular media library device. You can view the Default wait time (DFTWAIT)
value by running the Display Job (DSPJOB) command. DFTWAIT time is
specified as 30 seconds, but tape management rounds this to the nearest
The CFGDEVMLB command must be issued once for each media library device
description that uses a communication interface, although one line, controller,
and device description is actually used for each Library Manager PC.
This creates the line, controller, and device description under the line resource
called CMN01. Figure 126 shows the Configure Device Media Library
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Note
The RS232 line, controller, and device descriptions are created with
ONLINE(*NO). Do not vary them on. They are varied on as needed internally
by OS/400 when the tape media library is varied on.
Use the following information from the system to configrue the library manager
console. Select APPC as the communication protocol.
b. Write down the following values from the Display LAN Media Library
Information. Write down the values for the following reverse bold numbers
that correspond to the reverse bold numbers shown in Figure 127:
• 1 Host network ID . . . APPN
• 2 Host location name . . SYSTEM01
• 3 Host adapter address . 40101010101
Note: These are sample values. Change these to meet your installation
requirements.
c. Go to your 3494 Library Manager PC, and select the Commands option
from the menu bar.
d. Select Add LAN Host, and add host (your AS/400) information using the
values obtained from the DSPLANMLB command in step b.
3. On the Library Manager PC, select Commands from the menu bar.
4. Select LM LAN Information. Make note of the following information:
• Library Location Name 4
• Adapter Address 5
• On the AS/400, use the CFGDEVMLB command to configure the robot name
(ROBOTDEV) as follows:
CFGDEVMLB DEV(TAPMLB01) Sample library device name.
ADPTTYPE(*LAN)
LIND(TRN3494) Line name created in step 1.
RMTLOCNAME(APPN.MLD01) Information obtained from step 4 4.
APPN is the network ID on the AS/400.
ADPTADR(11221122112) Sample adapter address for the Library Manager
obtained in step 4 5.
Hint
The CFGDEVMLB command will automatically vary on the line, controller,
and device description for you.
For BRMS/400 to work optimally with movement and shared devices, the device
name on each AS/400 system must be the same. For example, TAPMLB01 on
SYSTEM01 must be the same physical library as TAPMLB01 on SYSTEM02.
This can be accomplished easily by taking into consideration the points that are
presented in the following sections.
Important
Whenever you make changes to the media library device descriptions, it is
important that you make the changes in BRMS/400 to reflect the correct
storage location in the media policies, move policies, device descriptions, and
system policies.
The 3494 Automated Tape Library Data Server uses MLDD for adding and
removing the device. To change the 3494 Automated Tape Library Data Server
MLD name, end MLDD (ENDMLD), remove the old MLD device (RMVMLD), and
add the new one (ADDMLD). Initialize MLDD and begin using the new device
name. For more information on the MLDD commands, see IBM 3494 User’s
Guide: Media Library Device Driver for the AS/400, GC35-0153.
Note
If the Autocreate Controller parameter on the LAN line description is set to
*YES, you receive a configuration error when you use the ADDMLD command,
because it automatically creates the controller description before you have the
chance to create the new description yourself. This happens when you wait too
long between the RMVMLD command and the ADDMLD command.
For a LAN-attached 3494 Automated Tape Library Data Server, MLDD requires
the library device description to be in the form MLDxxxxx. Do not use the same
name for the media library device description and the Library Manager remote
location name. This results in a duplicate device description error.
For V3R1 and V3R2, the tape library commands (WRKTAPCTG, DSPTAPSTS,
and so on) are issued with the media library device specified. However, tape
commands (SAVLIB, SAVCHGOBJ, and so on) are issued with the tape device
specified. To change the tape device description, use the following command:
WRKCFGSTS *DEV TAP*
To change the tape resource name, you have to vary off the media library device
description and start System Service Tools (SST). Let us assume that you
currently have a tape resource called TAP11 and you want to change it to be
TAP02. Your media library device description is called TAPMLB01. Use the
following steps as a guide for changing the resource names:
1. Vary off the library device TAPMLB01.
2. Type STRSST.
3. Select the following options:
• Option 1 (Start Service Tool)
• Option 7 (Hardware Service Manager)
• Option 2 (Logical hardware resources (buses, IOPs, and controllers))
• Option 1 (System Bus Resources)
4. Locate the IOP and select resources associated with the IOP. For example,
selecting option 9 for Storage IOP 6501-001 displays the results shown in
Figure 128.
Resource
Opt Description Type-Model Status Name
_ Storage IOP 6501-001 Operational SI01
_ Tape Library 3494-012 Operational TAPMLB01
_ Tape Unit 3590-B1A Operational TAP11
Figure 128. Locating and selectomg resources associated with the IOP
5. Select option 2 (Change Detail) to change the tape unit resource name to a
new name.
6. Exit from SST.
7. Vary on TAPMLB01.
We recommend that you also change the tape device name, which is still called
TAP11, to match the new tape resource name of TAP02. To rename the tape
device description from TAP11 to TAP02, use the command:
WRKDEVD TAP11
For media libraries, the preferred command is Work with Media Library Status
(WRKMLBSTS). It provides the same function as the WRKCFGSTS command,
plus a new function to manage the tape resources associated with the media
library.
Device/
Opt Drive Status Allocation
_ TAPMLB01 VARIED ON
_ TAP01 OPERATIONAL UNPROTECTED
_ TAP02 OPERATIONAL DEALLOCATED
_ TAPMLB02 VARIED OFF
_ TAP03 OPERATIONAL ALLOCATED
When using BRMS/400, device allocations can be manipulated when systems are
sharing one tape library. This can be done by using the UNPROTECTED status
and device wait times. Or it can be done by using ALLOCATE and DEALLOCATE
requests through the Vary Config (VRYCFG) command in the control group exits
(*EXIT). You can use the control groups to ALLOCATE and DEALLOCATE
resources and use job scheduler to coordinate the job dependencies.
Device/
Opt Resource Status
TAPMLB01 VARIED ON
TAP01 OPERATIONAL
TAPMLB02 VARIED ON
TAP02 OPERATIONAL
TAP03 OPERATIONAL
TAPMLB03 VARIED OFF
TAP04 OPERATIONAL
TAP05 OPERATIONAL
Function key F11 invokes the resource allocation display (Figure 131). This
display is used to view the current and requested allocation of the device
resources. Current allocation refers to the present state of the device resource,
and requested refers to the state that occurs when the media library device is
varied on. If the device resource is varied on for a stand-alone tape device
description, “Stand-Alone” is displayed in the Current allocation field.
Option 8 (Work with Description) was enhanced to work with the tape device
description associated with the tape device resource.
Support for multiple devices under a single media library device description is
provided through PTFs for V3R6 and V3R7. See Informational APAR II09724 for
information on the PTFs.
Before you apply the PTFs, each subsystem within the 3494 library is
represented in the system as a library (MLB) device with access only to those
drives in its own subsystem. For example, a 3494 that contains two 3490 tape
subsystems and two 3590 tape subsystems are automatically configured as
shown in Figure 132 on page 178.
Device/
Opt Drive Status Allocation
TAPMLB01 VARIED ON
TAP01 OPERATIONAL ALLOCATED
TAP02 OPERATIONAL ALLOCATED
TAPMLB02 VARIED ON
TAP03 OPERATIONAL ALLOCATED
TAP04 OPERATIONAL ALLOCATED
TAPMLB03 VARIED ON
TAP05 OPERATIONAL ALLOCATED
TAPMLB04 VARIED ON
TAP06 OPERATIONAL ALLOCATED
Figure 132. WRKMLBSTS prior to applying PTFs in a shared environment for the 3494
After you apply the PTFs, you can have one library device description for each
type of tape subsystem in the 3494. All subsystems still have a library (MLB)
device description created using automatic configuration, but you now have
access through any one of those descriptions to all of the drives of the same type
in the 3494. Using our example of two 3490 subsystems and two 3590
subsystems in the 3494, you see that each of the AS/400 systems has four media
library devices configured as shown in Figure 133. You can use the WRKMLBSTS
command to display the configuration.
Device/
Opt Drive Status Allocation
TAPMLB01 VARIED ON
TAP01 OPERATIONAL ALLOCATED
TAP02 OPERATIONAL ALLOCATED
TAP03 OPERATIONAL ALLOCATED
TAP04 OPERATIONAL ALLOCATED
TAPMLB02 VARIED OFF
TAP01 OPERATIONAL DEALLOCATED
TAP02 OPERATIONAL DEALLOCATED
TAP03 OPERATIONAL DEALLOCATED
TAP04 OPERATIONAL DEALLOCATED
TAPMLB03 VARIED ON
TAP05 OPERATIONAL ALLOCATED
TAP06 OPERATIONAL ALLOCATED
TAPMLB04 VARIED OFF
TAP05 OPERATIONAL DEALLOCATED
TAP06 OPERATIONAL DEALLOCATED
Figure 133. WRKMLBSTS after applying PTFs in a shared environment for the 3494
You can now allocate the drives so that you only have two active descriptions:
one to use with your 3490 cartridges and the other to use with your 3590
cartridges. The drives can be allocated to only one library (MLB) device
description at a time. If you want to separate a particular drive, you can manage
this by how you allocate the drives.
To share all tape resources between the two hosts, both systems should have the
media library device description varied on. It is better to ignore the second media
library device description rather than delete it. If you delete it and you have
QAUTOCFG set to on, the media library device descriptions are re-created at
IPL.
All shared devices should be left varied off. When an AS/400 system wants to use
the shared device, BRMS/400 varies it on. After the backup is complete,
BRMS/400 varies it off again.
If both systems are RISC, both systems have TAPMLB01 varied on as before,
and the resources are allocated as UNPROTECTED.
If more control is needed for complex setups where performance or some other
concern needs to be addressed, the second media library device description can
be used to manage the device resource independently. See Figure 134 for the
resulting configuration that is displayed by the WRKMLBSTS command. In this
setup, TAP01 and TAP03 are shared, while TAP02 and TAP04 are dedicated. The
second system can share TAP01 and TAP03, but cannot use TAP02 or TAP04.
Note: On RISC systems, BRMS/400 always selects the first varied on media
library that has resources allocated if *MEDCLS is specified for the device.
Device/
Opt Drive Status Allocation
TAPMLB01 VARIED ON
TAP01 OPERATIONAL UNPROTECTED
TAP02 OPERATIONAL DEALLOCATED
TAP03 OPERATIONAL UNPROTECTED
TAP04 OPERATIONAL DEALLOCATED
TAPMLB02 VARIED ON
TAP01 OPERATIONAL DEALLOCATED
TAP02 OPERATIONAL ALLOCATED
TAP03 OPERATIONAL DEALLOCATED
TAP04 OPERATIONAL ALLOCATED
Figure 134. Work with Media Library Status: TAPMLB01 and TAPMLB02 varied on
If you want to clean up your device descriptions, you can use the following
command as an alternative:
INZBRM OPTION(*DEVICE)
Instead of adding the new devices, this clears all the existing information and
replaces it with information about the devices currently attached to the system.
We recommend that you print your existing media device information before you
run this command to capture any changes you may have already made to
existing default values. You must use the “Print Screen” utility to obtain hard
copies.
After you’ve created the BRMS/400 device descriptions, you need to update the
device location, next volume message and tape mount delay, auto enroll media,
shared device, and IDRC parameters to reflect your installation. Use the Work
with Device Information ( WRKDEVBRM) command to make these changes.
The INZBRM command automatically creates media classes appropriate for the
devices. However, at this stage, you may want to review these and create
additional ones.
You should pay special attention to naming locations when you are using the
9427 tape library in split mode. Using the bonus slots in a split library
configuration can result in a tape cartridge being moved to a slot in either half of
the library. Since each host has access to only one half, the tape cartridge may
become inaccessible to the host after the move.
Normally, you create a single storage location for the tape library unit and define
all of the tape drives within the frame as being in that location. However, in split
mode, tapes in Magazine 1 of the library can never be selected by the accessor
for loading in tape drive 2, nor tapes from Magazine 2 in drive 1.
A possible naming convention that you can use when using the 9427 tape library
with BRMS/400 is to have the storage location for the first magazine named as
MLB9427TOP and the second magazine named as MLB9427BOT using the
following steps:
1. Create a new storage location, either MLB9427TOP or MLB9427BOT, as
appropriate.
2. From the BRMMED menu, select option 8 (Work with device information).
You find two device descriptions defined within BRMS/400. These have been
generated from the OS/400 device descriptions and called TAPxx.
3. Update both entries to specify device location = MLB9427TOP (if you are on
System A) or MLB9427BOT (if you are on System B) as appropriate.
Although this device description is only used when you explicitly request
TAPxx, for example, in a stand-alone environment where the accessor is
unavailable, we recommend, for completeness, that you update this as well as
the media library device. They are, in practice, the same device.
4. From the BRMMED menu, select option 9 (Work with media libraries).
An entry has been automatically generated for you with a name of MLB9427.
Update this entry with the specified storage location MLB9427TOP or
MLB9427BOT.
You have now defined Drive 1 as being located in storage location MLB9427TOP,
and Drive 2 as being located in storage location MLB9427BOT.
To preserve the integrity of the inventory, use the Move Tape command on the
9427 tape library front panel to move tapes to the appropriate magazine.
When you use BRMS/400 with non-barcode reader libraries, you should be
careful when you initialize blank tapes. See 9.5.1, “Special cartridge identifiers”
on page 184, for more information.
The easiest way to find existing cartridges for use in the media library device
inventory is to use the Work with Media Library Media (WRKMLMBRM)
command. For example, use the following command to display a complete
inventory of cartridges and volume identifiers and their status as shown in Figure
135:
WRKMLMBRM DEV(TAPMLB01)
---BRM Information---
Opt Volume Category Media Class Expired Status
You can see a similar display by using the OS/400 Work with Tape Cartridges
(WRKTAPCTG) command. You need to use F11 on the Work with Tape Cartridges
display to view the category, density, and other information that appears on the
WRKMLMBRM display.
Hint
If the system name is changed, all cartridges in the associated categories
become unavailable until a categroy is created with the previous system name.
Cartridges in the *NOSHARE category that belong to that system are not
accessible. We highly recommend that you remove all cartidges from the
media library device or change them to the *SHARE400 category prior to
changing the system name by using a media class that is SHARE(*YES).
For libraries without a vision system, which includes the 3590 tape device and
3570 Magstar MP tape subsystem, specially generated cartridge IDs have been
implemented on RISC systems:
NLTxxx Non-Labeled Tape: This cartridge contains data written in
non-Standard tape label format.
CLNxxx Cleaning: This cartridge has been identified as a cleaning tape.
BLKxxx Blank: This cartridge contains no data.
UNKxxx Unknown: This cartridge is not identifiable.
IMPxxx Import: This refers to the cartridge that is in the Priority slot.
SLTxxx Slot: This refers to the cartridge by its slot number. This only occurs if
the device description is created with the GENCTGID parameter set to
*SYSGEN mode (see 9.3.2, “Creating media library device
descriptions” on page 168) and is not appropriate for BRMS/400,
which refers to media by volume identifier.
When using BRMS/400 with non-barcode reader libraries, take care when
initializing blank tapes. The system generates a volume ID of BLK001 and so on.
BRMS/400 users should never initialize cartridges to these IDs, whether through
a BRMS/400 or OS/400 command. If a real volume exists in the library with ID
BLK001 and a new tape is added that causes OS/400 to generate another
BLK001, you receive an instant duplicate. Further, BRMS/400 thinks that every
new BLK001 is that same original BLK001 and tries to use it for saves and so on.
A similar situation can occur when you add an already known cartridge to the
library through the priority slot using CHECKVOL(*NO). The cartridge is moved to
a slot in the ACF, but the cartridge identifier remains IMP001. See 9.5.4,
“Importing cartridges” on page 187, for more information on importing cartridges.
You must not use the ADDMLMBRM command to initialize these tapes. You must
first put the media library device into auto-mode and use the ADDMEDBRM command
to add the cartridges. Once the cartridges are added, you should use the
MOVMEDBRM command to place the cartridges in the correct library location. You
must hold the library using the WRKMLBBRM command to do this and release the
library when you have completed the move operation.
This should not really concern BRMS/400 users. If, for example, a scratch volume
is required, BRMS/400 suggests a volume from its own scratch pool based on the
media class selected for the save operation. This is passed to the media library
and the specified volume loaded.
If you ever receive a *MOUNTED volume not correct type of message, it usually
means that BRMS/400 has run out of tape volumes to suggest at that location.
You should check for the tape volumes by using the WRKMEDBRM command and the
WRKMLMBRM command. Ensure that volumes are available at the location of the
library.
On RISC systems, the End option (ENDOPT) parameter has a significant affect
on the operation of the media library device.
In a multiple user environment, take care when using *LEAVE. Consider the
situation where SYSTEM01 and SYSTEM02 share the same library that contains
two drives:
• SYSTEM01 processes a control group containing some saves with *EXIT
processing in between.
• SYSTEM01 starts the save to cartridge XYZ001, and the user changes the
ENDOPT parameter to *LEAVE.
• SYSTEM01 performs *EXIT processing for some minutes before the next save
starts.
• At that point, if SYSTEM02 attempts to access the drive, it will fail. However, if
another job on SYSTEM01 is queued and requesting cartridge XYZ001, that
job can interrupt the job that did the *LEAVE processing and steal the
resource and the cartridge.
• When job 1 on SYSTEM01 resumes saving after the *EXIT, it finds the
cartridge is not available and tries another cartridge, perhaps mounting it on
the second drive. In this way, it is possible to have one control group with
APPEND(*YES) to end up on two different cartridges.
You should be aware of this when you queue up save jobs on the same system. If
necessary, change the media class so that the same cartridge ID is not requested
(BRMS/400 does not know which cartridge is being used in a control group that is
in progress until the save completes and the media information is written). In
other words, *LEAVE processing holds the cartridge to the resource for that
system; it does not lock the resource to the job.
In V3R1 and V3R2, the priority slot of the 3590 with automated cartridge facility
and the 3570 Magstar MP tape library has a simple implementation. The
cartridge in the priority slot is assigned a generated identifier of IMP001 (actually
IMPxxx where xxx is the next available IMP number). The commands for this
cartridge can either reference IMP001 or the actual volume identifier in the VOL
parameter. Upon issuing the command, the cartridge is moved from the priority
slot to the device. When the device is unloaded, the cartridge is returned to the
priority slot for removal.
V3R6 and V3R7 enhances the library support to provide full import capability from
the priority slot to the device or ACF inventory. Because there is often more than
one cartridge to be imported, we still recommend that you physically replace the
cartridges in a magazine and then re-inventory the magazine.
Cartridges that have been imported into the library remain in the *INSERT
category until they are enrolled into BRMS/400. To do this, you can either use the
Work with Media Libraries (WRKMLBBRM) command and type option 11 next to the
required library or directly use the Add MLB Media using BRM ( ADDMLMBRM)
command. The tapes must already be initialized if it is a non-barcode reading
media library (Figure 136 on page 188).
If the shared media attribute in the media class is *NO, the category is changed
from *INSERT to *NOSHARE. Otherwise, the category is changed to
*SHARE400.
For such libraries as the 3494 Automated Tape Library Data Server where the
cartridges are physically moved to a storage cell location by Library Manager, a
single ADDMLMBRM command changes all volumes with the *INSERT category.
It is also possible to import a cartridge to the library using the OS/400 Add Tape
Cartridge (ADDTAPCTG) command, for example:
ADDTAPCTG DEV(TAPLIB01) CTG(TAPE01) CGY(*SHARE400) CHKVOL(*YES)
However, we recommend that you do not use this technique when using
BRMS/400 enrolled tapes. In this case, you lose the benefits of the
ADDMLMBRM command, which allows you to run the ADDTAPCTG and
ADDMEDBRM commands and moves the media to your library using the
MOVMEDBRM command through one simple command.
For the 3590 tape device and 3570 Magstar MP tape subsystem on CISC
systems, the cartridges are left in the device in the *EJECT category. This also
applies to 9427 tape library on CISC or RISC since the 9427 tape library does not
have a convenience station.
For all libraries, except the 9427 tape library on RISC systems, and for 3494
Automated Tape Library Data Server on CISC, the cartridges are moved to the
convenience station. If more cartridges exist than the convenience station can
hold, the additional cartridges are queued by the media library device for ejection.
When BRMS/400 movement is run, it causes a volume to move from the library. A
RMVTAPCTG command is also issued to eject the cartridge. As long as the
system that runs the MOVMEDBRM command is attached to the library (in other
words, it recognizes the media library device description), it can take action on
the RMVTAPCTG command and eject the cartridge. If there are multiple systems
and multiple libraries attached to different systems and the MOVMEDBRM
command is run on one system only, the BRMS/400 files are updated around the
network, but the cartridges are not ejected from the remote libraries. To ensure
cartridges are ejected, run MOVMEDBRM on those systems that are attached to
the libraries. We recommend you run the MOVMEDBRM command individually
on all systems in the network.
Four files in QUSRSYS are required for complete automation of the media library
devices: QATAMID, QLTAMID, QATACGY, and QLTACGY. If these files do not
exist on the system, a limited set of automation function is supported. Cartridges
can be mounted by specifying the cartridge identifiers in the VOL parameter of
the OS/400 commands. This subset of automation does not support the use of
the cartridge commands such as WRKTAPCTG, DSPTAPCTG, and so on.
Once the resource is deallocated, it is a free resource for any device description.
Tape device descriptions are auto-configured for the tape resources, but are not
varied on. The WRKCFGSTS *DEV *TAP command displays the current tape device
descriptions that exist on the system. Find the device description that
corresponds to the tape resource, and vary on the tape device description.
Alternatively, use the WRKMLBBRM command to hold the media library device. Now,
commands can be sent to this device description, but no library functions occur.
Many media library devices provide modes or commands to move media to the
device during a stand-alone operation. The 9427 and 3590 media library devices
both support modes that are used for stand-alone devices. The 9427 provides a
sequential mode where cartridges are moved to the device automatically in
sequence from the inventory. The 3590 has three modes for stand-alone mode:
auto, manual, and accumulate. The Library Manager software on the 3494
supports the stand-alone mode from the command pull-down on the Library
Manager console. In this mode, the operator can mount a tape from the I/O
station or from the inventory either by volume identifier or by a category.
The 3570 has an automatic mode, which loads cassettes from right to left. In the
manual mode, the cassettes are loaded in the furthest right slot.
The intent of this chapter is not to provide you with step-by-step instructions on
how you should recover your AS/400 system. For this, you must use the
BRMS/400 Recovering Your Entire System report for a guide to the recovery
steps for your specific installation.
Every effort has been made in BRMS/400, in the recovery manuals, and in this
redbook to ensure that the recovery information is complete. However, the only
way to know that you have a recoverable system is to try it.
There are two major factors to consider: data and timing. Of course, there are
other factors such as people, skills, facilities, and processes. However, it is not
within the scope of this redbook to cover these aspects of recovery planning.
You can secure you data by making sure you have complete and up-to-date
backups, including recovery documentation and regularly moving backups off-site
or to a secure location. Timing needs to be addressed in the design of your
backup.
For example, it may be necessary to recover a critical application and restart the
business before any other recovery is undertaken. Using backup lists to secure
critical files, documents, spooled files, in addition to the main libraries for this
application, can facilitate this.
You may have to ensure that unnecessary recovery of incremental saves does
not occur. Rebuilding access paths is also time consuming. Where possible, you
should have access paths and their associated files in the same libraries and
save the access paths.
The numbers in reverse bold that follow correspond to the numbers in reverse
shown in Figure 137:
1 To recover a specific control group, enter *CTLGRP. You are prompted for the
control group name. If the restore is halted or fails, you can restart the
recovery from the point of failure by specifying *RESUME here. With the
*RESUME option, no other parameters are shown.
2 If the latest backup was to a save file that still exists, setting this parameter to
*YES includes the save file in the recovery report. If you want to exclude this
latest save (for example, recover only from off-site tapes), setting this
parameter to *NO will cause BRMS/400 only to use information from the tape.
3 You can recover from a location (for example, an older copy now in the vault).
You can specify up to 10 locations.
4 You can specify that you do not want to recover libraries that have been
deleted after the save to which you are now recovering. That not only helps
recovery time but also reduces catch-up time.
If you created libraries, but have not run maintenance before deleting them
again, these libraries are still marked for recovery. You must run maintenance
between creating the library and deleting it to have it omitted. One way around
this is to manually delete the library from the WRKMEDIBRM displays.
5 You can specify the system name and remote location of another system in
your BRMS/400 network from which to restore media information.
As a general rule, saving recovery data should always be done at the end of
processing. QUSRBRM is frequently saved early in the backup cycle. It is
important for recovery to have the most up-to-date recovery information.
To actually perform the recovery, either use the STRRCYBRM command with the
action parameter of *RESTORE or use the BRMS/400 recovery menus.
Beginning with V3R6, V3R7, and V3R2, a new parameter, Receive Media
Information (circled in Figure 138) has been introduced on the Change Network
Group display (option 4 from the System Policy menu). This gives you the ability
to specify for a system or systems, whether you want to receive media content
information from the other systems in the network group.
If you use this feature, you have the recovery information at a central point and
can create recovery reports for other systems, if necessary.
Note: When you recover from SAVSYS or IBM distribution tapes, your tape
libraries must not be in random or library mode. See the appropriate Operator's
Guide for the library in use to set the correct mode.
Important
We used the 3494 library device as a topic to discuss the recovery of an entire
system. The intent of Table 4 on page 196 and subsequent sections is to
provide an overview of the steps that are required when restoring your CISC
AS/400 system or the RISC AS/400 system. You must not use this section as a
checklist to perform your system recovery. You must always use the BRMS/400
Recovering Your Entire System report along with Backup and Recovery - Basic,
SC41-4304, to guide you through the correct recovery steps based on your
OS/400 release.
Your starting point in the recovery process should always be with the Recovering
Your Entire System report (QP1ARCY) produced by BRMS/400. This report
identifies the first volumes that are needed during the recovery process. You
should use the Recovery Volume Summary Report (QP1A2RCY) that is produced
together with the System Recovery Report to identify the locations for the
required tape volumes.
1 Recover Licensed Internal Code Control panel function (02-D IPL) in manual mode
Function code 24 for CISC
Install Licensed Internal Code menu for RISC
• Option 2 if restoring on a different system
• Option 3 if restoring to the same system.
3b* Recover MLDD, 3494 library driver code • RSTLIB QMLD (for 3494 only)
(not needed for RISC AS/400 systems). • RSTLIB QUSRMLD (for 3494)
13a* Apply journal changes Refer to Backup and Recovery - Basic, SC41-4304,
for information on how to apply journal changes.
Notes:
Step 3b is only required for the 3494 library device with V3R1 or V3R2.
Step 8 through step 15 require no manual intervention.
Ensure the media library devices are in the correct mode. For devices other than
the 3494, this is automatic/sequential mode or manual mode. See the device
documentation on how to properly change the mode for the hardware. The
random or library mode cannot be used until OS/400 is loaded.
For the 3494 Automated Tape Library Data Server, use Library Manager to set up
the library as a stand-alone device to mount your SAVSYS tape or the Licensed
Internal Code distribution tape. See 8.4, “Library Manager for the 3494” on page
160, for more information on setting up stand-alone mode.
If you have multiple tape devices inside the 3494 or multiple 3494s, the device
names may vary between the different systems. Notice that for each AS/400
system, the tape drive name and the corresponding device name of the library
manager for this device name has to be selected in the stand-alone mode, for
example:
AS/400 AS/400 Library Manager
System Tape Device Device Name
SYSTEM01 and SYSTEM02 share the same device, and SYSTEM03 and
SYSTEM04 share the other device.
Depending on your OS/400 release, the actual step numbers outlined here can
change. In addition, reference to any documentation can also change with
each release. Where possible, we attempted to identify the key differences
between the various releases of OS/400.
Select 02-D IPL in Manual Mode on the AS/400 control panel to load the Licensed
Internal Code and OS/400 from the alternate IPL device.
Select the required option (function code 24) on the front AS/400 control panel for
systems at V3R1 and V3R2. For systems with V3R6 and V3R7, on the Install
Licensed Internal Code display, select option 2 if you are recovering to a different
system or option 3 if you are recovering to the same system as detailed in Backup
and Recovery - Basic, SC41-4304.
Step 1 in the following example assumes that you are using V3R1 or V3R2:
STEP 1: Recover Licensed Internal Code
Use media shown in the this example and the procedure for
"Recovering the Licensed Internal Code" using function code 24
in the book in chapter 10.
Saved Save Save File Control
Item Type ASP Date Time Objects Seq Group Volume(s)
*SAVSYS *FULL 01 6/04/00 20:35:20 0 1 RHSAVSYS ABC011
After you install the Licensed Internal Code, select Install the Operating System
on the OS/400 installation menu:
STEP 2: Recover operating system.
Use the media shown here and the procedure for "Restoring the Operating
System using the Complete Restore Method” as detailed in the Backup
Recovery - Basic book.
Saved Save Save File Control
Item Type ASP Date Time Objects Seq Group Volume(s)
*SAVSYS *FULL 01 6/04/00 20:35:20 0 1 RHSAVSYS ABC011
The disk units may be in non-configured status for different reasons so they have
to be configured. Refer to Backup and Recovery - Advanced, SC41-4305, if you
plan to configure disk protection or user ASPs. For V3R7, the disk configuration
information is in Backup and Recovery - Basic, SC41-4304.
The first sign-on to the system uses no password. Shortly after that, you are
asked to change the password for QSECOFR. The display asks for the old
password, as well as a new password. The old password for QSECOFR is set to
the default value, QSECOFR. This new password display is only for V3R2 and
V3R7. On V3R1 and V3R6, no password is required at this time.
To see which tape devices are configured on your system, use the following
command:
WRKCFGSTS *DEV TAP*
At this point on RISC systems, if you had auto-configure on, you can go to
random mode on your 3494. You can use the CFGDEVMLB command to update
the Robot device name (ROBOTDEV) parameter for the 3494 Automated Tape
Library Data Server. See 9.3.3, “Creating a Robot Device Description
(ROBOTDEV) for the 3494” on page 170, for more information.
Note: On the restore command, you need to specify the media library device and
the volume identifier to have the tapes mounted automatically.
On CISC systems, you must wait until after step 7 when you have restored the
configuration data before you can go to random mode.
If you prefer to wait until after step 7 for RISC systems, you should DEALLOCATE
the library resource and vary on the tape device. When step 7 is completed, vary
off the tape device and vary on the library resource as ALLOCATED
(UNPROTECTED). For token-ring attached libraries, you need to vary on the
token-ring line.
STEP 3: Recover the BRMS/400 product and associated libraries.
The BRMS/400 product and associated libraries must be recovered
before you can use the product to perform other recovery operations.
Use WRKCFGSTS *DEV *TAP to see which tape devices are configured.
Then run RSTLIB for each of the following libraries specifying SEQNBR
and using media as shown below.
Saved Save Save File Control
Item Type ASP Date Time Objects Seq Group Volume(s)
QUSRBRM *FULL 01 6/04/00 20:49:29 143 13 RHBRMS ABC017
QBRM *FULL 01 6/04/00 20:50:09 823 14 RHBRMS ABC017
QUSRMLD *FULL 01 6/04/00 20:50:54 8 15 RHBRMS ABC017
QMLD *FULL 01 6/04/00 20:50:56 375 16 RHBRMS ABC017
QMSE *FULL 01 6/04/00 20:51:10 5 17 RHBRMS ABC017
Use the sequence number for the following restore so you are sure to restore the
correct objects in case there is more than one item of QUSRBRM on that tape.
Using the sequence number also improves performance if you are using a 3590
tape device.
STEP 4: Recover BRMS/400 related media information.
You must recover this information for the BRMS/400 product to
accurately guide you through remaining recovery operations.
To do so, run RSTOBJ OBJ(*ALL) SAVLIB(QUSRBRM) MBROPT(*ALL)
specifying library name, SEQNBR, and using media as shown below.
Saved Save Save File Control
Item Type ASP Date Time Objects Seq Group Volume(s)
QUSRBRM *QBRM 01 6/05/00 8:21:30 10 1 RHBKUGRP ABC592
Before you recover the user profiles, clear the BRMS/400 device and media
library information, and initialize the files with the tape devices currently
configured on the system. Use the command:
INZBRM OPTION(*DEVICE)
Verify your BRMS/400 device and media library information for the correct
settings (for example, next volume message, densities, device location, shared
devices, and so on). Some of the values are reset to the defaults when you use
the INZBRM OPTION(*DEVICE) command.
If you are recovering to a different system and your security level is 30 or greater,
*ALLOBJ special authority has been removed from all user profiles, except
certain IBM-supplied profiles. Use the CHGUSRPRF command to give *ALLOBJ
authority to user profiles who need it.
Note: You should use the CHGUSRPRF command to grant *ALLOBJ authority to
user profiles after the recovery is complete as detailed in Backup and Recovery -
Basic, SC41-4304. You should also review the implications of setting the Allow
object differences parameter (ALWOBJDIF) to *ALL in Backup and Recovery -
Basic, SC41-4304. You should only use *ALL when you perform a full system
recovery and there is no data on the system. Specifying ALWOBJDIF(*ALL) when
you recover to a different system allows the restored data to be automatically
linked to the authorization lists associated with the object.
You must restore specific system libraries before you can use BRMS/400 to
perform other recovery operations and tape automation. These libraries are
QGPL, QUSRSYS, and QSYS2. QUSRSYS contains the tape exit registration
information and QSYS2 contains the LAN code for the 3494 media library.
The QGPL library must be restored prior to the QUSRSYS library because there
are dependencies in QGPL that QUSRSYS needs.
Step 6 is new a step beginning with V3R6 and V3R2. In V3R1, this step is
equivalent to step 5.
STEP 6: Recover BRMS/400 required system libraries.
You must restore specific system libraries before you can use BRMS/400 to
perform other recovery operations. To do so, run STRRCYBRM OPTION(*SYSTEM
ACTION(*RESTORE) OMITLIB(*DELETE) using media shown below.
You are now ready to restore your configuration data. When you restore the
configuration data, you should use F9 to see the restore command defaults from
the Select Recovery Items display. If you are restoring configuration data on the
same system that you had saved from, you should leave the System resource
If you have restored the SRM database, and the hardware configuration does not
match, to correct the errors, you must refer to the “Correcting Problems with the
System Resource Management Database” chapter in Backup and Recovery -
Basic, SC41-4304.
For RISC AS/400 systems, only token-ring descriptions are found in the SRM
database. The SRM database has been incorporated into Hardware Resource
Manager (HRM). You should not see the same problems with a corrupted SRM
database as with the CISC AS/400 systems.
STEP 7: Recover configuration data.
You should restore a current version of your system configuration.
To do so, run STRRCYBRM OPTION(*SYSTEM) ACTION(*RESTORE) OMITLIB(*DELETE)
using media shown below.
Use the INZBRM *DEVICE command to clear the BRMS/400 device and media
library information and initialize the files with the tape devices currently
configured on the system after you have restored the configuration.
Item Type ASP Date Time Objects Seq Group Volume(s)
*SAVCFG *FULL 01 6/04/00 20:35:20 59 12 RHSAVSYS ABC011
For a LAN-attached 3494 Automated Tape Library Data Server, you must vary on
the LAN line description. To vary on the LAN description, use the command:
WRKCFGSTS *LIN
If your 3494 is attached through an RS232 connection, you do not need to vary
on the RS232 line description.
Use the following command to clear the BRMS/400 device and media library
information and initialize the files with the tape devices currently configured on
the system:
INZBRM OPTION(*DEVICE)
Verify your BRMS/400 device and media library information for the correct
settings (for example, next volume message, densities, device location, shared
devices, and so on). Some of the information is reset to the default values by
using the INZBRM OPTION(*DEVICE) command after you restore the configuration.
If you used the 3494 in stand-alone mode and there is another cartridge required,
the cartridge that is still inside the drive from the stand-alone mode is demounted,
and the required cartridge is mounted. On the Library Manager, you see the
demount complete display shown as shown in Figure 116 on page 162. You do
not have to reset stand-alone mode on the Library Manager; this is done
automatically for you.
STEP 8: Recover IBM product libraries.
You should restore the current version of IBM product libraries on your system.
To do so, run STRRCYBRM OPTION(*IBM) ACTION(*RESTORE) OMITLIB(*DELETE)
using the media shown here.
Press F9 (Recovery defaults) on the Select Recovery Items display.
Ensure the tape device name that you are using is correct.
Saved Save Save File Control
In the preceding step, we showed you only a few libraries to restore to give you an
idea. In reality, the list is longer than shown in the preceding report. Your
BRMS/400 System Recovery Report lists all of the IBM libraries that are required
to be restored.
Before the recovery, the display in Figure 139 shows where you can select which
libraries to recover, or you can press F16 on the Select Recovery Items display to
select all of the libraries. Unless you are absolutely sure of the IBM product
libraries that you want to omit, and if you are concerned about the recovery time
window, we recommend that you select all of the IBM product libraries.
You can use the F9 function key to change the recovery defaults as shown in
Figure 140. You can set the recovery defaults to specify:
• The tape drive you are using on the device parameter.
• *ALL for the allow object difference parameter if recovering on a different
system.
• *ALL for the system resource management parameter if you are recovering on
your system. You should use *NONE if you are recovering on a different
system.
If the BRMS/400 recovery ends in error or is cancelled using F12, you can restart
the procedure using the STRRCYBRM *RESUME command. The Select Recovery Items
display is set at the library that has to be restored next.
Note: In V3R1, any changes to recovery defaults do not remain in force if the
recovery ends in error or has been cancelled using F12. Beginning with V3R6
and V3R2, the changes in recovery defaults remain until the user signs off the
system.
The next step is to recover user libraries. Depending on how you saved the
libraries, you can choose the STRRCYBRM OPTION (*ALLUSR) or STRRCYBRM
OPTION(*CTLGRP) commands. The latter gives you more control and allows you to
start concurrent restores. In a full restore, BRMS/400 restores full and
incremental saves. You may want to avoid unnecessarily restoring multiple times
by using control groups. You should also give consideration to unnecessarily
rebuilding access paths when restoring your data.
Important
If you used option 21 from the SAVE menu to save your entire system, you
should use option 21 from the RESTORE menu even if you have BRMS/400
installed. You should not mix native save and restore menu options with
BRMS/400 save and resotore process.
The following step only shows you a few libraries for reference. The Recovering
Your Entire System report lists all of the user libraries that need to be restored.
STEP 9: Recover user libraries.
You should restore the current version of your libraries.
To do so, run STRRCYBRM OPTION(*ALLUSR) ACTION(*RESTORE) OMITLIB(*DELETE)
using the media shown here.
Depending on your recovery strategy, you may choose to use the
STRRCYBRM OPTION(*CTLGRP) ACTION(*RESTORE) OMITLIB(*DELETE) command to
restore individual control groups.
ATTENTION - If you have logical files whose based-on file is in a different
library, you must restore all based-on files before you can restore the
logical file.
If you use journaling, the libraries containing the journals must be
Step 11 is new beginning with V3R2 and V3R7. You can run the STRRCYBRM
command with the *LNKLIST value to restore the integrated file system (IFS)
objects.
For V3R6, the IFS objects are restored when you restore the LINKLIST item
listed under your user libraries in the backup control group. When you restore this
control group, your IFS objects are restored.
For V3R1, you have to remember to restore IFS objects manually. In V3R1, there
is no special *LINK value or *LNK type, and you cannot use LINKLIST in the
STRRCYBRM command. You must use an exit (*EXIT) within the control group
that performs a save operation (SAV) of the integrated file system to a save file.
Once you recover the library containing the save file, you can use the Restore
Object (RST) command outside of BRMS/400 to restore the integrated file system
objects. See 6.6, “Saving and restoring V3R1 IFS data with BRMS/400” on page
146, for additional information.
STEP 11: Recover objects in directories.
Run STRRCYBRM OPTION(*LNKLIST) ACTION(*RESTORE) using the media shown here.
Saved Save Save File Control
Item Type ASP Date Time Objects Seq Group Volume(s)
LINKLIST *FULL 01 6/05/00 8:26:51 4,072 1 RHBKUGRP ABC594
Step 12 is also new beginning with V3R2 and V3R7. Although the save spooled
file support within BRMS/400 is supported since V3R1, the recovery report for
V3R1 and V3R6 does not guide you through the actual recovery of the spooled
files. With V3R1 and V3R6, you have to remember to use the WRKSPLFBRM
command to recover your spooled files.
STEP 12: Recover Spooled files.
If spooled files were saved, restore your spooled files using the
WRKSPLFBRM command.
After the recovery has completed, you should check the job log to ensure all
objects were restored and that all authorities were correctly recovered. The job
log contains information about the restore operation. Print the job log and any
other remaining spooled output.
To print the job log, use the SIGNOFF *LIST command or the DSPJOBLOG * *PRINT
command.
The CPC3703 message is sent to the job log for each library that was
successfully restored. The CPF3773 message is sent to tell you the number of
objects that were restored. Sometimes objects may not be restored for various
reasons. You need to identify these objects and take appropriate action to
recover these objects.
You must check for all error messages, correct the errors, and restore any
missing objects from the media.
STEP 15: IPL
Return system to normal mode and IPL using PWRDWNSYS OPTION(*IMMED)
RESTART(*YES).
Figure 141 on page 206 shows the parameters for the WRKMEDIBRM command.
You have to press Enter to see these last two entries. The default is *LCL to
search the local system. However, you may enter the location and network
identification of another system in the network to work with that system. If the
entry in the Receive media info parameter of the system group is set to *LIB, all
library entries from the history of the remote system are on your system.
Otherwise, a DDM link is activated and you receive the information from the
remote system. The values in the FROMSYS parameter are ignored if you specify
a volume identifier in the VOL parameter. In this case, the values associated with
the volume are used.
When you press Enter, the Work with Media Information display is shown (Figure
142). Select option 7 to select the library to restore.
Position to Date . . . . .
Since there may be more than one entry, make sure you choose the entry with
the date and time that correspond to the save from which you want to recover.
Use F9 to change the recovery default options and F14 to submit to batch if
required.
This procedure can be used between systems with different releases and also
between systems with CISC and RISC OS/400 releases. If you restore to a
previous release, you have to select your save with the Target release parameter,
specifying the release to which you are going. This can be selected in the backup
control group or in the save commands such as SAVLIBBRM or SAVOBJBRM.
At the completion of the recovery, you receive a message that tells you how many
objects have been restored. Use the following command to look at the recovery
activity:
DSPLOGBRM *RCY
If you have not saved object detail, you cannot use BRMS/400 to search for the
object. However, you can still restore it if you know its name. At this point, if you
replace option 1 with option 7 (Specify object), you are prompted with the Restore
Object Display (Figure 144).
The only way to restore a single user profile is to use the native OS/400
RSTUSRPRF command.
Beginning with V3R7, there is a new special value called *LINK. See 6.5,
“Restoring IFS directories with BRMS/400” on page 142, for more details on the
integrated file system.
For V3R1, you can only save the integrated file system using the SAV command
in a *EXIT in a control group. BRMS/400 recovers the library where you
processed the SAV command. However, you must use RST outside of BRMS/400
to recover the integrated file system. See 6.6, “Saving and restoring V3R1 IFS
data with BRMS/400” on page 146, for more information.
If you have access to the Internet, use the following procedure to find current
information about upgrading BRMS/400 and other IBM products:
1. Access the AS/400 service home page:
http://as400service.rochester.ibm.com
2. From the Service page, select AS/400 Authorized Program Analysis
Reports (APAR).
3. From the APAR page, select all Informational APARs.
4. Use the search function to find Informational APARs about BRMS/400 (or
other licensed programs that you have installed).
Before you begin your save using the Enhanced Upgrade Assistant tool, you
must complete the following tasks:
1. Sign on the system console or a workstation that is assigned to the controlling
subsystem. Sign on with a user profile that has all the authorities that
Enhanced Upgrade Assistant requires, such as QSECOFR. This ensures that
you have the authority that you need to place the system in the necessary
state and to save everything.
2. Make sure that Client Access is not active at your workstation.
3. If you plan to run the save procedure immediately, make sure that no jobs are
running on the system. Use the WRKACTJOB command.
If you plan to schedule the save procedure, send a message to all the users
that informs them when the system will be unavailable.
4. If you use the LAN server, QNetWare, or Lotus Notes licensed programs, you
must vary off the network server descriptions before you begin the save
procedure.
5. If you are using MQSeries (5763-MQ1 or 5763-MQ2), you need to quiesce
MQSeries for OS/400 before you save the system.
6. Mount the first tape.
BRMS considerations
• Do not use BRMS/400 to perform this save operation.
• Perform the following steps to disable BRMS/400 from this system:
1. Type: WRKPCYBRM *SYS
2. Select option 1 (Change System Policy).
3. Change the Media Monitor parameter to *NO.
• Do not use tapes that are enrolled in BRMS, contain active data, or are
in a media library device. Ensure the tape volumes you use are scratch
volumes, and label your tapes correctly.
Note: If you are using a shared media inventory environment with
BRMS/400, the tapes you use to perform the save for the upgrade are
not protected from being overwritten while the BRMS/400 media monitor
is turned off.
• This save operation does not affect the information that BRMS/400
stores for managing the process of saving changed objects.
11.5 Deleting the libraries for the media library device driver
If you had the Media Device Driver program (5798-RZH) on your source system,
you would need the program to perform your save operations successfully.
Therefore, you cannot delete it before your final save. However, the functions that
5798-RZH provided on your source system are included in the operating system
on your target system. Therefore, you should delete the 5798-RZH libraries. Type
the following two commands:
DLTLIB LIB(QMLD)
DLTLIB LIB(QUSRMLD)
For information on the type of objects that you may consider for archiving and
how to set up BRMS/400 to produce an operational Dynamic Retrieval solution,
see Chapter 13, “Practical implementation of hierarchical storage management
archiving capabilities” on page 261.
For details about the types of data to archive and setting up retention periods,
see Chapter 13, “Practical implementation of hierarchical storage management
archiving capabilities” on page 261.
Objects selected to be archived are identified by the entire auxiliary storage pool,
library, or as lists of objects (known as archive lists). The ASPs, libraries, or lists
are then included in a BRMS/400 archive control group. Each control group has
parameters that control such things as the amount of time the object must have
been inactive to be selected for archive, whether save with storage freed is used,
and so on. These parameters are known as the control group attributes. These
details may also be set in the Archive Policy, which sets the defaults to use
The BRMS/400 archive control groups used for save with storage freed also
defaults to saving the access paths of the file members. This is a performance
consideration, and it may be changed by the user. It means that the object takes
longer to save (archive) but eliminates the need for a potentially lengthy access
path rebuild on restore (retrieve).
Figure 145 shows the makeup of an AS/400 object and how that object may look
after being saved with storage freed. The object description contains only a small
amount of data that describes the object, including object name, object type,
library name, security information, and so on. This sort of information is found
when you process such commands as DSPOBJD, DSPFD, and DSPFFD.
It is the data portion that contains all of the real data to be processed (for
example, all of the records in a physical file). This data constitutes the majority of
the object size. When objects are saved with storage freed, the data portion is
deleted from the system after successfully completing the save. The object
description is retained, and the details are updated to record the save date, time,
and the media where the data is stored.
data
Figure 145. AS/400 objects before and after save with storage freed
Figure 145 shows the structure of an AS/400 object (note that the object
description is typically much smaller than the data part) and how save with
When you access the object, the system searches the job's library list or the
library name referenced by the object. If the system finds that the data portion of
the object is missing (object was saved with storage freed), BRMS/400 proceeds
to check its inventory of archived objects to see whether it has indeed been
archived by BRMS/400. If the object is found in the BRMS/400 archive inventory,
the retrieve of that object can be invoked by BRMS/400.
Note
If an object has been saved with storage freed by any means other than
BRMS/400, there is no inventory of archived objects to consult. In this case,
BRMS/400 cannot locate and restore the object without manual intervention.
The user receives the standard OS/400 CPF4102 message File in library
with member not found.
If the object that has been saved with storage freed is not one of the supported
object types for the Dynamic Retrieval function, BRMS/400 is aware that the
object has been archived and can assist an operator in locating the correct
volume. However, the automatic initiation of a retrieve operation is not possible.
The user or job that was attempting to access the unsupported object receives a
standard OS/400 error condition (CPF4102) indicating that the object has been
saved with storage free. The user or operator must consult the BRMS/400 archive
inventory to locate the object and manually initiate its retrieval. This can also be
done from BRMS/400 using the Work with Saved Objects (WRKOBJBRM) display
or by using the Restore Object using BRM (RSTOBJBRM) command.
You can modify an existing application to support certain objects that are not
supported for Dynamic Retrieval by BRMS/400. The additional application code
needs to manage the types of OS/400 error messages returned for the objects
required and to interrogate the BRMS/400 inventory and initiate a BRMS/400
restore operation.
Chapter 12. Planning for the hierarchical storage management archiving solution 219
Suppose you have been running at a particular release for a while and suddenly
some of your production environment file members begin to be archived (with an
entire delete, no save with storage freed). Now when you come to access a
particular production environment file member that has been archived, you
cannot find the file member at all in the production library. The search through
your library list continues until you now find a file member of the same name in
the test library.
The file member you are now opening to access is not the one you need. It
contains test data, which may be vastly different from your production data. The
point of most concern is that you are not aware that this has happened.
Private authorities
When an object is deleted from the system and restored at a later date, the
private authorities that are assigned to it are lost until a restore authority
(RSTAUT) is run. Consider also that RSTAUT can only be run in a restricted
state, and even then, it can only be run after a restore of user profiles has been
executed.
Add this to the fact that you have to run RSTAUT for all user profiles on the
system because you do not know which users had private authorities to that
object. It quickly becomes clear that an ad hoc restore of an archived object that
was deleted entirely from the system is not as simple as the storage freed
implementation.
Restore performance
When restoring an object that has been saved with storage freed, OS/400 has
less work to do because it does not need to completely build a new object for the
restore of an object that has been deleted. As such, Dynamic Retrieval performs
better in this case. This is more beneficial for smaller files because the “create”
part of the restore is a larger percentage of the entire process.
For these reasons, and there are possibly others, it is considered impractical to
use a solution that deletes the object entirely. The save with storage freed
solution appears far more integral, secure, and simple.
Important
When the object is saved with the STG(FREE) option, the object headers
cannot be saved again using the standard OS/400-supplied save commands
as the system overlays new tape volume information. You receive the CPF3243
message Member xxxxx already saved with storage freed in your job log. This is
expected since you do not want to overwrite the volume information in the
object header, which provides the important link to where your data is.
One of the advantages of using BRMS/400 is that it uses the Media Storage
Extension (MSE) to save the object headers. You can, therefore, migrate your
data to another system. Without the MSE feature, you cannot transfer the
object header information to another system. You have to first restore all your
archived data, save the objects on SYSTEMA, restore on SYSTEMB, and then
re-archive the objects.
Note
These steps are used for archiving objects while retaining the object
description. For archiving where no object description is required to be
retained, steps 3 and 4 change to delete the object. We concentrate on the
save with storage freed implementation in this book because this is required for
Dynamic Retrieval. See 12.1.1.2, “What happens when archiving without
storage freed” on page 219, for reasons why BRMS/400 uses save with storage
freed.
You must ensure that if the process fails at any point between the transaction
boundaries, it can be recovered. The main limitation here is the difficulty of
recovering a save with storage freed operation without significant manual
intervention, for example, re-mounting the tape. Nor can you perform the updates
to the BRMS/400 inventory before the save operation because BRMS/400 relies
on the output file information from the OS/400 save operation to update its
inventory.
To illustrate the point, consider a single save solution, which may work as shown
in the following process (without a double save):
1. Save objects to tape with storage freed:
a. Save object 1 to tape.
b. Delete object 1 data portion.
c. Save object 2 to tape.
d. Delete object 2 data portion.
e. Save object 3 to tape.
f. Delete object 3 data portion.
g. ... and so on ...
h. Send the completion details to BRMS/400.
2. Update the BRMS/400 inventory:
a. Update object 1 archive details.
b. Update object 2 archive details.
c. Update object 3 archive details.
d. ... and so on ...
Chapter 12. Planning for the hierarchical storage management archiving solution 221
3. Commit the archive transaction.
In both cases, you can only recover the operation if you can identify which tapes
the storage freed objects were saved to, and then do a manual restore of these
objects.
When the double save is implemented, you do not delete the data portion of the
objects until you have completed the BRMS/400 inventory update. While this is a
much more satisfactory solution, there are some considerations that must be
taken into account when using archive with the save with storage freed option.
Tabulating the answers to these questions is the first step in establishing the
optimal system setup and BRMS/400 configuration.
The file members may be grouped according to common archive and retrieve
characteristics and entered into archive lists within BRMS/400. These archive
lists may, themselves, be grouped according to common parameters concerning
the method of archiving them and entered into control groups within BRMS/400.
The control groups' attributes are tailored, and the groups are scheduled to run
on a regular basis. Archiving can be run to produce only an Archive Candidate
report or to actually perform the archive itself. Whether you run the report first
depends on the items in your archive lists and control groups. More details about
BRMS/400 configuration is available in 13.3, “Using BRMS/400 for hierarchical
storage management” on page 267.
Chapter 12. Planning for the hierarchical storage management archiving solution 223
Typical characteristics of database files depend on the application that uses
them. A transaction-based application (for example, telephone order processing)
can amass records as time passes. These records tend to become dormant at a
certain point in time (for example, when the order has been fulfilled and payment
received) and, therefore, become historical data for auditing purposes. There
may even be a second level of dormancy once an auditing period is over (for
example, at the close of the financial year). At each stage, the status of the data
changes. A business decision based on knowledge of the volatility of the data at
the various stages and access requirements must be made as to when the data
becomes dormant.
This may be easier to perform at a record level. Further complications arise when
records at different stages in their application life share the same file member.
Archiving must be performed at the file member level. Further considerations
connected with record level versus member level archiving are available in 12.16,
“Application design considerations” on page 245.
Section 13.1.1, “Types of objects to archive for Dynamic Retrieval” on page 261,
lists and classifies the various file access characteristics in tabular form. It also
suggests suitable configurations for archive and retrieval.
For these reasons, we do not recommend that you attempt to implement such a
scenario.
There are times when the size of a logical file may grow to a significant level
compared to that of the physical. In this case, it is desirable to archive the logical
file if it becomes dormant.
Chapter 12. Planning for the hierarchical storage management archiving solution 225
Note
Saving a logical file with storage freed does not free any storage space. Doing
so performs a save of the object. None of the access path information is
deleted from the logical file since this is part of the object description; there is
no actual data component to be freed. When we refer to archiving logical files
in these sections, we mean archiving with total object deletion. The retrieval of
the logical file is not an automatic one, although BRMS/400 can be used to
assist with the location of the tape and restore operation.
There are some scenarios where it seems of little point to keep a logical file on
the system:
• The logical file has not been used for so long that it may be regarded as
disused (for example, test files that were never deleted or files that supported
previous releases).
In this case, the file is simply archived by deleting the object description. It is
assumed that Dynamic Retrieval is not needed for this file.
• The physical file on which the logical file is based has been archived.
In this case, it might be appropriate to archive all of the logical files connected
with this file. However, consider the following points:
– Some of the logical files may be so small that there is little to be gained
from archiving them.
– Because the physical file may be restored to the system with the Dynamic
Retrieval function (and the logical may not), the archive parameters need to
be set differently. That is, you have to be very sure that the logical file is not
needed for a longer time than for the physical file.
– For multiple format logical files (over multiple physical files), it is possible
that a logical file may not access all of the physical files to which it is
attached for any one request operation. If this is sustained over a length of
time, one of the physical files may be archived, but not the others. In this
case, you need to keep the logical view online. Note that this does not
apply to join logical files.
Also, it is possible that eventually all other copies of an object that have been
saved in the normal backup procedure will expire, leaving only one copy (on tape)
of the archived object. This is the most up-to-date copy.
For these reasons, we recommend that you duplicate immediately tape copies of
archived data and move the duplicate copy to an off-site storage location. The
following recommended procedure may be followed to address these issues.
Chapter 12. Planning for the hierarchical storage management archiving solution 227
It is also important to ensure that for every item on the list of candidates for the
archive that is being run, that the inactivity period for qualification is longer
than the period since the last guaranteed save of that object. That is, if you
know that object A has definitely been saved within a month of today, and it
cannot qualify for archiving unless it has been inactive for at least a month,
you can be sure that the object has not changed since the last save. This
ensures a back-out path in case the object was archived to a tape that
subsequently has a media error.
It is acceptable to perform the archive while the system is active since objects
that happen to be locked at the time of archival are, by definition, not eligible
for archive because they are in use. The exceptions to this rule revolve around
the definition of “in use”. A file may be allocated but not actually opened,
although this has no common practical application.
If the inactivity period set within BRMS/400 is zero days, there is a chance that
the object can be in use. In this case, these archive jobs should be run at a
time when the object is not likely to be in use.
3. Duplicate all of the archive tapes that were just produced.
This is normally performed with BRMS/400. You may use option 14 on the
Work with Media (WRKMEDBRM) display or use the Duplicate Media using
BRM (DUPMEDBRM) command.
This procedure also verifies the original archive tape copy since it must read
the files successfully to duplicate them.
4. If the duplication fails, you can restore the affected objects from the last
backup.
You can use BRMS/400 to list the objects on the affected tape with the
WRKMEDIBRM VOL(volid) command, where volid is the volume ID of the damaged
tape. Option 9 for each library shows the object detail. Write down the object
names.
You can locate the current backup copy tapes for each object using the
WRKOBJBRM OBJ(objname) command and select option 7 to restore the “lost”
object. This assumes that you have saved object-level details with your
backups. Without this, you need to use the WRKMEDIBRM LIB(libname) command,
and type option 7 next to each library with a second option 7 to enable you to
type in the object name.
When you have recovered the objects lost on the damaged tape, go back to
step 2, and run an archive for the objects that were lost from the original “bad”
archive tape.
5. Move the duplicate tapes off-site.
Important
If an archive tape fails during duplication, it may be quicker to restore a
complete library from a backup tape rather than several objects individually
from the same library. Be careful in this case to ensure that every object
within that library has not been changed since the backup. You may lose
important data if this is not the case.
Example
You have a parts inventory system and archived the parts list file from last year
because your catalog of parts has been refreshed for this year. The old catalog
is rarely used again. However, while you are running down your stocks from the
old catalog, you may want to keep it online. After a continuous 90 days of
inactivity, you can be sure that it is not used and it can be automatically
archived. A customer calls and asks for a discontinued part. Your system tells
you that it is discontinued. The customer is desperate for this part, and you
decide to check last year's catalog to see if any of these really old parts are still
lying around.
At this point, the old catalog file is retrieved. Having performed the search
using the old catalog, you are confident that you probably do not need this
catalog unless some really exceptional circumstances occur again. Why wait
another 90 days for it to archive? Why not allow this retrieved file to be
re-archived after five days of inactivity?
BRMS/400 supports archiving at multiple levels based on the last used date, the
last change date, or both (whichever is the later).
If you want to enable such a function, you have to create your own program that
interfaces with the BRMS/400 retrieve exit point to generate a list of retrieved
objects. You may have your own special archive control group that has a different
inactivity level specified from the regular control group. The list of retrieved
objects is used against a list of candidates objects for this special treatment to
generate the list of objects to be included in your special control group.
You may also attempt to create a method of differentiating between objects that
have been retrieved for read-only purposes and those retrieved for update. Once
again, BRMS/400 does not currently differentiate between these conditions. If you
are sure that the file member has not been updated, you may consider freeing the
storage of the file member after the necessary alternative dormancy period has
elapsed. This requires a save to a temporary save file with STG(*FREE) option
and deleting the save file. To be sure of this, you need to establish an instant lock
on the file member to allow read only transactions or set authority so that no one
can update it. This is clearly not a simple task. The last updated date cannot be
used because it is changed by the restore operation when you retrieved the file
member. Also, because it is only a date (and not a time), there is no way of
judging whether an update took place on the same day as the restore.
Chapter 12. Planning for the hierarchical storage management archiving solution 229
For details on setting up BRMS/400 to optimize your retrieve operations, see
13.7, “Using BRMS/400 for Dynamic Retrieval” on page 277.
Note
If the operation fails because the object type is not supported by BRMS/400
(for example, it is a *PGM type object that has been archived with storage
freed), or it is not in the BRMS/400 archive inventory (if perhaps the user
performed a save with storage freed outside of BRMS/400), the user is sent
the standard OS/400 message for this condition (message ID varies
depending on object type). It is not apparent that BRMS/400 has been
consulted at all. This situation requires standard application “object has had
its storage freed” error processing.
There are some circumstances where a *FILE object that has been archived
by BRMS/400 may fail. This can be in the situation of a restore failure
(media error or operator takes the cancel reply to the tape mount message),
or if BRMS/400 submits the retrieve to batch, or it is delayed to occur later.
In these cases, the CPF4102 message is relayed to the application. Your
application needs error handling to hide this from the user so that it can
recover gracefully from these conditions to allow a retry of the operation
later when the completion message is sent.
Chapter 12. Planning for the hierarchical storage management archiving solution 231
information on this user exit, see Complementing AS/400 Storage
Management using Hierarchical Storage Management APIs, SG24-4450.
• *NOTIFY: Using this value causes the restore request to be executed with
minimum operator involvement. For example, if a batch job attempts to open
an archived file member, the file member is automatically retrieved (restored)
with no delay or operator involvement, except as needed to inform the user (or
system operator if batch operation) that the retrieval is occurring, and to notify
as necessary for mounting media or indicating failure.
This option allows maximum seamlessness when implementing Dynamic
Retrieval. The user or operator is simply made aware of the fact that a restore
is taking place by a message on the last line of the display for interactive users
or on the BRMS/400 notification message queue for batch jobs. No decisions
need to be made by an application user. This option is best used when you are
sure that there will not be a significant number of retrieves performed that may
impact total system performance.
The *NOTIFY option is ideal when a tape library is available so operators do
not need to be involved in tape mount operations. Additionally, it is good for
less knowledgeable users who are not comfortable with making a decision
when they are presented with the *VERIFY message display.
• *DELAY: In the retrieval policy or the SETRTVBRM command, *DELAY can be
specified so that when an archived file is encountered, the file is “marked” to
be restored at a later time. In addition, when using any of the other retrieve
modes, if a restore exceeds the ASP threshold, it is disabled and the retrieve
is processed as an implicit *DELAY. In either case, the BRM1823 message is
sent to the user indicating that the restore has been delayed and that the file
cannot be used until it is restored. The application needs to handle the
CPF4102 condition generated when opening the file. The unretrieved file is
tracked by BRMS/400. The Resume Retrieve using BRM (RSMRTVBRM)
command and the Resume Retrieve display can be used to easily identify files
whose retrieve mode is *DELAY, and the user can request that the retrieval
operation for one or more of them should be performed or cancelled. Once the
files are restored, a message is sent to inform the user.
The delay mode can be used for users of applications who have lower priority
or who perhaps submit a lot of batch transaction processing (for example,
large queries that are not business critical).
• *SBMJOB: This is for interactive users only. This mode indicates that the
retrieval operation is to be submitted as a batch job. The BRM1823 message
is sent to the user indicating that the restore has been requested and that the
file cannot be used until it is restored. The application needs to handle the
CPF4102 condition generated when opening the file. Once the file restored, a
message is sent to inform the user.
This option is particularly useful for users of applications that deal with large
files and have multiple functions. If a user requests an operation and the file to
be retrieved is large, the batch submission of this retrieve job allows the user
to temporarily abandon the request and move on to process a similar request
with different data or a totally different function. This option may help improve
the general productivity of application users (and, therefore, the overall
performance) over *NOTIFY or *VERIFY modes.
• *NONE: This allows you to bypass retrieve processing.
Chapter 12. Planning for the hierarchical storage management archiving solution 233
message to the BRMS/400 notification message queue. *NOTIFY causes the
retrieve to happen immediately. *DELAY works as described, which means
that the file transfer request ends in error the first time it is run. *SBMJOB is
not valid for the batch option; therefore, it is not suitable for a file transfer
request.
• CPYF: Because the Copy File command is most often used to copy the
records in the file, this causes the member to be opened and initiates a
retrieval.
• Network file transfer: SNDNETF sends the object description as well as the
data records so this initiates a retrieval.
• SAVxxx ACCPTH(*YES): When saving using SAVOBJ or SAVLIB, or with any
BRMS/400-managed save where the access path parameter (ACCPTH) is set
to *YES, this invokes a retrieve operation. If you are using ACCPTH(*NO), the
Dynamic Retrieval function is not invoked.
• CRTxxxPGM: Program source code in a source file member requires access
to the source statements and is retrieved if a compile is performed on it.
The only consideration is when the journal entry for the storage free operation is
included in the block of sequence numbers to be processed in the apply or
remove. Typically, this occurs during a RMVJRNCHG operation where the
Starting sequence number parameter contains *LAST and the Ending sequence
number parameter contains a number that is related to the point in time to which
the file changes must be rolled back. The journal entries in this range include the
BRMS/400 archive (and storage free) operation. A RMVJRNCHG command
cannot roll back this type of operation and will fail. You need to perform a
DSPJRN (display journal) command to select a range of journal entries that do
not include the storage free operation.
For example, the following output is created from the DSPJRN command for a file
that is updated and then archived. The code for a storage free operation is MF.
Seq Code Type Object Library Job Time Comments
9 F OP PAYROLL1 PAYROLL PAYROLL 15:26:07 Open
10 R UB PAYROLL1 PAYROLL PAYROLL 15:26:12 Update 1
11 R UP PAYROLL1 PAYROLL PAYROLL 15:26:12
12 R UB PAYROLL1 PAYROLL PAYROLL 15:26:19 Update 2
13 R UP PAYROLL1 PAYROLL PAYROLL 15:26:19
14 R UB PAYROLL1 PAYROLL PAYROLL 15:26:24 Update 3
15 R UP PAYROLL1 PAYROLL PAYROLL 15:26:24
16 R UB PAYROLL1 PAYROLL PAYROLL 15:26:26 Update 4
17 R UP PAYROLL1 PAYROLL PAYROLL 15:26:26
18 R UB PAYROLL1 PAYROLL PAYROLL 15:26:29 Update 5
19 R UP PAYROLL1 PAYROLL PAYROLL 15:26:29
20 R UB PAYROLL1 PAYROLL PAYROLL 15:26:32 Update 6
21 R UP PAYROLL1 PAYROLL PAYROLL 15:26:32
22 F CL PAYROLL1 PAYROLL PAYROLL 15:26:36 Close
23 F CL PAYROLL1 PAYROLL PAYROLL 15:26:36
24 F MS PAYROLL1 PAYROLL 15:27:54 Save
25 F MS PAYROLL1 PAYROLL 15:28:32 Save with
26 F MF PAYROLL1 PAYROLL PAYROLL 15:28:34 storage free
Chapter 12. Planning for the hierarchical storage management archiving solution 235
OP = member opened
UB = update - before image
UP = update - after image
CL = member closed
MS = member saved
MF = storage for member freed
To roll back changes to a storage freed file member, you need to issue the
RMVJRNCHG command as follows:
RMVJRNCHG JRN(PAYROLL/PAYROLL) FILE((PAYROLL/PAYROLL1)) FROMENT(23) TOENT(17)
Note: The receiver entry range from 17 to 23 did not include the MF (free
storage) entry.
While the save access path parameter may still be overridden, we suggest that
you leave it at *YES to save the access paths and improve the retrieval
performance.
Be careful to split files appropriately. This solution may be a problem if you have
to retrieve of all the files that were split to satisfy a single data request. You have
to perform multiple restores, possibly from multiple volumes that may be stored in
different locations. All the pre-processing, post-processing, and tape mounting
tasks add to the overall time and complexity to retrieve an object. Additional
considerations for application customizing are discussed in 12.16, “Application
design considerations” on page 245.
Chapter 12. Planning for the hierarchical storage management archiving solution 237
cannot display any application knowledge to predict the incoming retrieve
operations. This discussion continues in 12.14.1, “Predicting which objects are
retrieved” on page 241. The result is that for a given complex (multiple file)
operation, you cannot predict either the total size of all of the members to be
restored or the time it takes to complete. Therefore, the performance is not
predictable.
• Access path rebuild times: Access through a multiple format or join logical
file may cause the retrieve of several physical file members. As each physical
file member retrieve operation is performed separately and independently of
any other operations, an access path rebuild for each physical file member
retrieved is experienced. Therefore, a situation can occur where a string of
access path rebuilds is performed when one final rebuild would suffice.
BRMS/400 cannot override the access path rebuild to *DELAY because it
cannot predict which physical file members, if any, are retrieved unless
BRMS/400 is retrieving in *DELAY mode. BRMS/400 uses the RSTRTVBRM
confirm display. See 12.8, “Retrieval methods” on page 231, for retrieve mode
details.
You should be aware of the potential performance implications of the multiple
access path rebuilds that are caused by archiving physical files under a
multiple format logical file.
This is certainly true for an application with a fixed logical flow of activities that
must be performed to complete a unit of work. If any of the sub-units of this piece
of work are temporarily stalled, the user has no option but to wait for completion
of that sub-unit.
For example, the unit of work may be the processing for a customer placing an
order. The first sub-unit may be to retrieve the customer's details, the second to
retrieve the stock details of the item required, and the third to create an order.
Of course, it is not that simple. The logic of the application may have to be
changed to allow backing out of sub-units to return to them later.
It is possible to create a special batch environment for retrieve jobs to speed their
performance. BRMS/400 uses the job queue named in your job description. You
can create a special job queue and reference it in your job description to change
it from the default associated with the user profile.
The retrieve mode used is typically set at the job level. It is possible to alter the
retrieve mode for the entire job by issuing the SETRTVBRM command before
each file open operation. This may have unexpected results on other activities
within your job, such as group jobs. It also requires changes to your application.
You may, however, decide that you are not impacting performance at all by
allowing sub-unit three to be submitted to batch. In this case, you may set the
mode for this entire job to *SBMJOB.
In summary, you can conclude that it is not always best for general user
productivity to use *NOTIFY. In some cases, *SBMJOB may be more appropriate.
Chapter 12. Planning for the hierarchical storage management archiving solution 239
12.14 Managing your disk space
An important issue with any automated procedure for adding and removing data
from your disk storage is the setting of precautionary checkpoints to avoid
storage overflow. The key to managing your storage lies in the balance between
the in-flow (retrieve) and out-flow (archive) of data.
Not every application can operate in delayed mode. There is definitely a need to
balance performance requirements against the storage capacity control
requirements.
If you use the *DELAY mode and the RSMRTVBRM command with the confirm
parameter set to *YES, you can choose which objects are to be retrieved. The
information on the Confirm Retrieve display may be used to total the sizes of the
objects for each ASP.
Chapter 12. Planning for the hierarchical storage management archiving solution 241
A number of factors influence the restore time, including:
• The object type (each object type has different restore characteristics)
• AS/400 system model performance
• Other jobs running on the AS/400 system that affect the performance
• Tape drive speed
• The speed of the IOP to which the tape drive is attached
• The use of compression (or not) during the save and the type of compression
• Waiting time for other jobs already using the available drives
• Time for mount requests to be honored
• Where on tape the actual object is located, that is, how much searching must
be done to find the start of the object
The retrieve function uses data stored in the BRMS/400 archive history to
determine the size of an object when it is retrieved. It is based on the size of the
object when it last resided on disk. The ASP threshold is derived from the
standard system ASP threshold that is set by the STRSST command. On a
well-managed system, it is unlikely that any retrieve operation will overflow an
ASP. An ASP overflow may occur if:
• The ASP threshold is set high (90% or above).
• Other independent create or restore operations (for example, CRTDUPOBJ or
RSTLIB) begin after the retrieve has started but before it has finished. This
may lead to an overflow as the retrieve continues its restore operation.
• The object size information is incorrect:
– The BRMS/400 data could have been corrupted.
– The object may be restored to a different operating system release that
may effectively change the required space needed for the object.
Chapter 12. Planning for the hierarchical storage management archiving solution 243
3. Update the entry for the file in the BRMS/400 archive lists.
If the file was included under a generic entry, you may or may not need to
change this entry. If you change a generic entry, for example FILE* to FIL*,
check that other files are not affected. You do not need any unwanted includes
or unanticipated excludes.
If the file member was included as an *ALL entry, you do not need to alter the
BRMS/400 list unless you have also changed the library name.
Use the WRKLBRM command if the object was in an archive list. If you are adding
a new list, use the WRKCTLGBRM *ARC command to add the new list to your
archive control group.
4. Leave the file members to be archived in the normal way.
If you want to re-archive these members instantly, you need to create a
temporary archive list and control group with inactivity set to zero days. You
can use the STRARCBRM command to archive the objects defined in the
temporary control group.
5. Optionally, delete the archive history for the old member name.
Use the WRKOBJBRM command with the appropriate parameters to select the file
in which the renamed member existed and remove the history data. It is
possible that you no longer need the data, so delete the BRMS/400 archive
history to save space. If not, it is deleted when the expiration date is reached.
This section concentrates on the methods of handling the data that you want to
archive. It discusses the methods in which our data structures may be changed to
accommodate Dynamic Retrieval or improve it. It also discusses the type of
customizing that an application may need to adapt to the altered file structures.
This section is about achieving the best from your file member-level archive and
the application considerations that go with it.
Chapter 12. Planning for the hierarchical storage management archiving solution 245
• Using multiple members within those files: Each file has a set of different
members. Each member consists of a group of related records. The
completion of the function (or sub-function) related to that file involves the
selection of the particular member required within that file based on a
particular item of information.
For example, the part detail file may have a different member for each catalog
of parts, each catalog may change each month, and there may be a different
catalog for each supplier of parts. The member selection is based on supplier
name and current month.
• Databases fully normalized: Full normalization of data entities implies that
there is no redundancy of data, and that the database is broken down into
many files. This allows you to go directly to the actual piece of data you need
without touching other data at the same time and, therefore, falsely instructing
the system that this other data is also active.
For example, as a result of a database design using full normalization
techniques, you have a part order file that does not contain direct values of
each part's description or price. These are referenced with a part identification
number and derived from a separate part details file and part price file. At the
time you print the order, you access all three files (orders, part descriptions,
and part prices). However, months later, you may perform a manufacturing
output analysis where all you need is the part's description (part detail file) and
the number of parts sold (order file). This way, you do not touch the price data
(part price file) and may leave it in its archived state if already archived, or at
least not disturb its dormancy rating.
• Effective design of logical files: Similar to the argument for normalizing
databases, having done all of the hard work in normalizing using multiple
members and multiple files, you must ensure that the design of logical files
does not lead to the unnecessary inclusion of unwanted or unneeded data.
For example, in the previous order file example, you may design a month-end
manufacturing analysis report (to report on numbers of parts manufactured)
that uses a logical file already created for a sales analysis report. Therefore,
you are saving on design cost, complexity, and access path maintenance by
re-using an existing logical file. However, the existing sales analysis logical file
also accesses the parts price file to obtain sales figures, but the manufacturing
analysis report does not need this information. You are, therefore, accessing
the parts price file unnecessarily and restricting its chances of being archived.
• Groups of records with commonality spread across multiple members: If
multiple members within each file contain records with no common theme, it is
difficult to control access to these members. Data requests may result in
sequential searches through each member instead of directly opening the
correct one. This is an indexing problem. There is little to be gained from
setting up multiple members if the access to these members is to be of an
entirely random nature.
For example, the customer details file can consist of many members, each
with 200 customer records. As new customer information is entered, a
member fills up. When a member is full, a new one is created. There is no
order to this arrangement and every time the customer detail file is queried, all
of the members must be searched. However, if the file was split into 26
members and grouped by the first letter in the customer name, a search on
customer name only accesses one member.
If these characteristics are found in your application, it is possible that you may
not need to make any changes to derive full benefit from the implementation of
archiving with Dynamic Retrieval.
Chapter 12. Planning for the hierarchical storage management archiving solution 247
• Change the application design to reflect the characteristics described in
12.16.1.1, “Applications suitable for member level archiving” on page 245.
• Design a work-around solution that minimizes changes to the application, but
uses special exit programs to intercept database requests, and to manage
files and their members.
• Design a work-around at record level that minimizes application change. See
12.17, “Pseudo record-level archiving” on page 254, for a discussion on this.
RECORD1
FIELDA FIELDC FIELDD FIELDE FIELDF FIELDG FIELDH FIELDJ
The key result of vertical data splitting is the creation of new files within your
application. The original file, with its single large record format, is converted
into several smaller files. Each small file has its own smaller record format.
Logical views may still be constructed to simulate the old record format using
multiple formats or joined record formats. The logical views help reduce the
impact on code changes. However, if all of the new records are always
accessed for every transaction, you may have not gained any enhanced ability
to archive some of the less active fields.
Once again, pay attention to the statistical variation of the use of these fields with
time. Only if it can be shown that certain fields are being used less as time goes
on, is it appropriate to remove these fields from the file.
An example is a change in the use of an application over time. Suppose that the
record format of the database in your payroll application included several fields of
information for the clerk that processed each pay check. These fields are there
because the clerks used to manually process part of the paperwork before the
entire process became computerized. They are still used infrequently when a
manual correction is needed. It is possible, therefore, that the usage statistics for
these fields are decreasing as time goes on and the accuracy and competency of
the payroll application increases. These fields may be vertically split off and
placed in a separate file, and that file is archived to tape.
All three may conflict. While it is possible that normalization and vertical splitting
for migration may have similar targets, it is also possible that the choice of which
fields to split off may differ significantly. Sometimes vertical splitting may be an
extension to the normalization process.
Chapter 12. Planning for the hierarchical storage management archiving solution 249
Performance of database access can sometimes be reduced by opening multiple
files, using join logical files, and other match and join techniques built into the
application code. This is in direct conflict with normalization and vertical splitting.
Application changes
The application changes needed when creating new record formats and files
include:
• Redesigning the data description specification (DDS) source for all included
data files.
• Redesigning the data description specification (DDS) source for all included
screen files.
• Designing new logical files over new physical file record formats.
• Redesigning application display handling code.
• Changing file names and record formats and record handling in application
database access code.
• Re-compiling all involved files, displays, and program modules.
Note
When using DB2/400 to access records in a file, it only allows you to open one
member at a time. Other members can be accessed with DB2/400, but only
after issuing the OVRDBF command to select the member required. This is
important to understand if you are considering using horizontal splitting.
MEMBER1
Primary key Secondary key Other fields
MEMBER2
Primary key Secondary key Other fields
MEMBER3
Primary key Secondary key Other fields
Figure 149 on page 252 shows horizontal data splitting by all keys. The single
member file is split into multiple members using changes in any key as the
boundary for each member. In this case, both the primary and secondary keys
become redundant.
Chapter 12. Planning for the hierarchical storage management archiving solution 251
MEMBER1
Primary key Secondary key Other fields
MEMBER2
Primary key Secondary key Other fields
MEMBER3
Primary key Secondary key Other fields
MEMBER4
Primary key Secondary key Other fields
MEMBER5
Primary key Secondary key Other fields
MEMBER6
Primary key Secondary key Other fields
MEMBER7
Primary key Secondary key Other fields
MEMBER8
Primary key Secondary key Other fields
CHARLIE ECHO LKSDFLKSDLNSLFGSLJGNSDLJNFALFNASLFNBSAJKL
CHARLIE ECHO KJSNVJSVNKSAJVDKSAJDNVKSJADVNKSJAVNKJSVSD
CHARLIE ECHO LKSDHFKSJAFKSDGKJBASDKJBASDVJVKJSKJSADVKS
Horizontal data splitting tends to create new members within the same file
because the record format for each group of records is identical.
For example, you may consider keying all entries in an accounts payable file by
the purchase date and breaking the entries at the change of each month. As the
records become older, they are less frequently used. This implies that entire
members may become eligible for archive as each member contains records from
within the same month.
However, if you decide to key your customer detail file by the customer name and
break this down by the change in the first letter, the result is 26 members all with
the same approximate activity levels. While you may find differences in the
activity of the “X” member to the “B” member, neither member changes
significantly with respect to the time that has elapsed. That is, you probably do
not find that the “X” member's relative activity has decreased after six months
have elapsed any more than the relative activity of the “B” member. In short, the
statistical activity of each and every member in this file does not vary with time.
Application changes
The key changes you need to make in your application to deal with horizontal
data splitting include:
Chapter 12. Planning for the hierarchical storage management archiving solution 253
• Setting up a member search list, listing the names of members to search for a
hit, and the order in which you search them. Include the most active ones first
and the most dormant last. You may have different lists for different
sub-functions on the same file.
• Coding the changes needed to deal with the member search list to maintain
and update it.
• Coding the changes needed to use the list to have a successful search while
minimizing the need to retrieve archived data.
The main benefit from this approach is the successful archiving and Dynamic
Retrieval of records for applications that do not normally lend themselves to this
type of solution while also minimizing the impact of changes to that application.
Some questions that you need to answer during this process include:
• How are the records to be copied to another file for migration and what
indexing data should we maintain for searches?
• When are they to be copied? What triggers the process?
• Which records should be selected for migration?
• How are the archived records to be retrieved?
• What triggers the process for retrieve?
• What search criteria can we use for accessing records and when do we decide
to search the archived data (instead of just the online data)?
• How can we group the records (index them) into groups with common
statistical activity?
• What direct code changes must we make?
• How much database “get” intercept code do we need?
Note
You should be principally concerned with horizontal data splitting, but, in this
case, you are performing the splitting actively (and in an ongoing manner) by
constantly moving records to and from tape. The previous section concentrated
on splitting the data in the design stages by redesigning the file structures,
members, and the application itself.
You need to consider the following points when you design your record migration
function:
• What programs perform the migration?
The user application may be modified to include a set of statements to select,
copy, and delete certain records within the main files. These statements are
best coded to be as flexible, generic, and re-usable as possible.
This migration is performed by a background job. This job acts as a database
manager that starts at predefined intervals, performs a transfer, and goes
back to sleep. Alternatively, this job can constantly monitor the file activity and
prepare certain records for transfer.
• How are the migration programs triggered?
Whichever way the migration is performed, you need to establish clear
triggering criteria for migration activity. The triggering should depend on the
type of file activity and granularity required. It can be based on:
– When a file member reaches a certain size
– Repeated at fixed times (for example, 2:00 a.m. every day)
– At user request
– When a certain volume of migratable records accumulates
The last option is a more intelligent triggering mechanism, but relies on the
ability to time-stamp each record individually, which is not part of the OS/400
database function.
• Which records does the migration programs select?
This is really a process of active horizontal splitting. The data splitting is
performed real-time. You need to index the records and select certain records
based on their key values. Once the first migration is performed, the indexes
and selection criteria are fixed. The only way of changing them is to retrieve all
archived records first. If each record is time stamped, you may be able to
index on the time stamp and select the oldest records for migration. See
12.16.2.5, “Using horizontal splitting” on page 253, for more considerations
about horizontal splitting.
• How do we arrange the migration files?
Do you need to create a new member every time you archive more records? If
you create a new member each time, you must establish a naming convention
for each member and a chain of members. This is much the same as the chain
of receivers that you set up for journaling. Each member name contains a
generic part and a sequence number part, such as ARCMEM0001,
ARCMEM0002, and so on. You also need an index of these members to keep
the chain intact and to provide an order in which to sequence them. This is
similar to the journal object itself that tracks the receiver chain that it feeds.
The archived member chain list can also be used as a type of member list with
which a search is initiated for a record. This is the same principle with which
OS/400 may search for an object using a library list.
If you insist on using the same member for each archive operation, you must
either delete all of the previously archived records each time a new group is
archived, or retrieve the previously archived records and append the new
Chapter 12. Planning for the hierarchical storage management archiving solution 255
ones to this member and re-archive the member. If you choose to delete the
previously archived records, you really mean delete them (that is, expire the
tape on which they reside so that they really are gone forever, no copies on
disk, tape, or anywhere).
If you decide to append to the archive member, you should be aware that this
forces a retrieve of all of the records ever archived every time you want to
append. This almost defeats the purpose of archive and retrieve except for
situations where this archive process is only performed infrequently and there
is enough temporary disk space to accommodate the retrieved member. You
may also need to temporarily clear out the really old records from this
member, since you can never expire the tape (on which it resides as a whole)
because this loses all of the archived records, including freshly archived ones.
• In what form do the copied records remain in the main file?
Once you have selected the records in the master file and copied them to the
archive file, what do you do with them? You have three options:
– Delete them entirely:
In this case, you have no direct reference to indicate whether a record is
archived or simply does not exist. Therefore, if a non-existent record was
requested, the search may have to go through all of the archived records to
find out that this record does not exist. This results in retrieving all records
for every unsatisfied query to the main file.
The effect of this is reduced by establishing a list (or chain) of archive
members through which the search can interrogate. If the records are
keyed by a time stamp, it is possible to place a time scope within which the
search must remain. A less sophisticated version of this involves naming
the last allowable member in the chain that is searchable.
You may want to combine the idea of searching through a chain of archived
members with the *VERIFY retrieve mode allowing the user to stop the
search at any point (by member) by cancelling the retrieve operation.
– Keep record stubs in the main file:
You can delete all field information relating to a record except for its keys
fields. This leaves a stub that uniquely identifies that record and can be
used to check the record's existence without querying any archived files.
This works similarly to a save with storage freed, and you call it “save
record with storage free”.
You may need to add a special flag field to each record to indicate whether
it has been archived or establish a special condition to indicate migration
status.
You only save disk space if the record consists of multiple formats and
parts of the joined format can be totally deleted from their own physical
files. If the record sits in one large record format, all you can achieve is to
blank out a number of fields that do not conserve storage space. Another
opportunity is to use variable-length records. This way, only the key data
takes up space, and the less active data can be removed. Therefore, the
file makes more efficient use of storage.
– Create an index file:
You can create a separate physical file containing a record format that
includes only the key information from the main application file, a migration
Action to be taken Records are deleted from Records are saved with Homemade access path
the main file files freed
Trigger: How is the Any record get request, such Any record get request, such Any record get request, such
search started? as read or chain, is as a read or chain, is as a read or chain, is
intercepted by a special intercepted by a special intercepted by a special
record management program. record management program. record management program.
Locate: How is the A simple search through the Search key fields in the main Search through the special
record found? members in the list. file. index.
Search path: Which Start at the online member, Only the main file (online). Only the special index.
members are and progress offline until it is
searched? found. Follow the list.
Retrieve: How is the All searched members are If a record does not exist, all Only the member containing
record brought retrieved until the required searched members are the record required is
back? record is online. retrieved until the required retrieved.
record is online.
Read: How is the Read directly from the Read directly from the Read directly from the
record read? retrieved member. retrieved member. retrieved member.
Update: How is the Added to the main file and Copied to main file (add extra Is added to the main file,
record updated? updated. data in other record formats) updated, and index modified.
and updated.
Migration: What Archived if it is updated, and Archived if it is updated, and Archived if it is updated, and
happens to the deleted if it is read only. deleted if it is read only. deleted if it is read only
retrieved member in
the main file?
Chapter 12. Planning for the hierarchical storage management archiving solution 257
Action to be taken Records are deleted from Records are saved with Homemade access path
the main file files freed
Note:
The headings refer to method of dealing with records in the main file that have been copied to an archived member.
And that's it! But remember, all of the work is in customizing the solution,
involving designing the record handling program, creating archive members and
indexes, and all of the other things previously mentioned.
If you do not know the status of your records (that is, those that are archived), it
may not be appropriate to use the *ONLINE or *ARCHIVED options. You may
need access to all records that are changed or created since a certain date. This
requires individual time stamping of every record in the database and indexing
based on that time stamp.
The retrieval of archived records requires merging some records back into the
main file. You may choose whether you merge complete members or select
specific records to merge. Either way, you must avoid duplicating records and use
the following routine for all of the records accessed:
1. Select a record.
2. Copy the record to a main file.
3. Delete the record from the archive file.
Chapter 12. Planning for the hierarchical storage management archiving solution 259
12.17.5.1 Using direct tape I/O
Direct tape input/output (I/O) is where a user program writes records directly to
tape or reads them directly from tape. No save or restore CL commands are
used. This is different from Dynamic Retrieval, which uses a basic save/restore
interface. Direct tape I/O may be an alternative solution for read-intensive
operations on archived data. You can use a tape file to write records directly to
tape. The record key must be set before you write the block of data, and it is not
possible to insert or add records to the initial block.
However, with the use of the BRMS/400 fast search facility for tape drives, such
as the 3490, 3590, and 3570, you may be able to locate the beginning of the tape
file quickly and perform intensive read only sequential operations such as running
a query. The BRMS/400 inventory stores the starting block ID on tape of a tape
file and fast forwards the tape directly to that position instead of searching
sequentially through the entire tape.
Note: This does not mean Query/400. Tape file I/O means a program reading
from or writing sequentially to tape. The records must be read and a *FILE object
created from them before Query/400 is used over them.
The fast search implementation is part of the BRMS/400 product. If you want to
take advantage of this facility, you must perform all of your tape input and output
under BRMS/400 control. To do this, you need to use the Set Media using BRM
(SETMEDBRM) command. For further information, refer to Backup Recovery and
Media Services for OS/400 (part of the IBM Online Library SK2T-2171).
Before you begin the process of archiving, you may need to break the data files
down into members (horizontal data splitting) according to typical usage
characteristics. This involves a certain amount of statistical analysis of each
record and its subsequent placing in a file member dependent on its anticipated
usage. You have to place frequently accessed data into the frequently accessed
members. You place the infrequently accessed data into the infrequently
accessed members and archive the infrequently accessed members. If the
application manages this, it is suitable for archive with Dynamic Retrieval.
Moreover, the parts inventory may have random access characteristics with
respect to record age, but the parts order file may have lots of transaction-based
activity.
Source physical file members offer great potential for archiving with Dynamic
Retrieval because they are typically not used for long periods of time and are split
into separate file members with each member having its own independent usage
statistics and age.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 263
If the historical data is grouped in clearly-defined sets, and if these sets are
correspondingly arranged in different file members, the Dynamic Retrieval
function may be used to good effect. In this case, the application is responsible
for “off-loading” the historical data into historical file members and the
subsequent management of these file members. An example of such an
application could be year-to-year accounts.
Use care when setting the dormancy levels for the archive group to avoid
repetitive archive and retrieval cycles. The impact of retrieval delays should be
studied in detail. If the application function is of a highly performance critical
nature, the gains derived from archiving are outweighed by the performance hit of
a single retrieval operation. The choice of retrieve mode is also critical. See 12.7,
“Retrieval considerations” on page 229, for more information.
Tabulating the answers to the preceding questions is the first step in establishing
the optimal system setup and BRMS/400 configuration. Remember that
BRMS/400 supports a hierarchical policy structure, which therefore, allows you to
For example, you may decide that the most commonly-used dormancy criteria is
that of one year. Set this in the Archive Policy. Then, for every control group that
requires a different value, override the value in the control group's attributes.
Note
A more prudent approach may be to use the most safe value for the Archive
Policy. In this example, you may have a dormancy period of five years set in
the Archive Policy. That way, when you create your Archive Control Groups, if
you forget to override the dormancy value, the impact is limited. In this case,
you do not suddenly archive every object in the archive control group because
the Archive Policy dormancy is set to one day.
The preceding structure should be used at all times when planning your
implementation of hierarchical storage management. You should examine each
data set in detail and derive the most appropriate settings for your BRMS/400
setup. Take into account:
• Overall business objectives
• Individual “user class” requirements
• Agreed service levels
• Application design constraints
• System constraints
• BRMS/400 function
Table 6 on page 266 lists the data set types previously mentioned and
suggestions for the necessary design points.
Note
This table is, by no means, exhaustive or conclusive. It is meant as a
reasonable test and nothing more. You should always plan your particular
implementation thoroughly, examining each data set individually. A keen
understanding of your own business and the applications that you use is vital
and should be exploited fully.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 265
Table 6. BRMS/400 Dynamic Retrieval guidelines
Outfile Data Query the L 3 months 1 year *DELAY Some applications may use
results of CL outfile support. Do not include
commands. these files in your archive
lists. The application should
manage them independently.
If archived, they should be
part of application archive.
Data File with Typically order M 1 to 3 years 5 years and *VERIFY *SMBJOB may actually
Transaction entry, up: Depends (small) or improve performance in
Based accounting on business *SBMJOB some cases.
Members sales analysis, or legal (large)
and so on. requirements
Data File with Typically order H Immediate 5 years and *VERIFY The archive should be
Transaction entry, up: Depends performed immediately after
Based records accounting on business the movement of records to
sales analysis, or legal the special archive member.
and so on. requirements Using the *SBMJOB retrieve
mode may actually improve
performance in some cases.
Data File with Typically stock H 1 to 3 years 5 years and *VERIFY *SBMJOB may actually
Random control, up: Depends (large) or improve performance in
Access medical on business *NOTIFY some cases.
Members analysis, or legal (small)
customer files, requirements
and so on.
Data File with Typically stock H Immediate 5 years and *VERIFY The archive should be
Random control, up: Depends performed immediately after
Access medical on business the movement of records to
Records analysis, or legal the special archive member.
customer files, requirements Using the *SBMJOB retrieve
and so on. mode may actually improve
performance in some cases.
Data File with Example: H 1 to 3 years 5 years and *NOTIFY You may even analyze each
Mixed Customer up: Depends (performance individual data set within the
Characteristics order on business critical) application and allocate
application: or legal separate archiving and
generating requirements retrieval conditions for each
order is one.
transaction,
fetch customer
data is random
access.
Source file Source editing M 1 year 5 to 10 years *SBMJOB The value of the intellectual
members applications property within the source
and compilers. files must not be lost by
discarding the archive copy
early.
Digital Reference H 2 weeks 10 years and *NOTIFY Typically small chunks of the
Libraries information up massive library are retrieved,
applications and therefore, *NOTIFY is
probably appropriate.
Historical Data Transaction- H Immediate 5 years and *VERIFY Archive should take place as
based (coincide with up: Depends soon as the historical data is
applications period end) on business placed into the archive
or legal members.
requirements
Active Data Any business H 18 months 10 years and *NOTIFY 18 months dormancy is a
Sets application up reasonable period to
determine if data needs to be
archived since it was last
used.
See Backup Recovery and Media Services for OS/400 (part of the IBM Online
Library SK2T-2171) if you need additional information on the commands and the
parameters.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 267
3. Group the data sets by common characteristics.
4. Identify the jobs associated with the various data sets.
5. Build BRMS/400 archive lists (one for each group or sub-group of data sets).
6. Incorporate the archive lists into control groups.
7. Create any required special media classes for archive.
8. Create any required special media movement policies for archive.
9. Create media policies for each group of data sets.
10.Establish an archive policy.
11.Build an archive control group for each group of data sets.
12.Adjust each archive control group's attributes where they vary from the
archive policy.
13.Establish a retrieve policy.
14.Build alternative retrieve policy settings for any jobs that require different
retrieve modes. These can be implemented using the SETRTVBRM command
in the user's initial program.
15.Add the archive jobs to the scheduler (if required).
Ideas and suggestions for the first four steps are included in the previous sections
of this publication. This chapter deals with the practicalities of setting up
BRMS/400. This includes the remaining steps. We also deal with:
• Checking the BRMS/400 logs for results from the archive run.
• Controlling retrieve operations from the RSMRTVBRM display.
The ASP and library levels give you the opportunity to specify a large number of
candidate file members without much typing. You can specify an ASP number as
a special value in the archive control group (for example, *ASP03 or a library
name such as PAY*). When specifying these values, BRMS/400 checks all of the
file members in ASP 3 or in all of the libraries beginning with the characters
“PAY”. However, it is rare that you want to actually archive at these levels. They
are useful in producing Archive Candidate reports to assist in estimating potential
space savings.
Each list of objects may be entered into a BRMS/400 archive list. These lists are
placed into a BRMS/400 archive control group. It is the control group that
specifies the archiving parameters such as dormancy levels and media policies.
Therefore, it is feasible to split groups of objects that currently have similar
archive or retrieve characteristics into several individual archive lists to allow
additional flexibility for future changes.
To work with BRMS/400 lists, enter the WRKLBRM command. You must create your
archive list with *ARC for the Use value and *OBJ for the Type value. You can also
select *FLR to archive folders or *SPL to archive spooled files.
Important
Be aware that neither folders or spooled files currently have Dynamic Retrieval
support.
The Add Object List display is shown where you may proceed to enter the objects
required for the archive. Simply type in a sequence number, library name, object
name and type, and whether this is an include or exclude selection as shown in
Figure 150. The archive processing takes place in the order shown on the display.
Use . . . . . . . . . : *ARC
List name . . . . . . . ARCLIST
Text . . . . . . . . . Main List for Archive with Retrieval
When you complete your archive list, press the Enter key once more to save the
list. If you press F3 or F12, you lose all of the changes you just entered!
Continue to create as many lists as you need. You use these lists later in the
various archive control groups that you create.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 269
Note
If you want to include a complete library of objects as candidates, it is easier to
enter that library name as an entry in an archive control group rather than
including it in an archive list. Either way, for retrieval purposes, remember that
if you include generic values, or even whole libraries or ASPs, you can easily
archive object types such as programs, logical files, journal receivers, and so
on that are not supported for Dynamic Retrieval. These objects may archive
without problems. However, you do not realize what you have done until it
becomes time to retrieve an unsupported object, at which time the system
simply reportes that it is saved with storage freed and the user program ends in
error. As mentioned earlier, the ASP and library-level values are good for
creating Archive Candidate reports.
Use the WRKCLSBRM *MED command to create a new media class, and change the
necessary parameters in the Add Media Class display shown in Figure 151.
The first move policy should be used for the “active” tapes that contain the
“active” data that has been archived and can be required for retrieval at any
moment. This set is the copy of the original archive set. Because the duplicate set
was created after the original set of tapes, BRMS/400 regards these tapes as the
The second move policy should be for the original tapes that we recommend you
make a duplicate of after every archive operation. You should send these tapes
immediately to a different site from the site in which the “active” archive copies
are stored.
You may repeat this pairing of move policies for each different physical location in
which archive tapes are likely to be stored.
To create a move policy, use the WRKPCYBRM *MOV command, and create a move
policy such as ARCMOV. Define the sequence and duration of all of the locations to
be visited on the Create Move Policy display shown in Figure 152.
You may set retention by the number of elapsed days, the number of versions to
keep, permanent (keep data for ever), or for a fixed date. We make the following
recommendations for these options:
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 271
• Permanent: This is generally unsuitable because if a data item is retrieved, it
may be changed and re-archived at a later date. Therefore, the original
version is now redundant but continues to occupy its tape forever.
However, since version control at the member level is not currently supported,
the permanent option may be the only way to keep your archived data
indefinitely. If you implement this, be aware that every time you archive a data
item with permanent retention, you say good-bye to that tape forever. It is
unlikely that you are in a position to manually expire the tape because you
have no idea whether the items archived to it have since been retrieved.
• Date: It is unlikely that you need to discard all of the archived data on a certain
date, especially if you have no idea when it may be retrieved.
Use this option with caution. If you specify an expiration date, you may need to
modify existing policies or create new policies and control groups as time
passes. An example may be a tax analysis application where the data must be
kept for seven years or more, regardless of the number of times that this data
was retrieved. Therefore, you may have a control group for 1994 (called
“TAX94”) that listed the 1994 tax files and a 1994 media policy (called
“TAX94”) that expires all of the data on January 1, 2002 (seven years after the
end of 1994). Every time a 1994 tax file was retrieved and subsequently
re-archived, the expiration is always in January 2002. The consequence of
this system is that you must create new archive control groups (and possibly
new archive lists) and new media policies each year (but you should only need
seven of each).
• Versions: Version control is currently unsuitable for archiving because the
versioning algorithm works at a tape file level as opposed to a file member
level. Consequently, you may have several file members archived in a single
save with storage freed operation, producing a single tape file with a label
based on the name of the data file. When a group of different file members
within the same data file are subsequently archived, you create what appears
to be a second version of the same file members, but it is not. Currently,
BRMS/400 prevents us from using versioning with archive control groups.
If version control for archive at a member level ever become available, it will
offer an elegant way of permanently keeping your archive data on tape but
expiring older versions of members that have since been retrieved and
re-archived to another tape.
• Days: The number of days elapsed is by far the simplest method for retaining
our archived data tapes.
The retention period is important. If you set it too short, you may completely lose
important data far too soon. Expiration of a tape with archived data is effectively
deleting that data. If you set the period too long, you experience a degree of data
fragmentation on your tapes. Every time an object is retrieved, it is restored from
tape and used on the system. At a later date, it is archived again and the original
copy becomes redundant or “expired”. For a tape that contains several archived
objects, as time passes, more and more of the archived objects “expire”. This is
all wasted space on the tape and can only be reclaimed when the entire tape is
expired by BRMS/400. In extreme cases, all of the archived data might have
become redundant (and, therefore, the entire tape is redundant), and the tape is
still not expired (and, therefore, re-usable) by BRMS/400.
If you are using an automated tape library, you may also specify the name of the
required library location in the Storage location parameter when you create a
media policy. This helps BRMS/400 select the correct tape drives to use when
performing archive or retrieve operations.
Use the WRKPCYBRM *MED command to create a media policy. On the Add Media
Policy display, set the parameters according to the results of your implementation
planning work completed in 13.1, “What to archive” on page 261.
After you create the necessary media policies and archive lists, you can create
the required archive policy and base your control groups on all three.
You can access the archive policy directly by using the WRKPCYBRM *ARC command,
and you can change the parameters to meet your requirements.
Note
The following recommendations are intended for all archive control groups that
archive objects for use with Dynamic Retrieval. If you do not perform any other
kind of archiving, it may be appropriate to follow these recommendations for
the archive policy and allow all of your archive control groups to default to the
archive policy. If non-retrieve archive control groups also exist, you use take
care with this approach. It may be best to specifically set all of these
parameters within each archive control group and leave the archive policy as
general as possible.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 273
the last used date or the last changed date as the checkpoint for the dormancy
duration. BRMS/400 may still use both as described in the previous paragraph.
This facility allows you to, at the control group override level, have two control
groups with the same file objects listed, but different dormancy criteria for the last
update and last used. Using this approach, you may want to set a longer period to
wait for archive if the file has recently been updated, and a shorter wait until
archive if the file has only been read. You can also use this approach to
differentiate between active data files (recently changed) and files that have
simply been retrieved for a small number of reads (recently used), although this is
not a watertight assumption to make.
Our main recommendation for your archive activity plan is that you start archive
immediately after your backups have completed. This minimizes the impact of
archive media errors because a backup copy of the data exists. You can also use
the DUPMEDBRM command to create duplicates of your archived media for
safety reasons.
Use the WRKCTLGBRM *ARC command to create an archive control group. Specify the
names of the archive lists that you created earlier, or enter the names of the
libraries that you regard as suitable candidates for archiving. An example is
shown in Figure 153.
Group . . . . . . . . . . : MAINARC
Default activity . . . . . *ARCPCY
Text . . . . . . . . . . . Archive Control Group
Weekly Save
Archive List Activity While
Seq Items Type SMTWTFS Active
60 *ASP03 ____
10 ARCLIST *OBJ *DFTACT *NO
20 SALESLIST *OBJ *DFTACT *NO
30 MYLIB ____ * * *NO
40 STOCKLIST *OBJ * * * * *NO
50 ARC2LIST *OBJ *DFTACT *NO
Note that F19 key allows you to display a list of libraries to choose from. In each
case, you are simply listing available candidates for archive. The selection of
objects that actually are archived is performed at run time using the list of archive
candidates and the Include Criteria specified in the control group attributes or the
archive policy.
You may also want to specify a different archive weekly activity for each library or
list at this point. If you leave this field, it defaults to *DFTACT, and the activity is
taken from the default activity, which is a control group attribute, and can also be
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 275
entered at the top of the display. Remember that each of the control group's
attributes may also default to the archive policy, and some of these may also
default to the system policy.
After creating the archive control group, you can change any of the attributes
such as tape device to use or the dormancy criteria. Refer to Backup Recovery
and Media Services for OS/400 (part of the IBM Online Library SK2T-2171) if you
need more information on individual parameters. There is also a discussion on
some of the more relevant parameters in 13.5.3, “Archive policy” on page 273.
You may also change the list of subsystems to end if there are some jobs that
interfere with the archive processing. At the end of the archive run, the
subsystems are automatically re-started. Similarly, you can also specify a list of
job queues to be held during the processing of the archive control group.
As a final check, you may use the Start Archive using BRM ( STRARCBRM) command
with the *REPORT option to print a report a report of the available candidates for
archiving within the control group. The report may not be printed if none of the
files in your lists are dormant yet. In this case, you receive a message saying that
the report did not contain any data.
BMJOB(*NO)
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
Frequency . . . . . . . . . . . > *WEEKLY *ONCE, *WEEKLY, *MONTHLY
Schedule date, or . . . . . . . > *NONE Date, *CURRENT, *MONTHSTR...
Schedule day . . . . . . . . . . > *ALL *NONE, *ALL, *MON, *TUE...
+ for more values
Schedule time . . . . . . . . . > '00:01' Time, *CURRENT
You can set the archive job to run daily, several times a week, weekly, or monthly.
To specify daily, set the Frequency parameter to *WEEKLY and the Schedule Day
parameter to *ALL. The other combinations are self explanatory.
We advise you to set the time for the run to start immediately after the backup
runs have completed. You can achieve this by choosing a time when you are
confident that the backup run has shut the system down to a restricted state;
You may want to use an alternative job scheduler (for example, one that has a
dependency function built into the scheduling algorithm, perhaps using parent
and child relationships). You can instruct BRMS/400 to use the scheduler of your
choice with the CHGSCDBRM command. See Backup Recovery and Media
Services for OS/400 (part of the IBM Online Library SK2T-2171) for more details.
Obviously, not all applications want to retrieve their data in the same manner (or
mode, as we call it). For additional flexibility, you may use the SETRTVBRM
command to override the system wide retrieve policy settings at the job level.
When you issue the SETRTVBRM command, the new settings apply for all
retrieve operations initiated after that point and until the job ends or another
SETRTVBRM command is issued. The SETRTVBRM command is explained
further in 13.7.1.2, “Setting the retrieve controls for a particular job” on page 279.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 277
Change Retrieve Policy SYSTEM04
When media containing the file is located in a media library device, BRMS/400
limits its choice of *MEDCLS devices to those that are at the media library
device location.
• Retrieve confirmation: You may specify the retrieve confirmation (or retrieve
mode) for batch and interactive jobs separately and independently.
A full description of each of these parameters is found in 12.8, “Retrieval
methods” on page 231. Further discussion on the best uses of each mode is
found in 12.7, “Retrieval considerations” on page 229.
• Retrieve authorization: The authority option tells BRMS/400 what level of
authorization to a file is necessary before the accessing user can retrieve the
file. This authorization level is checked and, if met, the retrieve operation is
performed. If it is not met, the BRM1823 message is sent indicating that the
file was not restored and that it cannot be used until restored. The unretrieved
file is tracked by BRMS/400 to indicate that an *AUTHORITY failure occurred.
Through the RSMRTVBRM command and the Resume Retrieve display, the
user can easily identify files that were unable to be retrieved due to authority
failures and can request that the retrieve operation for one or more of them is
performed or cancelled.
For many enterprises, users only have use or update authority to files. If the
authority level is set at *UPD at open time, BRMS/400 automatically retrieves
the archived file member for those users that have at least update authority to
the file. In doing so, BRMS/400 allows the file to be retrieved without having to
grant users who access the file *OBJEXIST authority to enable Dynamic
Retrieval.
Allowable values are a subset of those allowed on the OS/400 CHKOBJ
command for the AUT parameter such as *OBJEXIST, *OBJMGT, *OBJOPR,
*ADD, *DLT, *READ, *UPD, and *ALL. The default value is *OBJEXIST.
It should be noted that all retrieve operations are constrained by the Storage
Threshold (a high water mark for Auxiliary Storage Pool (ASP) utilization) as
expressed through the System Service Tools (STRSST) ASP threshold. See
Backup and Recovery - Advanced, SC41-4305, for more details.
BRMS/400 does not restore a file if doing so causes the ASP's storage threshold
to be exceeded. If the storage threshold were to be exceeded, messages are sent
indicating that the file was not restored and that it cannot be used until restored.
The unretrieved file is tracked by BRMS/400 to indicate that a *STORAGE failure
occurred. Through the Resume Retrieve using BRM (RSMRTVBRM) command
and the Resume Retrieve display, the user can easily identify files that were
unable to be retrieved due to DASD space constraints and can request that the
retrieve operation for one or more of them be performed or cancelled.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 279
The controls you specify with the SETRTVBRM command remain in effect for
your job until they are reset, for example, when the job ends, or otherwise is
changed with another SETRTVBRM command. To see control values that are
currently in effect, use the SETRTVBRM command. A display appears similar to the
example in Figure 156.
The parameters shown are exactly the same as those found in the retrieve policy.
You may review the descriptions listed in 12.8, “Retrieval methods” on page 231,
for more information.
The SETRTVBRM command can be inserted into the initial program for certain
users or into the controlling CL program for your batch jobs. You may even build it
into your application if you need to change retrieve modes depending on the
functions being performed. You must be careful about allowing users to change
their retrieval controls themselves. See 13.9.3, “Securing the retrieve policy” on
page 287, for further discussion on this matter.
13.7.2.1 *VERIFY
By default, a program message is displayed to the user as shown in Figure 157
through Figure 159. The first display is shown, and the Additional Message
Information display is only shown if the user presses the Help key. The more
knowledgeable user becomes familiar with the options and most often makes a
decision from only the Display Program Messages display. Important additional
information is included in the second display including object size and ASP
utilization, which may influence the user's decision to initiate the retrieve
immediately.
F3=Exit F12=Cancel
S -- Submit the retrieve operation for batch processing. The current job
will receive an indication that the object's data was not found.
Technical description . . . . . . . . : Access to a suspended object has
caused BRMS to attempt to retrieve the object from archives. If the object
is a physical file then only the requested member for that file will be
restored.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 281
You many want to customize the messages shown during retrieve processing or
automate the action to be taken under certain circumstances. For additional
information and an example of an alternative interface that can be coded by the
system administrator to take the Dynamic Retrieval function one step further, see
Complementing AS/400 Storage Management Using Hierarchical Storage
Management, SG24-4450.
13.7.2.2 *NOTIFY
A status message is shown on the last line of the display that is shown in Figure
160. The job waits until restore is complete. As for the immediate (Go) option with
*VERIFY mode, the user should not use the End job (System Request, option 2)
function during this time.
For *NOTIFY and the immediate (Go) option of *VERIFY, such errors as media
errors and tape mount messages are reported to the system operator or the
BRMS/400 notification message queue. If an error is severe and the operation is
cancelled, all messages are added to the user's job log including those
responded to by the system operator. The original OS/400 CPF4102 message is
sent to the application.
Bottom
Parameters or command
===> dsppfm PAYROLL/PAYMASTFIL
13.7.2.3 *SBMJOB
The BRM1824 message is added to the user's job log to inform the user that the
retrieve job is submitted. The open request (the application) is sent the CPF4102
message to handle as an error and enable the user to retry the function at a later
time.
13.7.2.4 *DELAY
The BRM1823 message is added to the user's job log to inform the user that the
retrieve job is submitted. The open request (the application) is sent the CPF4102
message to handle as an error and enable the user to retry the function at a later
time.
When the retrieval is resumed later, the user is informed with the status of the
restore. As for the *SBMJOB option, if the restore fails, the application has
already reacted, so the user knows simply not to try that function again until the
cause of error is fixed.
Frequently checking the BRMS/400 log is recommended. Use the *RTV option to
check on retrieve operations.
The DSPLOGBRM command supports the display of log entries that record the
occurrence, success, and failure of BRMS/400 operations. The same log concept
that is used throughout BRMS/400 can also be used to track retrieve operations.
Log entries are categorized by type to show which operation caused the log entry.
The entry type *RTV is supported for retrieve type operations and is used to
record whether these are successful or unsuccessful. A user can search all
BRMS/400 log entries using type *RTV to audit retrieve operations.
Issue the DSPLOGBRM *RTV command to list all of the available log entries for
retrieve operations.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 283
• ASP to contain the retrieved file has exceeded its storage utilization limit.
• User accessing the archived file did not have appropriate authority to perform
a retrieve operation.
See Backup Recovery and Media Services for OS/400 (part of the IBM Online
Library SK2T-2171) for additional information on the RSMRTVBRM command.
If you specified *YES for the Confirm Retrieval parameter and are assuming that
this is not a batch operation, the confirm display in Figure 161 is shown.
The Confirm Retrieve display shows a list of files for which retrieve operations
were delayed or unsuccessful. It allows the user to select and retry, ignore, or
cancel the retrieve operation for one or more of the files listed. Use option 1
(Confirm) to select and retry the retrieve operation. Use option 4 (Remove) to
cancel the retrieve operation. Leave the option column blank to ignore the
retrieve operation and leave it for execution at a later time.
The automatic submission of this command to batch implies that you do not use
the confirm display. You must decide which retrieve operations you want to select
for initiation at the time that you submit the command to the scheduler. You may
want to consider the following suggestions for inclusion criteria:
• Library *ALL: Unless you know exactly which libraries contain archived file
members, we recommend that you use the *ALL option. If you require extra
peace of mind by specifying library names, you need to submit a separate
RSMRTVBRM command for each library. This may involve writing a simple CL
program.
• Auxiliary Storage Pool ID: You may have an application that you know
resides in a specific ASP. By specifying this ASP number, you are ensuring
that you do not automatically start any unusual or unexpected retrieve
operations. In general, however, we recommend that you specify *ALL.
• Retrieve Select *DELAY: In most cases, we recommend that you only
automatically initiate retrieve operations that were purposefully delayed. Using
the *ALL parameter includes retrievals that have been halted because of
storage or security considerations. In both of these cases, further operator or
administrator action may be required before these retrievals can take place.
When you submit the RSMRTVBRM command in batch, we advise you to have
someone check for other file members that may be waiting to be retrieved. These
include file members that you did not include in your selection criteria in the batch
submission of the command and any “failed” retrievals due to authority or storage
exceptions. We do not recommend that you include these in the batch submitted
command. For example, if you regularly run the RSMRTVBRM *DELAY
*RETRIEVE *NO command, there may be other file members waiting to be
retrieved that are not retrieved such as those that have *STORAGE or
*SECURITY conditions. An interactive “double-check” needs not be performed as
regularly as the automatic scheduling of the batch command. In addition, further
action may be needed before retrying the failed retrievals such as ASP clear up
or security adjustments. You can use the *REPORT option of the RSMRTVBRM
command to print any pending retrieves after the *DELAY retrieve operation has
been run in batch.
Scheduling the batch submission may be performed for your entire system. If you
choose to set the system-wide Retrieve Policy to use a retrieve mode of *DELAY,
you are effectively queueing up most of the system retrieve requests until a
suitable time for significant tape activity. This approach is useful for good
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 285
balancing of system resources, in particular, your tape devices. However, it
reduces the responsiveness of the retrieve system. Note that it can also lead to
stocking up a large number of retrieve requests and the time window for
completing all of them may affect other necessary tape activity.
Without the confirm display, you remove the necessity to make decisions for each
file member. However, you still need to specify your include parameters. We
recommend you use the same ones listed for the previous batch submission.
However, by invoking this command interactively without the confirm display only
buys you a possible improved performance, which you can also set up by
creating a special high priority batch job. This approach ties up an interactive
session for an indefinite time period.
With the confirm display, you gain much more flexibility. You may choose to
perform any of the following options:
• Use the display to understand which retrieve operations have been delayed
due to storage or security exceptions and take the necessary action to resolve
these issues and retry the retrieves.
• Use the information on the confirm display to help you roughly estimate the
restore times and storage level effects of retrieving certain file members, and
on this basis, choose which ones to initiate.
• Identify which file members should not even be retrieved and take action to
prevent this from occurring, ranging from simply cancelling the retrieve to
removing or excluding the file member from your BRMS/400 archive lists.
In each of these cases, you must have an administrator who is qualified to make
such decisions and take appropriate action to run the RSMRTVBRM command
with the confirm display.
For example, if the user chooses to alter the parameter to allow users with *USE
authority to an object to retrieve that object (by setting the parameter to *USE),
that user may “create” objects (through retrieve) that they normally are only able
to read.
One way to reduce the chances of retrieving inappropriate data is to use the
restore options supplied in the retrieve policy and the SETRTVBRM command.
The Allow object differences parameter helps prevent the restoration of deleted
and subsequently recreated file members. If you set the parameter to *NONE, the
create time stamp and owner information are cross-checked before allowing the
restore. Therefore, if a delayed retrieve is finally submitted after a member has
been deleted and re-created, the restore operation cannot succeed.
Chapter 13. Practical implementation of hierarchical storage management archiving capabilities 287
– Include SETRTVBRM in the initial program for the required users.
– When compiling this initial program, set the run authority of the program to
*OWNER. This adopts the authority of the program object's owner. You
may change this parameter after the compile with the CHGPGM command.
– Compile the initial program under a user profile that has authority to the
SETRTVBRM command. You may change this parameter after the compile
with the CHGOBJOWN command.
– As an extra measure, you may restrict the authority to the program object
itself.
A.1.4 Reports
Report enhancements include:
• New Reports menu (BRMRPT) added:
A new Reports menu has been added to the BRMS/400 main menu. The
Reports menu contains commonly used reports.
• Enhancements to the Recovery Volume Summary report:
The Recovery Volume Summary report now includes duplicate volumes where
appropriate.
A.1.5 General
Other general enhancements include:
• New user profile QBRMS:
A user profile called QBRMS is now created during installation for you on your
system if it does not already exist. This user profile is used for internal
BRMS/400 purposes and should not be deleted. This change provides the
A.2.4 Reports
Some of the new report enhancements include:
• New report, Link Information report that is in the QP1ADI printer file.
• New report, Object Link List = QP1AFS.
A.2.5 General
Enhanced recoverability feature requires the conversion of all programs to ILE.
A.3.4 Reports
Some of the report enhancements include:
• A new Reports menu has been added to the BRMS/400 main menu. The
Reports menu contains commonly used reports.
• New report, Link Information report that is in Q1APDI printer file.
• New report, Object Link List = QP1AFS.
A.3.5 General
Other general enhancements include:
• Enhanced recoverability feature requires the conversion of all programs to
ILE.
• A user profile called QBRMS is now created during installation for you on your
system. This user profile is used for internal BRMS/400 purposes and should
not be deleted. This change provides the BRMS/400 database more security
in that changes can only be made to the database through BRMS/400
functions or APIs unless the user has a higher assigned authority such as
QSECOFR.
The performance suggestions mentioned here are aimed at the high performance
tape drives such as the 3590. However, other tape drives can also benefit by
ensuring that the correct parameters and options are used during your save and
restore operation.
The choice of using HDC (the DTACPR option on the save commands) and
compaction (the COMPACT option on save commands) is important when
deciding between faster rates or fewer tapes used. For each of the following tape
devices, these are the options that you should have:
• 6380 tape device:
a. DTACPR(*YES) COMPACT(*NO)
b. DTACPR(*YES) COMPACT(*NO)
• 6385 tape device (using QIC5010 format cartridge):
a. DTACPR(*NO) COMPACT(*DEV)
b. DTACPR(*NO) COMPACT(*DEV)
• 6385 tape device (using other format cartridges):
a. DTACPR(*YES) COMPACT(*DEV)
b. DTACPR(*YES) COMPACT(*DEV)
• 6390 tape device:
a. DTACPR(*NO) COMPACT(*DEV)
b. DTACPR(*NO) COMPACT(*DEV)
• 2644 IOP (using 3422, 3430, 3480, 3490 tape devices):
a. DTACPR(*YES) COMPACT(*NO)
b. DTACPR(*YES) COMPACT(*DEV)
Note: Option a provides the best performance. Option b uses fewer tapes.
The data written to the tape must come from the disk drives. Therefore, the sum
of disk operations and tape operations must be equal to or less than the system
bus bandwidth. Two high performance tape devices on the same bus can create a
performance bottleneck, where the tape drives compete with the system bus
bandwidth.
With the RISC systems, the I/O bus rate has increased from 8 MB/sec to
16 MB/sec or 24 MB/sec depending on the machine type. The higher bus
bandwidth now allows you to attach the tape drive and the disk drives on the
same bus.
On CISC systems, the block size is 24 KB. With V3R6, this block size was
increased to 28 KB. Beginning with V3R7, the block size is 256 KB. This allows
better save and restore rates for high performance tape drives such as the 3590
and the 3570.
PGM PARM(&DEV)
DCL VAR(&DEV) TYPE(*CHAR) LEN(10)
/**************************************************************/
/* Define the media policy to be used. */
/**************************************************************/
/**************************************************************/
/* Make sure that QSYSOPR does not interrupt the save. */
/**************************************************************/
/**************************************************************/
/* Call program SETBRMVOL to create a category and add */
/* volumes to it in the order BRM will expect them */
/**************************************************************/
/**************************************************************/
/* Rename QMLDSBS so that BRMS/400 will not be able to */
/* start it after the SAVSYSBRM command completes */
/**************************************************************/
ENDMLD OPTION(*IMMED)
DLYJOB DLY(60)
RNMOBJ OBJ(QMLD/QMLDSBS) OBJTYPE(*SBSD) NEWOBJ(QMLDSBSTMP)
MONMSG MSGID(CPF0000)
/**************************************************************/
/* Perform the system save */
/**************************************************************/
/**************************************************************/
/* Save the following libraries while still restricted. */
/**************************************************************/
/**************************************************************/
/* Rename the subsystem */
/**************************************************************/
/**************************************************************/
/* Call SETBRMVOL to change the volume category to */
/* *NOSHARE and delete the catagory we created. */
/**************************************************************/
INZMLD
DLYJOB DLY(360)
CALL PGM(SETBRMVOL) PARM(&DEV RMV)
MONMSG MSGID(CPF0000)
ENDPGM
/**************************************************************/
Figure 162. Program for restricted save processing with the 3494
/**************************************************************/
/* Define the number of volumes to add to this category */
/**************************************************************/
/**************************************************************/
/* Define the name of the 3494 */
/**************************************************************/
/**************************************************************/
/* Define the media class */
/**************************************************************/
/**************************************************************/
/* Use the SYSTEM name as the temporary category */
/* BRMS/400 uses the LOCAL LOCATION name on the volume record */
/**************************************************************/
/**************************************************************/
/* Option ADD processing. */
/**************************************************************/
/**************************************************************/
/* Option RMV processing. */
/**************************************************************/
LOOP:
RCVF
/* Change the category the volume is assigned to. */
Figure 163. CL program to create a tape category and add volumes (Part 1 of 2)
/**************************************************************/
/* Option RMV processing */
/**************************************************************/
ELSE CMD(DO)
DMTCTGMLD DEV(&DEV)
MONMSG MSGID(CPF0000)
ENDPGM
/**************************************************************/
Figure 164. CL program to create a tape category and add volumes (Part 2 of 2)
/**************************************************************/
/* PROGRAM: MLDPGM */
/**************************************************************/
PGM
DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(256)
DCL VAR(&MSGF) TYPE(*CHAR) LEN(10)
DCL VAR(&MSGFLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)
MONMSG MSGID(CPF0000 MCH0000) EXEC(GOTO CMDLBL(ERROR))
/**************************************************************/
/* File Override */
/**************************************************************/
/**************************************************************/
/* Display MLD information and run the query */
/**************************************************************/
DLTF FILE(QTEMP/TEMP1)
MONMSG MSGID(CPF0000)
/**************************************************************/
/* Default error handler */
/**************************************************************/
Note: We used MLD01 (highlighted in bold in Figure 165) in our example for the
media library device. You need to substitute this parameter with the media library
device name that you have on your system.
Query . . . . . . . . . . . . . . . . . MLDQRY
Library . . . . . . . . . . . . . . . QGPL
Query text . . . . . . . . . . . . . .
Query CCSID . . . . . . . . . . . . . . 65535
Query language id . . . . . . . . . . . ENU
Query country id . . . . . . . . . . . US
Collating sequence . . . . . . . . . . Hexadecimal
Processing options
Use rounding . . . . . . . . . . . . Yes (default)
Ignore decimal data errors . . . . . No (default)
Ignore substitution warnings . . . . Yes
Use collating for all compares . . . Yes
Selected files
ID File Library Member Record Format
T01 QA1AMM QUSRBRM *FIRST QA1AMMR
T02 TEMP1 QTEMP *FIRST QTAVOUTF
Join tests
Type of join . . . . . . . . . . . . . Unmatched records with primary file
Field Test Field
T02.RDMID EQ T01.TMCVSR
The following files are currently valid for both V3R2M0 and V3R6M0:
Object Type Attribute Description
------------------------------------------------------------------------
QJ1ACM *JRN BRMS Journal
QA1AAF *FILE PF-DTA Archive Folder Lists
QA1AAG *FILE PF-DTA Archive Control Groups Entries
QA1AAM *FILE PF-DTA Archive Control Group Attributes
QA1AAO *FILE PF-DTA Archive Object List Entries
QA1AAQ *FILE PF-DTA Archive Spool File List Entries
QA1AARC *FILE PF-DTA
QA1AARF *FILE PF-DTA
QA1AAX *FILE PF-DTA Archive Policy Attributes
QA1ABMM *FILE PF-DTA Media - Media Class and Volume
QA1ABX *FILE PF-DTA Backup Policy Attributes
QA1ACA *FILE PF-DTA Calendar Names
QA1ACG *FILE PF-DTA Backup Control Group Entries
QA1ACM *FILE PF-DTA Backup Control Group Attributes
QA1ACN *FILE PF-DTA Container Status
QA1ACT *FILE PF-DTA Container Classes
QA1ADI *FILE PF-DTA
QA1ADV *FILE PF-DTA Device Name Entries
QA1ADXR *FILE PF-DTA Media Information by Volume
QA1AFD *FILE PF-DTA Folder Save History
QA1AFL *FILE PF-DTA Folder List Names
QA1AFS *FILE PF-DTA
QA1AHS *FILE PF-DTA Save History Details
QA1AIA *FILE PF-DTA Subsystems to check before IPL
QA1AJH *FILE PF-DTA Job Queues to hold
QA1ALB *FILE PF-DTA
QA1ALG *FILE PF-DTA BRM Log Information
QA1ALI *FILE PF-DTA
QA1ALM *FILE PF-DTA Backup and Archive lists
QA1ALQ *FILE PF-DTA Backup Spool File List Entries
QA1ALR *FILE PF-DTA Save History - Save Statistics by Library
QA1AMB *FILE PF-DTA Save History - Save Statistics by Object
QA1AMD *FILE PF-DTA Media Library Device Entries
QA1AME *FILE PF-DTA Media Policy Attributes
QA1AMM *FILE PF-DTA Media Inventory
QA1AMP *FILE PF-DTA Move Policies
QA1AMT *FILE PF-DTA Media Class Attributes
QA1AMV *FILE PF-DTA
QA1ANET *FILE PF-DTA Network Save History
QA1AOB *FILE PF-DTA Backup Object List Entries
QA1AOD *FILE PF-DTA Object Detail
QA1AOL *FILE PF-DTA Libraries to omit from backups
QA1AOQ *FILE PF-DTA Save History - Spool Files
QA1AOT *FILE PF-DTA Object types
QA1ARA *FILE PF-DTA Recovery Activities
QA1ARC *FILE PF-DTA Recovery Contacts
QA1ARCY *FILE PF-DTA Recovery Records (STRRCYBRM)
QA1ARMT *FILE PF-DTA Network Group
QA1ARP *FILE PF-DTA Retrieve Policy
QA1ARX *FILE PF-DTA Recovery Policy
QA1ASE *FILE PF-DTA Subsystems to end
QA1ASG *FILE PF-DTA Signoff Exceptions
QA1ASL *FILE PF-DTA Storage Locations
QA1ASP *FILE PF-DTA System Policy
QA1ASRC *FILE PF-SRC Printer File Source
QA1AVER *FILE PF-DTA Version Control
QA1AWAG *FILE PF-DTA
QA1AWCG *FILE PF-DTA
QA1AWSF *FILE PF-DTA
QA1A1CA *FILE PF-DTA Calendar Entries
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
The information contained in this document has not been submitted to any formal
IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these
techniques to their own environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries licensed
exclusively through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned
by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks
of others.
The following publications are available only on CD-ROM. For more information,
please visit the iSeries Information Center at:
http://publib.boulder.ibm.com/pubs/html/as400/ic2924/info/index.htm
• AS/400 Road Map for Changing to PowerPC Technology, SA41-4150
• OS/400 NetWare Integration Support, SC41-3124
• Automated Tape Library Planning Guide, SC41-3309 (V3R7)
• SNA Distribution Services, SC41-3410
• OS/400 Integration of Lotus Notes, SC41-3431
• Software Installation Guide, SC41-4120 (V3R7)
• Integrating AS/400 with Novell NetWare, SC41-4124
• Backup and Recovery - Basic, SC41-4304 (V3R7)
• Backup and Recovery - Advanced, SC41-4305 (V3R7)
• Distributed Data Management, SC41-4307
• Data Management, SC41-4710
• Tape and Diskette Device Programming, SC41-4716
The following publications are available in the IBM Online Library CD-ROM
SK2T-2171:
• LAN Server/400 Administration
• Backup Recovery and Media Services for OS/400
This information was current at the time of publication, but is continually subject to change. The latest information
may be found at the Redbooks Web site.
Company
Address
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
Index 323
Add Media to BRM 20, 43 default weekly activity 274
Add Object List, archive 269 direct tape I/O 260
Add Server Storage Link 146 double save 221
adding a tape cartridge 189 implementation 261
adding media information 47 inactivity limit 273
adding systems to network group 104 include criteria 275
ADDJOBSCDE 277 key factors 240
ADDMEDBRM 20, 43, 184 logical files 225
ADDMEDIBRM 45 media class 270
ADDMLD 165, 173 media policy 271
ADDMLMBRM 43, 184 member level 245
ADDNWSSTGL 146 move policy 270
ADDTAPCTG 189 normal aged file member 223
ADSM 123 object types 261
ADSTAR Distributed Storage Management 123 pseudo record-level 254
aged file member, archive 223 saving access paths 237
allocate resources 174 source file members 224
allocated, status 175 storage freed 274
allocation status 175 tape duplication 227
allocated 175 tape duplication process 227
deallocated 175 archive candidates
stand-alone 175 active data sets 264
unprotected 175 data file with transaction based members 262
Allow object differences parameter 200, 279 data file with transaction based records 262
alternate IPL digital libraries 263
3494 153 disused test data 261
3570 156 historical data 263
3590 154 mixed characteristic data files 263
9427 154 outfile data 261
alternate IPL device 198 random access data files 262
ALWOBJDIF 200, 279 source files 263
retrieval 287 statistically random access data files 262
APARs temporary data files 261
II08968 68 archive control group 275
II09313 127 archive lists 217, 268
II09475 209 archive policy 273
II09724 177 archive structure, BRMS/400 267
II09772 11, 209 archive with Dynamic Retrieval 268
APPC 101 archive, without storage freed 219
Append to media parameter 35, 71 STG(*FREE), archive 219
APPEND(*NO) 35 archived files 243
APPEND(*YES) 28 , 71 archived libraries 244
APPEND(*YES), control group 186 archived object 243
appending to media rules 44 AS/400 home page 209
application design 245 ASP overflow 242
considerations 245 attributes, control group 42, 69
application swapping 224 authority
applications, interactive 238 *PUBLIC 101
applying journal changes 235 LAN Server/400 128
APPN 101 retrieve 286
archive 2 authority for IFS, save 127
access paths 274 auto enroll media 22, 64, 213
application design 245 automated tape library
application suitability 245 3494 151, 165
apply journal changes 235 3570 155
by BRMS/400 217 3590 154
candidates 275 9427 153
considerations 217 allocate resources 174
database file members 223 change device description, CISC 173
date for *FILE objects 273 change device description, RISC 174
Index 325
category, *INSERT 187 INZMLD 165
central point, recovery 194 INZTAP 45
Centralized Media Audit Report 59 MONSWABRM 73, 79
Change Job Scheduler 93 MOVMEDBRM 28, 52, 60, 189
Change License Information 13, 212 MOVOBJ 234
Change Network Attribute 101 PRTMEDBRM 60
Change Presentation Controls 33 RCLSTG 235
Change Presentation Controls display 33 RMVJRNCHG 235
changing media library device descriptions 172 RMVM 234
changing the device description RMVTAPCTG 189
CISC 173 RNMM 234
RISC 174 RNMOBJ 234
changing the system name 113 RSMRTVBRM 232, 278, 283
check availability, media 57 RST 124
Check Expired Media for BRM 50, 63 RSTAUT 220
checking the BRMS/400 network 120 RSTOBJBRM 219
CHGLICINF 13 SAV 124
CHGNETA 101 SAVMEDIBRM 58, 193
CHGSCDBRM 93, 277 SAVSAVFBRM 36, 58, 193
CHKEXPBRM 50, 63 SAVSYSBRM 69
CISC, changing the device description 173 SBMNWSCMD 130
Client Access/400 146 SETRTVBRM 231, 277
commands STRARCBRM 276
ADDJOBSCDE 277 STRBKUBRM 50
ADDMEDBRM 20, 43 STREXPBRM 26
ADDMEDIBRM 45 STRJRNAP 234
ADDMLD 165 STRJRNPF 234
ADDMLMBRM 43, 188 STRMNTBRM 26, 52, 232
ADDNWSSTGL 146 STRRCYBRM 52, 191
ADDPFM 234 STRSST 174
ADDTAPCTG 189 VFYMOVBRM 61
CHGLICINF 13 WRKCFGL 101
CHGNETA 101 WRKCFGSTS 166
CHGOBJAUD 234 WRKCLSBRM 24
CHGOBJD 234 WRKCLSBRM *MED 270
CHGOBJOWN 234 WRKCTLGBRM 37, 66
CHGPF 234 WRKCTLGRP *ARC 275
CHGPFM 234 WRKDEVBRM 21
CHGSCDBRM 93, 277 WRKJOBSCDE 277
CHKEXPBRM 50, 63 WRKLBRM 128
CHKOBJ 234 WRKLNKBRM 140
CPYMEDIBRM 97, 108 WRKLOCBRM 19
CRTDEVMLB 166, 168 WRKMEDBRM 43
CRTNWSD 125 WRKMEDIBRM 53, 70
DLTF 235 WRKMLBBRM 23
DSPBKUBRM 55 WRKMLBSTS 159, 176
DSPDEVSTS 166 WRKMLMBRM 159, 183
DSPHDWRSC 167 WRKNWSSSN 133
DSPLANMLB 171 WRKOBJBRM 205, 219
DSPLOG 235 WRKPCYBRM 214
DSPLOGBRM 50, 58, 283 WRKPCYBRM *MED 273
DSPNETA 101 WRKPCYBRM *MOV 270
DSPOBJD 234 WRKPCYBRM *RTV 277
DSPTAP 46 WRKREGINF 12
DSPTAPSTS 159 WRKSPLFBRM 85
DUPMEDBRM 60, 228 WRKTAPCTG 183
EDTRBDAP 35 completing recovery 201
EXTMEDIBRM 45 concept of Dynamic Retrieval 225
INZBRM 14, 106, 108, 167, 181 considerations, Dynamic Retrieval 286
INZMEDBRM 45 console monitor 87
Index 327
end option BRMS/400 limitations 136
*LEAVE 186 disaster recovery 147
*REWIND 186 hints 147
*UNLOAD 186 LAN Server 123
End option (ENDOPT) setting 185, 278, 279 managing saves using BRMS/400 140
ENDMLD 165, 173 memory requirements 127
ENDOPT setting 185 overview 123
ENDOPT(*LEAVE) 186 planning for saving directories 124
ENDOPT(*REWIND) 186 recovery 208
ENDOPT(*UNLOAD) 186 restore 123
Enhanced Upgrade Assistant tool 211 restore directories with BRMS/400 142
enhancements, BRMS/400 7, 17, 57 save recommendations 136
enroll media, automatically 64 save strategy 136
enrolled tapes 188 saving 123
re-activating 188 saving using BRMS/400 137
enrolling media 43 setting up BRMS/400 138
enrolling new tapes 188 V3R1 data 146
exclusive locks 72 IFS directories 142
exit program 12 II08968 68
expire volumes 20 II09313 127
exporting cartridges 189 II09475 209
EXTMEDIBRM 45 II09724 177
extracting media information 45 II09772 11
II09992 209
IMP001 cartridge identifiers 184
F implementation, save-while-active 73
failed retrieve operations 283 implementing an archive 261
file member, renaming 243 implementing BRMS/400 17
file renaming 243 implementing Dynamic Retrieval 264
file size 237 import/export, 3570 155
file size, retrieve performance 237 importing cartridges 187
files copied, CPYMEDIBRM 108 inactivity limit 273
files, media management 108 include criteria 275
fragmentation 237 Initialize BRM 14, 199
FSIOP 39, 123 Initialize Media Library Device 165
FULIC 154, 195 Initialize Tape 45
functional enhancements 3, 7, 17, 57 initializing media 43
initializing the BRM environment 14
G installation planning 7
Generate cartridge identifiers field 170 installing BRMS/400 11
grant authority, LAN Server/400 130 integrated file system 123
Integrated PC Server 39, 123
integration
H Lotus Notes 123
hardware data compression (HDC) 301 Novell NetWare 123
hardware resource manager (HRM) 201 interactive applications 238
HDC (hardware data compression) 301 invoking retrieval 233
hierarchical storage management 217 INZBRM 14, 167, 181, 199
planning 217 INZBRM *NETSYS 106, 108
using BRMS/400 267 INZBRM *NETTIME 110
hints, save and restore 147 INZMEDBRM 45
historical data 263 INZMLD 165
home location 19 IPL device, alternate 198
horizontal splitting, database 250, 253
HRM (hardware resource manager) 201
HSM (hierarchical storage management) 217 J
job priority 185
job queue processing 40
I job queues to hold 297
IFS 137 job queues to process 297
authority 127 job scheduler, OS/400 93
Index 329
MLDD commands OPNQRYF, retrieve 233
ADDMLD 173 optimum block size 23
DLTDEVMLB 173 option (ENDOPT) setting, end 185
ENDMLD 173 OS/400 job scheduler 93
RMVMLD 173 OS/400 recovery 197
upgrade to PowerPC AS 213 outfile data 261
mode overview of BRMS/400 1
blank 101 overview of IFS 123
QBRM 101
monitor job, ending example 133
monitor save while active for BRM 73 P
MONSWABRM 79 performance
mount volume, 3494 161 double save 222
move archived object 243 file size 237
Move Media using BRM 28, 184 join logical files 226
move policy 26 LAN Server/400 135
archive 270 multi-format files 226
movement report 63 multiple physical files 237
moving media 60 retrieve 237
MOVMEDBRM 28, 52, 60, 189 planning for saving IFS 124
MQSeries 211 planning for upgrades to PowerPC AS 209
MSE, see media and storage extensions 12, 230 policies, BRMS/400 3, 31
MULIC 154, 195 policy
multi-format files, performance 226 archive 273
multiple devices, 3494 177 media 28
multiple physical files 237 move 26
multiple systems attachment, 3494 152 retrieve 231, 277
predicting
object size 241
N time 242
naming convention 8 preparation for the recovery 195
network communications 101 Print Media Exceptions for BRM 60
network drive 136 print recovery report 192
network file transfer 234 priority slot 187
network group, removing a system 111 3570 155
network security 101 priority, job 185
network server description 125 private authorities 220
network server storage space 125 processing
networking, BRMS/400 97, 194 job queue 40
new tapes, enroll 188 subsystem 41
non-barcode libraries 170 PRTMEDBRM 60
non-barcode reader library 183 pseudo record-level archiving 254
normalization, database 246
Novell NetWare integration 123
Q
Q1ABRMNET subsystem 98
O Q1APRM 51
object description, retain 274 QA1ANET file 210
object locks, double save 222 QAUTOCFG 167, 168
object retention 279 QAWUSRDMN 13
value 233 QBRM mode 101
object retrieval 241 QBRMS user profile 100, 109
object size 241 QDLS 124
object types 261 QNetWare 211
ObjectConnect 50 QPGMR user profile 101
omit libraries 35 QSYSLIBL 12
ONLINE(*NO), 3494 169 Query/400 233
ONLINE(*YES), 3494 169 Query/400, retrieve 233
Open Query File (OPNQRYF) 233 QUSER user profile 101
operations that do not invoke retrieval 234
operations that invoke retrieval 233
Index 331
RST 124, 146 sign-off interactive users 69
RSTAUT (restore authority) 220 source file members, archive 224
RSTOBJBRM 219 source files 263
rules, appending to media 44 special authority 131
special cartridge identifiers 184
splitting database 248
S spooled files, save 84
SAV 124, 146 SQL/400 233
Save access paths parameter 274 SRM (system resource management) 200
save and restore hints 147 SST (System Service Tools) 174
save authority for IFS 127 stand-alone device mode 160
save files 58, 193 stand-alone mode, 3494 160
save object (SAV) 124 stand-alone status value 175
save recommendations for IFS 136 stand-alone tape resource 190
Save Save File using BRM 36, 193 Start Archive using BRM 276
Save Strategy Exceptions Report 60 Start Backup using BRM 50
save strategy for IFS 136 Start Expiration using BRM 26
save with storage freed 217, 218 Start Maintenance BRM 26, 52
saves, unattended 49 Start Recovery using BRM 52, 191
save-while-active 72 statistically random access data files 262
save-while-active implementation 73 STG(*FREE) 218
Save-while-active parameters 74 stopping BRMS/400 for upgrades 211
saving BRMS/400 recovery data 193 storage freed 218
saving IFS using BRMS/400 137 archive 274
saving LAN Server/400 user data 127 storage location 9, 18, 30
saving media information 58 storage management, hierarchical 217
saving spooled files 84 storage space 124, 125
saving user information for upgrades 211 storage space restore 145
saving V3R1 IFS data 146 STRARCBRM 276
SAVLIBBRM 69 STRBKUBRM 50
SAVMEDIBRM 58 STREXPBRM 26
SAVSAVFBRM 36, 58 STRMNTBRM 26, 52, 58, 232
SAVSYS 87, 160, 197 walk-through 58
SAVSYSBRM 69 STRRCYBRM 52, 191
SAVxxx ACCPTH(*YES) 234 structure, LAN Server/400 125
SBMNWSCMD 130 Submit Network Server Command (SBMNWSCMD) 130
scheduling jobs 91 subsystem processing 41
archive 276 subsystem, Q1ABRMNET 98
scratch pool 2, 8 subsystems to end 296
scratch volumes 50 subsystems to process 296
SDC (system data compression) 301 suitable application, archive 245
secure location 101 support home page 209
secure retrieve policy 287 SWA message queue 73, 80
securing the retrieve policy 287 swapping, application 224
security, network 101 synchronization 72
selecting devices, 3494 179 synchronizing
sequential mode, 9427 154 libraries 76
server storage space 125 media maintenance 193
Set Retrieve Controls for BRM 277 media movement 193
Set Retrieve using BRM 231 recovery report 193
set up retrieve policy 277 system data compression (SDC) 301
SETRTVBRM 231, 277 system name change 113
setting up BRMS/400 for IFS 138 system policy 31
setting up the tape device for SAVSYS recovery 197 automatically backup media information 33
setting, end option (ENDOPT) 185 day start time 32, 33
SHARE(*NO) 49 presentation controls 32, 33
SHARE(*YES) 49 system recovery 195
shared device support 22 , 213 SAVSYS 160
shared media 24, 25 system recovery report 191
shared media library 25 system resource management (SRM) 200
side-by-side, resynchronizing 215
Index 333
334 Backup Recovery and Media Services for OS/400
IBM Redbooks review
Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook
"made the difference" in a task or problem you encountered. Using one of the following methods, please review the
Redbook, addressing value, subject matter, structure, depth and quality as appropriate.
• Use the online Contact us review redbook form found at ibm.com/redbooks
• Fax this form to: USA International Access Code + 1 845 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Review
Questions about IBM’s privacy The following link explains how we protect your personal information.
policy? ibm.com/privacy/yourprivacy/
Concepts and tasks to This IBM Redbook preserves the valuable information from the
first edition of A Practical Approach to Managing Backup
INTERNATIONAL
implement BRMS for
Recovery and Media Services for OS/400, SG24-4840, which is TECHNICAL
OS/400 on AS/400e
based on CISC implementations. The updates in this edition were SUPPORT
servers
made to reflect the documentation and URL values that were ORGANIZATION
Tips and techniques available at the time of publication.
to make your BRMS
This publication is unique in its detailed coverage of using
implementation run BRMS/400 with tape libraries within a single AS/400 CISC
smoother BUILDING TECHNICAL
system, or within multiple AS/400 CISC configurations across INFORMATION BASED ON
multiple levels of OS/400 ranging from OS/400 V3R1 to and PRACTICAL EXPERIENCE
Best practices for through OS/400 V3R7. Coverage for BRMS for OS/400 for RISC
media and tape and iSeries systems will be found in a redpaper that is planned IBM Redbooks are developed
management for publication in 2001. by the IBM International
Technical Support
This redbook focuses on the installation and management of Organization. Experts from
IBM, Customers and Partners
BRMS/400 using tape libraries such as IBM 9427, IBM 3494, IBM from around the world create
3570, and IBM 3590. It provides implementation guidelines for timely technical information
using BRMS/400 to automate your save, restore, archive, and based on realistic scenarios.
retrieve operations. It also contains practical examples of Specific recommendations
managing your media inventory across multiple AS/400 CISC are provided to help you
implement IT solutions more
systems. This redbook also identifies functional differences effectively in your
between BRMS/400 and OS/400 CISC releases, where environment.
appropriate.