Paul,
1. We append our Auto dups, mainly for weekends when movement does not run, so less volumes are used.
DUPMEDBRM defaults to seq 1.
I did successfully QSYS/CHGCMDDFT CMD(DUPMEDBRM) NEWDFT('TOSEQNBR(*END)')
However, BRMS PTFs always sets this back to default, 1.
So in our AJS scheduled job for the BRMS STRBKUBRM save, I always set to *end, so AutoDup will append.
20 QSYS/CHGCMDDFT CMD(DUPMEDBRM) NEWDFT('TOSEQNBR(*END)')
2. Why would you want the save or auto dup to ALWMLTTHD?
4. On our Production LPAR, we have one control group for all our daily full save, retention of 45 days.
Four times a month, we have the need to retain the save for 13 months.
Month end save is Perm.
We were successfully able to override the STRBKUBRM save for the different retentions, but not the AutoDup.
IBM DCR request created a data area for this purpose.
In my AJS BRMS save job, we set the data area, which then controls the AutoDup
50 CRTDTAARA DTAARA(QTEMP/Q1ADMEDPCY) TYPE(*CHAR) LEN(10) VALUE('CYCBR...
60 CHGOBJOWN OBJ(QTEMP/Q1ADMEDPCY) OBJTYPE(*DTAARA) NEWOWN(QBRMS)
How to Override the Auto Duplication To Media Policy for STRBKUBRM
The control group specified on the Start Backup using BRM (STRBKUBRM) command determines which media policy will be used during the backup. The Automatic duplication fields in the media policy determine whether media used for a backup will automatically be duplicated. The To media policy field for Automatic duplication is used to specify the media policy of the output volumes.
In releases IBM i 6.1 and later, to override the media policy that is specified in the Automatic duplication To media policy field when STRBKUBRM is run, do the following.
CRTDTAARA DTAARA(QTEMP/Q1ADMEDPCY) TYPE(*CHAR) LEN(10) VALUE(nnnnnnnnnn)
QSYS/CHGOBJOWN OBJ(QTEMP/Q1ADMEDPCY) OBJTYPE(*DTAARA) NEWOWN(QBRMS)
Where nnnnnnnnnn is the media policy that will be used as the to media policy on the auto-duplication.
Note: In releases IBM i 7.1 and IBM i 6.1, the following PTFs or their superseding PTFs are required:
7.1 SI50292
6.1 SI50291
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20Backup%2C%20Recovery%20and%20Media%20Services%20%28BRMS%29%20for%20i/page/How%20to%20Override%20the%20Auto%20Duplication%20To%20Media%20Policy%20for%20STRBKUBRM
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Fenstermacher
Sent: Thursday, August 13, 2015 4:52 PM
To: Midrange Systems Technical Discussion
Subject: RE: DUPTTAP, DUPMEDBRM and/or AutoDup usage/issues
1. DUPMEDBRM is a proxy command that uses a hard coded library that uses COMPACT(*FROMFILE) which when using ProtecTier as the source won't compact. Can't do a CHGCMDDFT to a library at the top of the LIBL because it doesn't look. This causes us to use 4-5 LTO4 volumes to duplicate 4 ProtecTier volumes each weekend. Take this times 5 systems and we burn through a bunch of LTO4's every week. Supposed to be fixed in the September PTF.
2. Backup and duplication jobs can't run when submitted with the ALWMLTTHD parm on the SBMJOB command set to *YES. We had a user change the command default to *YES and duplication jobs failed. BRMS developers are saying they should hard code it to *NO for their purposes inside the product, maybe in the December PTF.
3. We recently put on the latest V7R1 BRMS PTF and noticed that the QA1ANET2 file on some systems always had greater than 0 records. Turns out there is an obscure issue where if the system name is less than 8 characters this issue can happen. We found it through BRMS Enterprise and it should be fixed in the September BRMS PTF.
4. Early on in using auto dup we found that the submitted auto dup job would use the media policy that was just used for the save as the "to" media policy rather than the one we specified. This caused the wrong retention period to be used for all of our auto dup'ed volumes.
Paul Fenstermacher | Sys Admin, Sr | Corporate Systems – POWER Systems Administration | Jack Henry & Associates, Inc.
663 West Highway 60 | Monett, MO 65708 | 417-235-4114 x177389 | pfenstermacher@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Thursday, August 13, 2015 9:21 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: RE: DUPTTAP, DUPMEDBRM and/or AutoDup usage/issues
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Paul,
Would you mind sharing your DUPMEDBRM with AutoDup issues, I would like to compare notes?
Thanks
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Fenstermacher
Sent: Thursday, August 13, 2015 9:37 AM
To: Midrange Systems Technical Discussion
Subject: RE: DUPTTAP, DUPMEDBRM and/or AutoDup usage/issues
We use DUPMEDBRM with AutoDup all the time, every day on 7 systems and every weekend on 9 systems. We've found a number of issues with this procedure for IBM because, as you say, it's not heavily used but I haven't seen the specific issue you mentioned. Sorry and I think it will probably remain a red headed step child but for us it serves a purpose and we don't really need it to be fast.
Paul Fenstermacher | Sys Admin, Sr | Corporate Systems – POWER Systems Administration | Jack Henry & Associates, Inc.
663 West Highway 60 | Monett, MO 65708 | 417-235-4114 x177389 | pfenstermacher@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Thursday, August 13, 2015 8:10 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: DUPTTAP, DUPMEDBRM and/or AutoDup usage/issues
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
First, I'd like to ask how many of you use DUPTAP, DUPMEDBRM and/or AutoDup on a daily basis?.
I use AutoDup, daily, both production and R&D LPARs, which is DUPMEDBRM, which under the covers is a DUPTAP.
2 reasons.
1) AutoDup confirms if the Save volume is good.
2) D&R plan requires we keep a 2nd copy of all saves off site on a daily basis.
We have no HA and/or DR solution, nor is one on the horizon, cost prohibitive.
Over the years, I've had very few save and/or restore issues, but many DUP issues.
Here's a summary of the latest, 3rd occurrence in less than a year,
While the DUPMEDBRM is running, the source volume/drive throws an error, (see errors below) Indicates either a bad drive or bad volume.
Drive goes into a failed status.
TAPMLB01 library also indicates drive or media error.
Reboot TAPMLB01, reset and clearing all errors.
Rerun the DUPMEDBRM, all is fine.
Both drive and volume actually are ok.
TAP01 was replaced at one point, 9/30/14.
Entire Library chassis was replaced 5/14/15.
All four LTO5 HH drives on latest firmware – E6Q3.
E6Q3 firmware did have code for similar issue.
However, the error does reoccur.
I've been working with Tape support for over a year on this.
Save/Restore team is saying this is tape issue, I'm not convinced.
CPF5110 70 INFO Device TAPMLB01 reported a hardware failure.
BRMS PRODUCT 997536 Q1ACALG 0000 08/11/15 01:24:47.122898 PRODUCT
CPF412F 40 INFO Cartridge 001080 not available.
BRMS PRODUCT 997536 Q1ACALG 0000 08/11/15 01:24:47.128348 PRODUCT
BRM4138 40 INFO Media duplication completed with errors.
BRMS PRODUCT 997536 Q1ACALG 0000 08/11/15 01:24:47.133791 PRODUCT
Also this PAL entry.
System Resource Resource
Ref Code Date Time Class Name Type
63A09300 08/11/15 01:18:02 Perm TAP01 3580
Second, DUPMEDBRM has some serious performance issues.
It's very old code, has not kept up with other I enhancements.
Takes twice as long to DUP a volume (5 hours) compared to the original save (2 1/2).
Third, DUPMEDBRM, DUPTAP, lack "Fast Positioning" which contributes to the lengthy time.
I have a DCR requesting "Fast Positioning", created 11/13/2012.
Latest update is this is not in the near future.
Fourth,
We refresh our 7 R&D environments several times a month.
This is done using RSTLIBBRM on our R&D LPAR using that nights Production save.
Process has been working great.
I had to do some creative job and jobq management so the AUTO dup runs after the RSTLIBRM.
This is also working great.
Fifth, from what I'm hearing, very few use DUPTTAP, DUPMEDBRM and/or AutoDup, thus little or no resources allocated.
Is there anything that could be done from the Midrange group to get this some additional attention.
Or will DUPTTAP, DUPMEDBRM and/or AutoDup remain a dinosaur.
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx
http://www.pencor.com/
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
