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]?


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

This thread ...


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