[Info-vax] C... the only winning move is not to play...

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ldir57$54k$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>> {...snip...}
>> Yep!  If you were able to know what updates were going to come along 
>> before they did so, you'd probably own Atlantic City, Vegas, the NY 
>> stock exchange, and such, at least until someone else discovered your 
>> secret.  I'm not greedy, I'd settle for one PowerBall win ....
>>
>> :-)
>>
>> My dim recollections are that there are 2 methods for obtaining RMS 
>> record data, the "move mode" where data is moved to and from some static 
>> buffer, such as a MAP in Basic, and then another method that I don't 
>> believe I've ever used, and forget the terminology.
>>
>> So, for the move mode, if you're intercepting the procedure before the 
>> data record is moved back to the I/O buffer, then I'd think that you'd 
>> have the "before image" still in the I/O buffer.  It should still be 
>> valid, since it would have a lock, else updating would not occur.
> 
> If you were to predicate this upon what the user passes in their FAB/RAB, to
> use you AC and Vegas metaphor, you're going to wind up a sorry loser!

Not sure what you're saying about FAB and RAB.

> I'm not going to disclose here how I get the "before image" but I assure you
> it's not stale data in the user's buffers.  If you'd really want to know how
> it's done, an NDA will need to be signed.

What I meant was the data is read into an internal I/O buffer, and the 
desired data record is then moved into a user's pre-defined record 
buffer.  In a write of the data record, RMS moves it back into the 
internal I/O buffer, then writes the I/O buffer.

If the data in the I/O buffer is locked, then is should not be stale.

However, I think I've already mentioned that it's been years since I did 
anything with RMS, and even then I wasn't deep into the internals, so 
the above is old conjecture.

I wasn't asking how you got the "before image", and respect your 
intellectual secrets.


>> Then there is writing new data.  And global buffers.  My, you really 
>> have gotten yourself into a quagmire.
> 
> Global buffers, believe it or not, are not treated any differently than the
> local buffers.

Yeah, after I wrote that, I began to suspect that they might be the 
same, or even easier than private I/O buffers.

>>> When initially scoped out, the idea was to simply intercept the RMS service
>>> and copy the data from the FAB or RAB but that's not the *right* way to do
>>> it.  I won't go into detail here for a number of reasons.  I did, however, 
>>> do a rather detailed expose' on the inner working at two OpenVMS Bootcamps.

This is what I fail to understand.  As far as I know, neither the FAB 
nor the RAB have any actual data in them.  They surely have some 
pointers that could be helpful, but no data.

Starting to wish I had been at those bootcamps ....

>>> Seriously, if you do see a use/need for this, contact Attunity.  I'm sure
>>> Hein would be happy to discuss the application of RMS CDC with you.  I can
>>> then answer specific questions for you if needed.
>>>
>> I doubt they would have anything that would help me, as DAS has nothing 
>> to do with RMS, well, once again I'm wrong, it uses the filename parser 
>> in RMS, but nothing else.
> 
> DAS???
> 

DAS is a Database Access System supporting indexed (ISAM) and relative 
files.  I implemented it in 1984, based on prior work at a previous job. 
  It consists of shared code for access, and some utilities for various 
file maintenance.  I/O is at the QIO level, and the DLM is used for locking.

It had been used by multiple customers, but now only by Consolidated 
Data in Codis, the others having been assimilated by the Borg.

It was a good product in 1984.  Having seen what's available in various 
RDBMS systems, it really isn't a good product in 2014.