RE: V5R3 IFS Bug??

That really isn't the case here.

1)  You cannot use the CHGATR command on an object in QNTC and change the 
"Allow Save" value to Yes.  The system automatically makes it No.  It 
isn't like it is a real attribute stored with the file.

2)  Reverse your scenario.  Create an object in the IFS, it will be 
eligible to be saved.  Now copy it to QNTC.  It will not be eligible to be 
saved.  Copy it back to IFS, it will not be eligible to be saved.

I think it is a bug.  I doubt there are a lot of people that use QNTC to 
copy stuff from a Windows server to the IFS, but if there are, I bet they 
will get burned by this.

Mark



midrange-l-bounces@xxxxxxxxxxxx wrote on 12/08/2004 11:01:15 AM:

> 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
> 
> --
> 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.
> 
> 
> 
_____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management 
> Services powered by MessageLabs. 
> 
_____________________________________________________________________________


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services 
powered by MessageLabs. 
_____________________________________________________________________________