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,
*SHRNUP, *EXCL.
Use the open() API with O_SHARE_NONE, and then do not close() the
file until after the SAV request with the *ALWCKPWRT option.
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/open.htm>
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/close.htm>
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
object?
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.
midrange.com
