[Info-vax] Still no DIR/SORT_BY_TIME

[David Froble]

Johnny Billquist wrote:
> 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
> 

Ah, I do believe I was referring to RSTS/E only.  And, I haven't used it since 
1978, so I could mis-remember some things.

You also mention RMS.  I don't think that's the only option on either RSTS/E or 
RSX.  Note, never used RSX.

I also have some considerable experience with locking ....