RE: V5R3 IFS Bug?? -- MIDRANGE-L

Mark:

Sorry for late response... got a couple days off. First thing I missed until 
reading your latest was "...it has NEVER worked this way before". Getting to 
the point:

And it isn't any different in V5R3, AFAIK.

That is, if you're seeing a difference, there seems to be something wrong on 
your system. I see no difference between V5R1 and V5R3 on the systems available 
to me today. I also see no PTFs that seem to cover this problem when I search 
with "sav", "archive", "netsvr" and similar search items.

*IF* there are no clearly specific PTFs, then I'd start looking at general IFS 
and perhaps NetServer PTFs. It may be that some IFS PTF has fixed attribute 
handling because it fixed something else that's required for attributes to work 
correctly. We might have PTFs that you don't, or you might have a later PTF 
that broke something.

I looked at your question originally from the wrong direction. I got the 
mistaken impression that you were saying V5R3 handled it wrong, but it handles 
it correctly from my viewpoint. But you were instead saying that your system 
handles it wrong and that's apparently true.

If I go into my Win2K PC and change the PC archive bit, I can see it change 
through the green-screen on V5R3 from Yes to No or the other way if I change it 
back. And if I run CHGATR through the green-screen on V5R3, it changes on my PC 
if I view the properties.

Also, the *SYSARCHIVE bit is not available through /QNTC since it's an OS/400 
IFS attribute, therefore it defaults to No I suppose. And if I run a 
green-screen CPY command to copy out of /QNTC into my /home directory, the bit 
is then shown as Yes on the new file. Exactly as on older releases.

The archive bit does override SAV. That is, telling your system to SAV a 
directory doesn't result in a saved file if the *SYSARCHIVE bit is No, AFAIK. 
But the bit shouldn't be No by default on the new file after a CPY.

This does indeed seem to be a bug on your system. Others might want to check 
their systems as well.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   4. RE: V5R3 IFS Bug?? (Mark Phippard)
>
>midrange-l-bounces@xxxxxxxxxxxx wrote on 12/12/2004 01:24:53 PM:
>>
>> With the original thread in mind, it seems to me that there is no easy
>> answer when things are being copied across different file systems. While
>I
>> agree that the behaviour is inconvenient, I think I would have to go
>along
>> with the reasoning that the original attributes should be preserved in a
>
>> copy operation where such attributes are supported by the file system.
>
>Except these are NOT REAL ATTRIBUTES.  There is no attribute stored with
>the file that says whether it can be saved, at least when the file is not
>stored in the IFS.  IBM is making this attribute up as a way to indicate
>that they will not save files stored on a Windows system.  You cannot use
>the CHGATR command to change the attribute while the file is stored on a
>Windows system.  The command just fails and says operation not supported.
>
>Also, if you start by creating a file in the IFS and then copy it to QNTC,
>it DOES LOSE these attributes.  So the argument does not hold water in
>either direction.
>
>Finally, QNTC has been around since V4R2 and it has NEVER worked this way
>before.

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com



__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp