× 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.



It is going away. Totally. No replacement system that we will ever
see, just a network connection to a remote data center running
who-knows-what on unknown hardware. Jobs changing as well. Think
"trainwreck". Between now and scheduled end, anything can happen.
Sure wouldn't go over well to have data entrusted to us get lost
before the new data center can lose it.

John McKee

On Thu, Jan 26, 2012 at 3:36 PM, <rob@xxxxxxxxx> wrote:
Are we talking full removal of IBM midrange platform?  Honestly, with only
10 months to go I would let it fly.  Yes, I'd ensure you had good backups
but I would be spending more energy learning the new platform (or honing
my resume').

But if we are talking about a new Power 7 box with new tape drives I'd use
the excuse that you want the operators doing it right when the new machine
arrives.  This might be a good time to phase in "real" brms use.  Convert
your library from sequential to random access and use it all right.  Some
new tape libraries (like ours) will not configure sequential and you must
use random mode.  Then it really helps to have BRMS.  Yes, it can be done
without BRMS and I fought it.  But once I saw how easy it was and how it
cut the operators instructions (by number of pages) in half I was
impressed.  So were the people who cover the operator for when I am gone
also.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to:  2505 Dekko Drive
         Garrett, IN 46738
Ship to:  Dock 108
         6928N 400E
         Kendallville, IN 46755
http://www.dekko.com





From:   John McKee <jmmckee@xxxxxxxxxxxxxx>
To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date:   01/26/2012 03:53 PM
Subject:        Re: More tape required for backup
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



Did a PRTERRLOG *VOLSTAT.  Had some collectively named tape show a
large number of temporary write errors.  Showed that to boss.  He is
reluctant to change things, as this system is scheduled to go away in
ten months.  He is also not thrilled with untraining operators who are
just used to doing things.  But, we have another meeting scheduled.
The large temporary write errors could be a single tape or several.
He said these are about ten years old.

Tapes are oddball.  All 3590.  But at least two different capacities.

Progress by inches.  Or, from StarTrek IV: The Voyage Home:  Kirk to
Scott: Congratulations, you have closed the barn door after the cows
have left.

John McKee

On Wed, Jan 25, 2012 at 3:15 PM,  <rob@xxxxxxxxx> wrote:
A successful 1/4" cartridge tape backup on a Basic 4 was cause for a
beer.

IBM's early AS/400 reel-to-reel backups used to have a bar graph on the
device itself that give an estimate on how much tape was used as it went
along.  I REALLY miss that.  Well, not so much with tape libraries now.
But back when I had to physically mount tapes when each was full...

Better get more tapes ordered up.

Take the clear option on PRTERRLOG to reset your statistics.  And TRY to
use separate volume ids.  Then you can see how much is written to each.
Although, even with the same backup you will see wide discrepancies.
 Most
of that is because it displays how much data it was BEFORE compressing
out
to tape.  DB2 compresses different than other areas of the IFS.
Volume          ---Temporary Errors---   --------M Bytes--------
ID                    Read       Write         Read      Written
                        0           0            1            1
BR0095                   0           0            1       506933
BR0104                   0           0            1       450784
BR0106                   0           0            1       483953
BR0181                   0           0            1      2448038

181 was the first tape of the full system save.  It compressed the hell
out of DB2.

Rob Berendt
--
Group Dekko
Dept 1600
Mail to:  2505 Dekko Drive
         Garrett, IN 46738
Ship to:  Dock 108
         6928N 400E
         Kendallville, IN 46755
http://www.dekko.com





From:   John McKee <jmmckee@xxxxxxxxxxxxxx>
To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date:   01/25/2012 03:34 PM
Subject:        Re: More tape required for backup
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



I was wondering about the capacity of a 3590 tape, and if it was
likely that we just managed to finally get large enough to need that
third tape.  We >may< have been lower on usage - again, I don't look
at that often.  Good to stay out of sa's turf - whether he looks or
not.  I don't know if the SAVE 21 does data compression, or just how
much a 3590 can hold.  I suspect things have improved DRAMATICALLY
since my days with the B50.  We had a 2410 (might be wrong on the
drive number - been too long to mater) tape drive and 8G of DASD.  I
got a few calls about the backup wiping out due to a tape error.  It
was worse than pulling teeth to get new tapes and have older ones
(unknown age) tested for errors.  Probably would have been done a
whole lot faster if the person who authorized purchase of tape got the
wake-up calls in the wee hours of Sunday morning.  Eight+ hours for
backup.

John McKee

On Wed, Jan 25, 2012 at 1:59 PM,  <rob@xxxxxxxxx> wrote:
Yes, GO SAVE 21 does it outside of BRMS.  Although QSYSOPR or DSPLOG
will
have a few messages that indicates that, since BRMS is installed, it's
chomping at the bit to be of assistance.  We had it installed some
years
before actually using it.

Not using unique id's is a real cluster ... for the two reasons you
mentioned:  screws up PRTERRLOG and baffles BRMS.

I supposed you could see if you have old joblogs from saves and count
blocks - yee haw!

But I concur with Chuck, probably some clean up is being missed.  We
IPL
and do full system saves once a quarter.  I have documented clean up
steps
on what I clean up during the week prior.

Then again maybe when the SA's away, the mice will play.  People going
nuts creating test data and stuff?


Rob Berendt
--
Group Dekko
Dept 1600
Mail to:  2505 Dekko Drive
         Garrett, IN 46738
Ship to:  Dock 108
         6928N 400E
         Kendallville, IN 46755
http://www.dekko.com





From:   John McKee <jmmckee@xxxxxxxxxxxxxx>
To:     Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>,
Date:   01/25/2012 02:12 PM
Subject:        Re: More tape required for backup
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



We use GO SAVE 21.  But, I took a look anyway.  No BRM log.

John McKee

On Wed, Jan 25, 2012 at 12:40 PM, Jack Kingsley
<iseriesflorida@xxxxxxxxx> wrote:
Maybe try the DSPLOGBRM command, how GO BRMS, then take reports
option,
there are many reports to pick from, maybe one of those might help you
out.

On Wed, Jan 25, 2012 at 12:21 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 25-Jan-2012 08:50 , John McKee wrote:
Our sa is away.  The last two weeks, the full backup (GO SAVE 21)
has
required three tapes, where it normally requires two. <<SNIP>>
do not believe usage has changed much.  I am wondering if we just
stepped over the threshold that two tapes can hold. <<SNIP>>

  Might be that some "manual cleanup" [periodic or while in
restricted
state after the save] was being done by SA, but the now unchecked
growth
has pushed the limit.  That is to suggest, that sometimes those
actions
do not make their way into the documented procedural steps that
somebody
else might have to perform as a backup\replacement.

  For example:  History logs and audit journal receivers sometimes
either are not saved :-( and\or saved separately and then deleted.
Perhaps deleting all previously saved\eligible receivers, post-save.
The QRPLOBJ which maybe was getting cleared; AFaIK that library is
part
of the save-21.  There may also be "log files" in some directories
that
were being purged, with or without prior save.  And if spool data is
part of the saves, perhaps some SPLF cleanup using or outside of the
GO
CLEANUP.

Regards, Chuck
--
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.

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

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

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.