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
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 fully expect the issue is a software failure manifest visibly as a
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.
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].
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives