Re: Failed GO SAVE 21

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.