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].
midrange.com
