× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Mark:

Ah! Totally new attribute! Now I'm awake.

No mention in V5R3 Memo to Users. No >>change<< marks in the CHGATR command. But the Qp0lSetAttr()/Qp0lGetAttr() APIs do have brief mentions of it -- brief enough that any relationship to the /QNTC file system is left out. Very useful documentation. (NOT!) Good thing the APIs are marked but the command isn't, since I'm sure the APIs are what's commonly used. <g>

Yes, kind of makes you wonder what the point of *SYSARCHIVE is now. The need for a new attribute seems unclear to say the least.

Thanks for pointing this out. The few notes about how this relates to saving/restoring related private authorities only serve to make it more curious.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

  9. RE: V5R3 IFS Bug?? (Mark Phippard)

midrange-l-bounces@xxxxxxxxxxxx wrote on 12/14/2004 11:02:48 PM:

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.

You probably jumped in late, because you missed stuff.

1) I am not talking about the archive bit. This is a new V5R3-specific flag called *ALWSAV on the CHGATR command.

2) I am not the only one experiencing this, it came to me from my customers.

3) All QNTC objects have this value set to *NO automatically, and it is not possible to change it with CHGATR. If you try, you get CPFA0AD - Function not supported by file system.

The issue is that this is essentially a "fake" attribute and when you copy/move an object from QNTC up to the IFS it brings the fake attribute with it (it is likely a real attribute in the IFS). If you were to create a new object in the IFS, the default would be *YES, I think that copying objects from QNTC to the IFS should do the same.

Finally, as I said, if you were to create a new object in the IFS with this attribute set to *YES. Then move the object to QNTC, and then move it back to the IFS, the attribute changes to *NO. In my opinion, that is a good example of the general underlying problem.

-- 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.