Some history will help you to understand. When SFS came out with VM/SP R6:
- ACCESS was simple: your own filespace was always R/W, other spaces R/O; FORCERW/FORCERO did NOT exist
- only two 'classic' commands (COPYFILE and XEDIT) were able to 'update' files in filespaces other than your own, they didn't check if a dirid was accessed RW or RO, only the authority on the file was checked.
- Two other 'classic' commands (RENAME and ERASE) accepted a dirid in the parameters, what allowed them to work on any filespace. When a "fm" is in the input parameters, they look at the accessmode, else at the authority on the file.
With the arrival of the FORCERO/FORCERW options for ACCESS, people started expecting that COPYFILE and XEDIT would refuse to update files in R/O accessed dirids. So later the SET RORESPECT command was born. But, the default remained like in the VM/SP R6 days, the rules of upward compatibility are respected.
Kris,
IBM Belgium, VM customer support
| "Edward M. Martin"
<[EMAIL PROTECTED]>
Sent by: VM/ESA and z/VM Discussions <[email protected]> 2005-12-23 20:25
|
|
Hello Everyone,
Just notice something on the SFS system.
I access a SFF as r/o
acc uquest.support b
DMSACR723I B (VMSYSU:UQUEST.SUPPORT) R/O
Ready; T=0.01/0.01 14:22:36
And I can not delete stuff, which makes sense.
But I can copy the member and pack it.
Copy UXACC0 ASSER85 B1 = = = (pack
Is this right?
Ed Martin
Aultman Health Foundation
330-363-5050
[EMAIL PROTECTED]
