×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 02-Sep-2015 13:15 -0600, John McKee wrote:
I >think< I accomplished the IOP reset when I responded to Chuck's
email.
<<SNIP>>
I am also wondering if the message requesting the drive be cleaned,
is the only >real< issue,
Doubtful the cleaning issue gave rise to later difficulties. I
suspect how the save progresses, across what is being saved, is more
likely at issue; much like I described as possibly analogous, that ever
since bad data gets added as row-data, an application that reads that
row-data will begin to falter by showing symptoms and exhibiting a
failure never seen prior to the introduction of the bad data.
and merely vary off/on, while appearing to correct the problem, as
evidenced by status changed from FAILED to ON did not actually
correct the underlying issue that the reset(*YES) may have. I am not
wanting to run from applying PTFs, but wonder if all that was wrong
was underlying condition was not fully corrected and now is.
My recollection is that the device will be marked as /damaged/
[soft\partial, aka logical] as an effect of whatever was the failure,
just as diagnosed by the msg CPI5922 "Vary the device off and then on
(WRKCFGSTS command). ... A machine interface instruction has failed to
complete causing device description &25 to become partially damaged.
...", and thus remained unusable until the device went through that
vary-off and vary-on cycle. I seriously doubt a warning\condition about
cleaning should not muck up the device to the point that the LIC TApe
feature would mark the device as damaged.
Yet if the device vary-on was not performed *with* the RESET(*YES)
specified, then I suppose an underlying issue could persist with the
device, since some initial incident, but prior to the latest reset; that
is to suggest that indeed, the reset\IPL of the device *may be* all that
is necessary to bypass whatever is the current problem being
experienced. Bypass, at least until whatever recurs giving rise to the
requirement to reset the device; of course that recurrence could be the
undiagnosed problem currently being encountered. Thus if the RESET has
not been performed since the first [of now three] recently experienced
failures, then another attempt after the reset of the IOP is probably
worthwhile before attempting to apply PTFs as maintenance; esp. if an
alternate to the full-save has not been effected, because ideally the
full-save will be completed before attempting to apply maintenance.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.