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

Hi Mark

Yes, these "PC" attributes are in a group by themselves. Margaret explains that the IFS merges (or some such) the characteristics of several kinds of file systems - native IBM i security, POSIX, and PC, at least. Her presentation in the IFS Bootcamp was very helpful.

I am glad you ran the experiment, that message is really interesting. I continue to agree on limiting people who are *ALLOBJ.

Another thing I've never tried is the checkout/checkin stuff on the IFS - this is another PC or Windows thing - Margaret gives an excellent explanation - there are things that can only be done with a checked-out object by the one who checked it out. Another Windows thing. I wonder if you get a message for that which tells you what to do!


On 4/3/2024 7:42 PM, Mark Waterbury wrote:
Hi, Vern,

Thanks for the "heads up" about this.  I have never heard of a *READONLY attribute before.  It is something completely separate from the usual object authorities and data authorities.

I just ran a test at V7R3, creating a directory:

    MKDIR '/home/MSW/test'

Then changed it to add that *READONLY attribute:

     CHGATR OBJ('/home/MSW/test') ATR(*READONLY) VALUE(*yes)

Then I signed off and signed-on with a profile that has *ALLOBJ and I tried this:
    RMVDIR '/home/MSW/test'

And, I get this message:

                         Additional Message Information
 Message ID . . . . . . :   CPFA1C5       Severity . . . . . . . :   40
 Message type . . . . . :   Diagnostic
 Date sent  . . . . . . :   04/03/24      Time sent  . . . . . . :   20:28:42
 Message . . . . :   Object is a read only object.  Object is /home/msw/test.
 Cause . . . . . :   An operation was requested on read only object
   /home/msw/test that is not allowed on a read only object.
 Recovery  . . . :   Attempt to change the object's read only attribute, using
   the Change Attributes (CHGATR) command or Set Attributes (Qp0lSetAttr) API,
   and then try the request again.  If the object name is *N, it could not be
   determined which object was read only. Refer to any previously issued
 Press Enter to continue.
 F3=Exit   F6=Print   F9=Display message details
 F10=Display messages in job log   F12=Cancel
But, they told me what to do, right there in the message seen above.  :-/

So, since I have *ALLOBJ, I just issued this:

     CHGATR OBJ('/home/MSW/test') ATR(*READONLY) VALUE(*no)

 and it says:

    Attributes changed for 1 objects.  0 objects not changed.

And so now, I issue:

   RMDIR '/home/MSW/test'

and it says:

    Directory removed.

"A.N..D.... IT'S GONE!"

So, I think I stand by my advice regarding *ALLOBJ.   :-)

All the best,

Mark S. Waterbury

On Wednesday, April 3, 2024 at 06:37:56 PM EDT, VERNON HAMBERG Owner via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Hi Justin and all

I wondered about the *ALLOBJ bit here, so am watching Margaret Fenlon's COMMON presentation on IFS security. She says that the *READONLY attribute prevents writing or deleting the object, and *ALLOBJ cannot override this attribute. She underlined "or deleting".

Anyone who is a COMMON member can view the presentations in the IFS Bootcamp - of course, Mark, your good counsel to limit number of users with *ALLOBJ is absolutely valid.

On Wed, 3 Apr, 2024 at 4:07 PM, Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx> wrote:

To: midrange systems technical discussion

Any user with *ALLOBJ can always delete your precious directory, no matter what you do.
"*ALLOBJ" means "all objects" -- including IFS (*STMFs and directories).
This is why it is important to limit the number of user profiles with *ALLOBJ.
Just saying.
Mark S. Waterbury

  On Wednesday, April 3, 2024 at 02:35:21 PM EDT, Justin Taylor <jtaylor.0ab@xxxxxxxxx<mailto:jtaylor.0ab@xxxxxxxxx>> wrote:

My goal is to make a directory that can't be deleted.  *READONLY works OK
when I tested it, but I just wanted a sanity check.


date: Tue, 2 Apr 2024 13:56:24 -0400
from: Rob Berendt <robertowenberendt@xxxxxxxxx<mailto:robertowenberendt@xxxxxxxxx>>
subject: Re: Read-only dir & files within?

I do not find any documentation on this.  However this testing may answer
MD DIR('/home/ROB/JT')
  Directory created.
  Attributes changed for 1 objects.  0 objects not changed.
EDTF STMF('/home/ROB/JT/test.txt')
The EDTF did create the file
DSPF STMF('/home/ROB/JT/test.txt')
The DSPF showed the changes.

There is an attribute called *RSTDRNMUNL you might want to read up on.

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.