× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



2. Why would you want the save or auto dup to ALWMLTTHD? We don't but it was changed by a user with too much authority and too little knowledge!



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: Friday, August 14, 2015 8:35 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,



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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.