[Info-vax] Still no DIR/SORT_BY_TIME

[Johnny Billquist]

On 2015-08-18 20:01, David Froble wrote:
> Simon Clubley wrote:
>> On 2015-08-16, Johnny Billquist <bqt at softjar.se> wrote:
>>> On 2015-08-16 20:05, Simon Clubley wrote:
>>>> RSTS/E DCL did this as well and you could still use PIP directly
>>>> if you needed to (/mode:4096 for example).
>>> Well, unless I remember wrong, it was/is not done the same way. Under
>>> RSTS/E, DCL would probably invoke PIP, with the command line massaged
>>> to accomplish the task.
>>> Under RSX, the command line is rewritten by the DCL CLI, and then
>>> passed to MCR to actually parse and execute it. So DCL do not invoke
>>> any programs, except MCR. And you can turn on debugging in DCL, which
>>> cause the command line DCL generates to be printed, but not executed.
>>> That way you can see what MCR line it translates to.
>>>
>>> Example:
>>> $ set debug
>>>
>>> $ dir /since:1-jan-2001
>>> PIP /DD:1-JAN-2001:*&/LI
>>> $
>>>
>>>> BTW, does RSX also have a read regardless mode ?
>>> Not sure what you mean by that. Maybe you can explain in more detail
>>> what you're asking, and then I can answer. :-)
>>>
>>
>> With RSTS/E, when opening a file, you could specify various options
>> using a mode field which was a bitfield encoded integer. Opening a file
>> with mode 4096 allowed you to open and read a file when you normally be
>> blocked due to an incompatible open mode from another currently running
>> program.
>
> Locking is ALWAYS a cooperative thing.  It's always possible to not
> conform to locking.  Just be careful when doing so.  Read only usually
> is safe.

Not so. Write locking is (in RSX) enforced by F11ACP, and is not left as 
an exercise to the programmer.
However, read locking is something RMS does without F11ACP enforing.
Same thing with block locking.

>> It's been a _long_ time since I last used it, but I think (IIRC) it
>> could even be used to see the current contents of a file which was
>> exclusively opened for writing by another program. (Assuming you had
>> suitable access rights to the file of course.)
>
> Well, since as far as I know, RSTS/E was definitely cache nothing, yes,
> if it's on the disk, you should be able to read it.

In RSX, it's not that simple. Various meta-data is not written out until 
explicitly requested from a program, so as well as local buffers in the 
program, various information, such as EOF position, is not visible to 
other programs just because one program have "written" it.

	Johnny