RE: V5R3 IFS Bug??

Mark,

Perhaps they are just trying to maintain "transparency", i.e. if you copy a 
file from QNTC to root file system and then back to QNTC, it should have the 
same attributes that it did originally. A copy operation should make an exact 
copy. I should get the same thing out that I put in. (assuming this works in 
both cases, attribute set and unset)

On the other hand, the QNTC object does not really exist on my system and I 
don't necessarily want to back it up. Presumably that is the reason for the 
attribute in question. When I make a local copy of the object, it does exist on 
my system so now I  most likely do want to back it up.

I can see validity in both philosophies.

-Marty

------------------------------

date: Wed, 8 Dec 2004 09:37:05 -0500
from: Mark Phippard <MarkP@xxxxxxxxxxxxxxx>
subject: V5R3 IFS Bug??

Tell me if you think this is a bug.

In V5R3 there is an attribute you can see and set on IFS objects that 
controls whether an object can be saved.  Use DSPATR on a file and you can 
see this.  By default, QNTC objects all have this attribute set and I 
imagine there are good reasons for it.  However, if you use the CPY 
command to copy the objects from a QNTC path into the IFS, then the object 
retains that setting and cannot be saved.  You can change the settting by 
running the CHGATR command, but I believe that just copying the object 
into the IFS should do this automatically and that this is a bug.

It seems like this would have the potential to really burn someone. 
Imagine someone copying a Domino database this way as an example and not 
knowing that the file is not being saved on their iSeries.

Anyone have any thoughts?

Mark