[Info-vax] RMS and SSIO (again)

[Greg Tinkler]

Hi Hein

Always good to read your posts.

> You have been focussing on random updates. nice of database, irrelevant for typical usage today. 
My understanding it is to get Postgresql running well on VMS, hence the need to random access.

> I think the more important problem to solve is shared appends and eof handling ( tail -f )
I though this was fixed is the current VMS versions...
Do you have a good suggestion for checking/getting the estimated EOF for a file from a program?  If it is shared then it will only be a guess.  I have not tried but $PUT with a 0 len record, or refresh the FAB and use that info.

> > - change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC
> READ/WRITE does NOT use (RMS) buffers. The user provide record (UBF on read, RBF on write)
I known, but wouldn't it be good it READ/WRITE used the bucket/MBC buffers.

> > - change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA.
> The current RFA already has a (32bit) block and (16 bit) byte offset. 
> I suppose you could add RAC=RFA and make $READ/$WRITE use the RFA fields, not the BKT.
That would be good, combined with using the existing buffers.
Also we could extend the idea, the current RAB has
    union  {
        unsigned short int rab$w_rfa [3]; /* record's file address          */
        struct  {
            unsigned long int rab$l_rfa0;
            unsigned short int rab$w_rfa4;
            } ;
        } ;
    short int rabdef$$_fill_4;          /* (reserved - rms release 1 optimizes stores  */
Effectively making it a Quadword, so why not have RAB$Q_RFA or RAB$Q_BOFFSET
No change to the layout of the RAB.  We would need to flag this to RMS possibly by using ROP2 RAB$M_BOFFSET.
At lease from an API point of view RMS could support VERY large files.  And yes there would need to be other engineering changes but these could be rolled out in a phased way.  FAB will need to be fixed once GFS2 is available, so maybe FAB64$ with fab$l_alq -> fab$q_alq.

> > - fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data
> $FIND has to read the data into the rms process buffer also. 
> It just does not move it to a user provided record buffer - a minor step in the scheme of things. 
> The biggest special thing about $FIND vs $GET is that $FIND only impacts the current record, not the next. 
> That is useful for updates. A program could be doing GET GET GET (all next 'blobs') then see some special data and decide to need a FIND and UPDATE for a random record before doing the next GET to continue reading a sequence. I find using two rabs for that more clear, more robust. 

Yup, understand all that and agree, however I expected that $FIND would allow me to position the current record using RFA on a UDF file.  It does not.  It also means that creating pseudo record locks using $FIND probably will not work for the same reason.  But this would be very useful.

gt