On 13-Aug-2014 16:19 -0500, Steinmetz, Paul wrote:
1) Response back from IBM, PMR is still open.

SAVBRM along with ALWCKPWRT was mainly created for saving Domino
while active.

Meaningless really, with regard to a more general discussion about SAV and backups for DR, with the ability to effect a SWA.

Domino also had save code changes, added, that if a item was missed,
it would be marked for the next save.

As might any application that allows its objects to be saved in that manner. The data inconsistencies may or may not be an issue for the application. Doubtful that log files not being complete\consistent in the backup, for example, would cause any problems post-recovery.

BRMS support recommends NOT to use SAVBRM and/or ALWCKPWRT, because
the status of the IFS save would be unknown.

The application owner and the B&R planners should be able make the decision about what is or is not acceptable for their situation. If the OS enables the feature, then why would the BRMS not also allow them to make their plan and then implement that plan using the BRMS instead of having to use the /native/ save\backup features instead?

Waiting on additional CPS from IFS group.

Seems to me that the issue is all about whether the BRM services feature supports what the OS\IFS has exposed to the SAV feature; whether and how the SAVBRM should expose the capabilities.?

2) I've done some experimenting/testing IFS saves with trying to
create various locks.
a) If you open an IFS object, 2=Edit, then check the object
via Ops Nav, the object shows a *SHRRD lock, not what I
expected, object can be saved without issue.
b) if you open an IFS object with notepad, Ops Nav shows
no locks, object can be saved without issue.

Stream file editors are quite typically a read-all during file->open and write-all during file->save; into and from memory, respectively. Thus they are unlikely to be able to produce an EBUSY [or ENOTAVAIL] condition for the save\backup activity.

3) How can I create an IFS lock higher then *SHRRD, either *SHRUPD,

Use the open() API with O_SHARE_NONE, and then do not close() the file until after the SAV request with the *ALWCKPWRT option.


Given a somewhat equivalent feature of the OS for /QSYS.LIB objects is the Allocate Object (ALCOBJ) command, perhaps searching the web for various potentially-named tooling might find a utility that /locks/ a stream file much like one can request to lock the data of a file.mbr object; e.g. ALCSTMF, ALCIFS, LCKIFS, LCKSTMF, ??

4) I'm leaning towards setting the ATR(*ALWSAV) to VALUE(*NO) for
IFS items with higher than a *SHRRD.
Prior to the IFS save, a CPY would be done for DR purposes.

Arguably the use of a copy (CPY) is similar to how B&R planning can make the decision about what is acceptable to an application, for how B&R is implemented. Why should the BRMS be suggesting that such a decision should not be made, and thus that their not providing support for *ALWCHKWRT is justified? Saying they would not enhance BRMS to allow you to make that decision is one thing; entirely different, and ridiculous IMO, to claim that your use of the feature should be prevented because BRMS does not think you should be trying to utilize that feature that might conflict with the proper function of your application(s) on the recovery-side.? I suppose they have a precedence for not having enabled a SAVCHGBRM for SAVCHGOBJ which has its own potential for problems with applications on the recovery-side; IIRC, they provide however, an incremental [*INCR] save capability.? But given they offer the SAVBRM already.?

5) Can an IFS object be jounrnaled?

Start Journal {Object} (STRJRN) command can start journaling of a stream file object.

If so, how would a BRMS *link save see a locked, journaled IFS

I have no idea; not being familiar enough with the feature, with or without the BRMS. Might the Journaled Objects (OBJJRN) play a role, whereby by default, journaled objects are omitted from the save because the expectation would be that the Apply Journaled Change (APYJRNCHG) would be performed on the back-end per having backed-up the Journal Receiver (*JRNRCV) objects.

This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page