The reason the save spills over to a second tape is due to files in IFS
that were built to prepare an archive which runs on a Windows server. Last
week, I ran multiple SAV commands, to test the full tape condition. After
running SAV four times, the tape was filled. A new tape was inserted, and
the SAV then completed. I did this with system running normal, not in
restricted state. Not quite scientific. Something in the previous
commands used by Go SAVE 21 appears to set the stage for partial damage. I
had no trouble at all running 5 SAV commands. Four to fill tape and the
fifth to add to what was already on the second tape from the fourth SAV.

I downloaded the PSP, but hae not gotten into it very far.

I suppose I could just load and apply the HIPERs. Would need to sneak in
the IPLs, somehow. It would be nice to know 1) If that fixes the issue,
and 2) When we had an opeator, and second tape was needed, if operator did
not notice the same error. That goes along with the infamous "if it ain't
broke". Have we been skating on thin ice because the error was not even
noticed? In the past, the second tape would have likely been needed due to
the SAVLIB portion. The files in IFS were never thislarge before.

John McKee

On Wed, Sep 9, 2015 at 2:07 PM, <rob@xxxxxxxxx> wrote:

I could see it.

You could try the RTVCFGSRC.
You could try WRKDEVD and 3 to copy.
I'm concerned that since you can only do this on a Wednesday that it would
just burn another week if this doesn't resolve it.

Another option is to try to get this to fit on one tape.

I would start by running RTVDSKINF.
Once that is done try PRTDSKINF *SYS and see where a bulk of the space it
tied up and then address that. Once you get the 30,000' view then you can
drill down further.

Is it "User Libraries"?
Is it "User directories"?
Is it elsewhere?


If "User libraries" then run
PRTDSKINF RPTTYPE(*LIB) to get a list of your biggest libraries. You can
drill down into that a little by
PRTDSKINF RPTTYPE(*LIB) OBJ(*ALL) MINSIZE(99999)
I've also found WRKJRNRCV JRNRCV(*ALL/*ALL) can be beneficial. Querying
DSPFD (if you had a newer OS I would recommend just querying
SYSPARTITIONSTAT) and RGZPFM those with a lot of deleted records.

If "User directories" make sure you didn't turn on some Management Central
tracing at some time. I've seen this take 30% of a system. This is
/QIBM/UserData/OS400/MGTC/service. If you're not tracing it should be
empty. If it isn't then turn the tracing off and clear it.
IBM has a RTVDIRINF and a PRTDIRINF but it doesn't have near the drill
down capabilities that PRTDSKINF has. No sort by size and whatnot.




Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
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 <jmmckee3@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 09/09/2015 02:48 PM
Subject: Re: Failed GO SAVE 21
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



This is hopefully the link to access the joblog


https://drive.google.com/file/d/0BxXuBYIdtkWtVHNGQWI0eTVfMzlkNkVZY2VNV1VRODZJSFRJ/view?usp=sharing


John McKee

On Wed, Sep 9, 2015 at 12:58 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 09-Sep-2015 09:48 -0600, John McKee wrote:

Three weeks in a row. I saw at the LAN console. Waited for the
tape change message. It came. Change the tape. Waited until drive
indicated tape was at load point. Back to LAN console. Entered G.
SAVE ended with FAIL. I did IOP reset last week. Did it again after
the FAIL message.

The job log shows my G response to the load next tape message.
IMMEDIATELY after that is System object TAP35 partially damaged.


The partial [aka logical or soft] damage is a side effect of the
[previously described-as a likely software] problem. The LIC decidedly
marks the tape as /damaged/ in response to a failure, as a /visible/
manifestation of the /problem/ that was encountered when attempting to
perform a supported method against the device.

Further down, it states VLOG identifier is *NONE.


Presumably the *NONE is the replacement value [missing] for the
replacement-variable "&40" in the msg CPI5922.? A new VLog is not
produced
for damage, if the object is already marked damaged; the prior
damage-set
for the object would need to be located in the LIC logs.

For recovery, it states to delete and recreate the DEVD.


Hmm, then maybe not the CPI5922? As I do not see that recovery
listed.?

Why not just provide the actual joblog [for which message identifier
and
context are available from a spooled LOG(4 0 *SECLVL) joblog], instead
of
offering chosen tidbits [and besides, as paraphrased instead of
literally
quoted]?


Text for current TAP35 *DEVD has "CREATED BY AUTO-CONFIGURATION".

DSPOBJD shows creation as 07/13/06. Also shows change date as
08/16/10. Never saved or restored.

Is there a way to see if it is damaged?


My expectation is that a request to initiate any save [e.g. SAVxxx] to
the tape should diagnose the pre-existing condition of the /damage/;
i.e.
such a request should be failed by the LIC, with an indication that the
device needs to be varied-off and then varied-on before the device can
be
utilized, because the LIC\TA feature knows that they previously and
purposely had marked the device as damaged to diagnose the prior
failure.
However, that could be manifest as merely a diagnostic message vs an
exception; that is how the database handles /partial/ damage to the
data,
such that access to the data is allowed, but a diagnostic is issued upon
open, so if\when the actual damage is encountered for which an actual
failure transpires, then there exists a logged indication that the
condition was known previously. Even other tape methods, those
implementing Initialize Tape (INZTAP), Clear Tape (CLRTAP), or Duplicate
Tape (DUPTAP) [esp. as target], or Display Tape (DSPTAP) best might
similarly log the condition, because the /recovery/ has not been
performed
[for which the damaged status should persist]; the LIC Tape feature
should
not be implicitly /recovering/ from a prior damage-set condition simply
due
to the next /use/ of the device. Any implicit recovery from the damage
vitiates the intention of originally having set the damage-condition.

Only way I have seen is to do GO SAVE, wait over an hour and ten get
the damaged message.


I believe that is conflating the effect-as-damage [damage-set as
effect
of the failing save] with the condition of previously-set damage.

As I recall, the Display Object Description (DSPOBJD) [using the
DETAIL(*BASIC) invocation] will show in the place of the Text, the value
*DAMAGED for either full\hard or partial\soft damage. The condition of
/partial damage/ for a device will be corrected by a vary-off\vary-on
cycle; however to best ensure a full recovery, the vary-on portion of
that
cycling should request the IOP Reset (RESET) option [with specification
RESET(*YES)], effectively asking to /IPL/ the [IOP for the attached]
device.

If I save the configuration source, vary off the device and then
delete it, then recreate from source - will THAT fix what is ailing?


I do not expect that to be any more fruitful than the IOP reset; and
IMO
unlikely to be any better served, by allowing the tape device to
re-create
using the auto-configuration capability. I suspect the device is
configured properly, but the conditions\environment for the save are
such
that the software is failing to effect the save to that properly
operating
device. If the interaction between the software and the IOP are in
error,
then likely the issue is firmware in the device, for which [as I
understand], neither the IOP reset nor the re-create of the device will
be
of any help -- and as I recall, the hardware [which should include
firmware] support was already done.


I get to wait until next Wednesday to try a save again.

I don't have a problem with recreating the DEVD, even manually. But,
I sure would like to be able to see if the ruddy thing was damaged
before an hour has passed.


I fully expect the issue is a software failure manifest visibly as a
device failure\damage-set, an effect that is by design. And that only
by
either applying a preventive PTF or modifying whatever about the saved
data
is leading to the failure, will there be any relief.

The former may be impossible given there may not exist such a PTF and
there may be no service\support forthcoming for the /unsupported/
release.

The latter may be difficult to effect, aside from some action that
[e.g.
deleting some objects; perhaps just enough objects to] prevent reaching
the
requirement of the save processing to place data on a volume that spans
tapes. While I do not suspect the tape change is _the_ issue, solely
[and
I recall testing other saves verified a volume spanning tapes was
verified
to function without error], I concur with the allusions that the failure
[probably had not and] probably will not transpire if whatever currently
is
spanning tapes does no longer happen to require spanning [and perhaps
specifically, that particular volume].

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