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/
midrange.com
