Re: Failed GO SAVE 21

On 24-Sep-2015 08:47 -0600, John McKee wrote:

Yesterday was the fourth week in a row that Go SAVE 21 failed. But,
very differently.

<<SNIP>>

Before the next GO SAVE Opt21, please issue the following two CL requests as the presumed circumvention of [the means to bypass] the failure:

CHGATR '/tmp/brms/flightrec' *ALWSAV *NO
CHGATR '/tmp/brms/flightrec.bku' *ALWSAV *NO

I am confident I have confirmed [by review of the data offered]. that this most recent incident was by exactly the same issue origin, and with the same object [address]. Presumably the difference between this and the past incidents is essentially that this error was fully manifest prior to the inquiry being sent; that in both past and present, the actual error occurs before the inquiry is sent, but when the error is manifest only after the G-Go on the inquiry, then there is just less spooled data for lack of FFDC. The reduced storage in the SAVLIB processing [note: an updated noted some *LIB objects were deleted, thus reducing total storage taken on media prior to start of SAV processing] likely caused the timing to be sufficiently different to change the effects; because the inquiry is not yet sent, the FFDC is in effect, and the save terminates, with the exception of the lack of the inquiry messaging, identically.

Instead of something like the following [with the detection of the /problem/ by Tape Volume Open occurring _after_ the change-tape inquiry, and the response being to terminate processing]:

,->QMHDSMSS->,
QTAFEOV->QTAEOV->QTAERR->' "cpa4088" '->QTAVOPEN->dmg

The result is something like the following [with the detection of the /problem/ by Tape Volume Open occurring _prior_ to the change-tape inquiry, and the response being to call the tape-dump-device API as FFDC]:

QTAFEOV->QTAEOV->QTAVOPEN->QTAERR->QTADMPDV

Because the BRMS flight recording feature might want to /switch/ from the active flight-recorder file to the backup flight-recorder file, during mid-save, be sure to change the Allow Save (*ALWSAV) attribute to *NO for both the /tmp/brms/flightrec and the /tmp/brms/flightrec.bku files. By ensuring that both these files are excluded from the SAV processing, any attempt by the BRMS flight recording to perform whatever work against those files can not conflict with the SAV, because the files are not being [concurrently] saved. Because either or both files may be re-created during any save, I suggest performing the same two Change Attribute requests to turn off the Allow Save attribute before each SAV, or ensure that those files still have that attribute\setting prior to any SAV. Modifying the SAV to OMIT all of the /tmp [¿or perhaps the same CHGATR for that top-level directory?] would be a preferable alternative.? The other options of disabling or removing BRMS and\or MSE [though more Draconian] should also serve to prevent the issue, because those should stop BRMS from [calling the Tape Exit to effect] writing to their flight recorder file(s) while a non-BRMS save is active.?