RE: Saving a User Defined File System (UDFS) using BRMS -- MIDRANGE-L

To be clear: don't take my remarks as any indication of what IBM's concern
is. What I suggest here is a guess only, scientific though it may be.

Also, "commit" may have been a poor choice of words on my part. "Written"
might have been better.

Have you ever put a flash drive (or a floppy, back in the day) into a
winblows computer, written something to it, and then removed it before the
system had guaranteed the changes? This may be the kind of information we
are talking about saving here. With Win*, you would do a "safely remove
hardware." With i or unix, you would umount (unmount) the folder.
Especially if your files are small, I suspect the system may not commit them
right away (nor even any time soon, unless enticed to do so).

I would suggest finding out from your service provider what the IBM concern
is... go from there.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Every generation laughs at the old fashions but religiously follows the
new."
-- Henry David Thoreau

If that is the case, then since I'm just storing lots of small image
files, commit shouldn't be an issue and I should be ok ...

Thanx for that information ..

Kenneth
Kenneth E. Graap
http://www.linkedin.com/in/kennethgraap

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Dennis Lovelady
Sent: Monday, September 13, 2010 1:51 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Saving a User Defined File System (UDFS) using BRMS

I suspect that IBM's recommendation is based upon the fact that they
don't (or can't) guarantee the files of UDFS are committed to disk at
any given point in time. I think the key to determining if your
strategy is sound, is to find out *why* IBM makes such a recommendation.

If IBM's concern is based upon the possibility of uncommitted data,
then it seems you'd do well to unmount and remount the FS, which should
force changes to be committed, and then carry on with your present
strategy.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"People are usually more convinced by reasons they discovered
themselves than by those found by others."
-- Blaise Pascal

I have hundreds of thousands of small Bill Images (65k each) stored

in

the IFS on my V5R4M5 iSeries.

I use an UDFS to store these files on a separate ASP.

My save strategy is to save all of these stream files once a month
(Full Save)... A Cumulative save weekly... and an Incremental save
daily.

I suppose that in order to do this I would need to save the UDFS

while

it is mounted.

However, I keep seeing in InfoCenter, that a UDFS should be saved
after un-mounting it.

So in my implementation I guess IBM recommends I un-mount the UDFS

and

save it as /dev/QASP04/billimages.udfs instead of the directory it is
usually mounted over /PRDSCIS/BILLIMAGE.

My concern with doing this is that I would loose the ability to do
Incremental saves and I wouldn't have any information in the BRMS
database, about the files and directories I have saved to tape.

Do you think my save strategy as outlined above (keeping the UDFS
mounted) is sound?

Do I have to do anything special to restore these files (except

create

the UDFS and mount it) when I do a DR test or other recovery?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.