On 30-Sep-2015 10:10 -0600, John McKee wrote:
On Wed, Sep 30, 2015 at 10:51 AM, Steinmetz, Paul wrote:

So are we stating that a non BRMS save still writes to the BRMS
flight recorders? This doesn't appear correct.

I looked at the flight recorder after the backup completed. There
are indeed records written to it.

Seems odd to me as well.

AIUI because MSE and BRMS are both installed, the Tape Exit gets invoked per the former, and the former is obliged to invoke the BRMS per the latter per having been registered as part of the installation. That holds, despite the operation against the tape possibly being non-BRMS. So essentially the BRMS is placed\registered-as in control of tape inventory [because those two features have been installed] and therefore BRMS is\must-be informed of the use of the tape device(s) [or MLB devices] wherever\whenever the Tape Exit runs.

Chuck had an initial suggestion to remove
BRMS and then reinstall. Likely would have worked.

The re-install after the save activity only to reset the system to the original configuration; i.e. prior to the next save, the delete\remove action again would be necessary as part of preventive. I believe I had noted, that given BRMS was not being utilized, seemingly the LPP could be removed entirely; though backed-up prior to DLTLICPGM, to allow a restore if\when deemed required, but restored from that backup so as not to require re-applying maintenance [because the PTFed product was saved\restored instead of the un-PTFed version of the LPP from media].

Changing the attribute on the flight recorder files to not save is
simpler and maybe safer.

Like the aforementioned disabling technique as [presumed] preventive would be required to be repeated for each full-system-save *if* the product were re-installed afterward, that [maybe] holds true for the technique with the FR files whereby the FR files might need to be modified prior to each full-system-save. That is, before each GO SAVE Opt-21, repeat the Change Attribute (CHGATR) request to set the *ALWSAV to *NO; or at least verify the AlwSav attribute\setting for each is still set to *NO. That ensures, at least prior to the system-save, that these files still existed with that attribute, despite possibly having been deleted\re-created by the BRMS in some previous activity. If the BRMS might delete and re-create the file, but not maintain that AlwSav=No attribute\setting, then the problem could recur, despite the attempt at preventive; I do not know how nor when the BRMS feature /switches/ between their _backup_ and primary FR files, and what effect that might have on the attributes of those files.

Begs the question if allow save is default on 5.4 or newer and was
changed, or if default was later changed. Or, if some PTF at any
level changed some behavior to prevent the lock condition from
causing the backup to fail.

I wonder(ed) the same. I thought I would have found a PTF that mentioned something if IBM had seen this problem [reported to them], or someone noting [in a blog or discussion somewhere] the CHGATR could be used as a presumed-preventive action; but I found nothing in searches of the web. I could ask a [former] developer from the product, but I have chosen not to bother any of them, especially for an inquiry about an unsupported release. I figure if any of them ever read\follow this list\NG, then they could respond themselves.

I wonder if instead of an explicit fix, the potential effect was at least partially mitigated by /tmp being marked as AlwSav=No in more recent releases? Or perhaps since some time, that /tmp/brms is getting created as AlwSav=No? I have no systems to check how /tmp is created upon installation [or at run-time, after deletion]; nor /tmp/brms or the individual files. I do know that the public v5r3 system that I use has both BRMS and MSE installed, and has AlwSav=Yes for all of /tmp, /tmp/brms/, /tmp/brms/flightrec, and /tmp/brms/flightrec.bku, so I suspect that system has the same potential for the issue. But again, the nuances of the layout of the saved data prior to SAV and similarly for the SAV itself, the identical [code levels of the] software can just as easily encounter the difficulty as not; all depends [so I infer] on the FR being included on the already-being-dumped descriptor and the Tape Exit then calling BRMS to write to the FR concurrent with the preparation of the next to-be-dumped descriptor. Seemingly that could explain why the problem could be[come] persistent\pervasive on a system though never seen prior, and that other systems may continue to never see the problem even while having the potential to encounter the issue.

Bad thing about this fix is that, if needed, flight recorder just
isn't going to be available to restore.

While the FR feature is for logging of the current moment and for the ability [for the dev mostly] to refer to past [BRMS] activity, the code performing future activity [such as more saves or restores] cares not [and in no way depends on], what was\is in the log files. Those files could be deleted, and the code should not care, simply effecting the creation on open\write; note: for this specific scenario however, deleting the files is *not* desirable, as they need to exist so the attribute can be set to AlwSav=No. That these files are not important to the feature for effecting any work [other than logging] should be somewhat conspicuous, given the files are stored in the /tmp directory, and that can be [and often is] cleared upon each IPL [on many systems]; and especially conspicuous, they definitely will not exist in any Disaster Recovery (DR) scenario [at least if\until the /tmp directory got restored, or probably in most cases where BRMS is in use, when the BRMS feature first ran and created them].

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.