I.1. Format of System-Dependent File Permissions in A-Packets The format of this field (the "," attribute) is interpreted according to the System ID ("." Attribute). For UNIX (System ID = U1), it's the familiar 3-digit octal number, the low-order 9 bits of the filemode: Owner, Group, World, e.g. 660 = read/write access for owner and group, none for world, recorded as a 3-digit octal string. For VMS (System ID = D7), it's a 4-digit hex string, representing the 16-bit file protection WGOS fields (World,Group,Owner,System), in that order (which is the reverse of how they're shown in a directory listing); in each field, Bit 0 = Read, 1 = Write, 2 = Execute, 3 = Delete. A bit value of 0 means permission is granted, 1 means permission is denied. Sample: r-01-00-^A/!FWERMIT.EXE'" s-01-00-^AE!Y/amd/watsun/w/fdc/new/wermit.exe.DV r-02-01-^A]"A."D7""B8#119980101 18:14:05!#8531&872960,$A20B-!7(#512@ #.Y s-02-01-^A%"Y.5! ^^^^^^ A VMS directory listing shows the file's protection as (E,RWED,RED,RE) which really means (S=E,O=RWED,G=RED,W=RE), which is reverse order from the internal storage, so (RE,RED,RWED,E). Now translate each letter to its corresponding bit: RE=0101, RED=1101, RWED=1111, E=0010 Now reverse the bits: RE=1010, RED=0010, RWED=0000, E=1101 This gives the 16-bit quantity: 1010001000001101 This is the internal representation of the VMS file permission; in hex: A20B as shown in the sample packet above. The VMS format probably would also apply to RSX or any other FILES-11 system. I.2. Handling of Generic Protection To be used when the two systems are different (and/or do not recognize or understand each other's local protection codes). First of all, the book is wrong. This should not be the World protection, but the Owner protection. The other fields should be set according to system defaults (e.g. UNIX umask, VMS default protection, etc), except that no non-Owner field should give more permissions than the Owner field. (End of CKCPLM.DOC)