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

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ldh67k$42n$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>> VAXman- @SendSpamHere.ORG wrote:
>>> In article <ldglia$3us$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>>>> {...snip...}
>>>>> This particular piece of C has some inner mode code.  I'm extra careful with
>>>>> that using C; however, I'm not so certain I'd want to be jumping into kernel
>>>>> mode with BASIC.
>>>>>
>>>> After thinking about this for a while, I must confess to curiosity.
>>>>
>>>> I'm assuming that by "inner mode" that you're talking about kernel mode. 
>>>>  If not, then ignore the rest of this.
>>> Correct.
>>>
>>>
>>>
>>>> I've dabbled a bit at exec mode, mainly to allow some RTL code to use 
>>> I've *MORE* than dabbled in recent months/years. ;)
>>>
>>>
>>>
>>>> SYSLCK when the user didn't have that priv.  But I've never had the need 
>>>> to run anything in kernel made.
>>>>
>>>> What would you be doing that would require running in kernel mode?  I'm 
>>>> assuming that you're working on some type of application, and not 
>>>> modifying something in VMS.
>>>>
>>>> Rather curious ....
>>> Well, remember, you asked...
>> Yeah, even after many lessons about the dangers of doing so ..
>>
>>> http://www.attunity.com/products/attunity-cdc/rms-change-data-capture
>>> http://www.attunity.com/products/attunity-cdc-ssis/rms-cdc-for-ssis
>>> http://www.attunity.com/learning/video/attunity-rms-cdc-only-rms-solution-its-kind
>>> http://www.enterpriseirregulars.com/25555/attunity-scores-a-win-with-rms-cdc-support/
>>> http://www.attunity.com/news/attunity-announces-million-dollar-license-agreement-leading-communications-and-media-provider
>>>
>>> I've been working with Hein van den Heuvel, who is now an Attunity employee,
>>> since about 2009 when this project was conceived.  There's not too much that
>>> I don't know now about the inner workings of RMS as a result of this project.
>>> It's been one of the most interesting and challenging VMS hacking projects I
>>> have ever done.
>> That's some real interesting, and timely, information.
>>
>> Timely, because of 2 possible tasks coming up.
>>
>> 1) Journaling or logging of all data updates, with the capability of 
>> rebuilding the updates from a static backup and the journals.
>>
>> 2) In the event a port away from VMS must be done, a method to have 
>> duplicate real time copies of the data, one in the current DAS data 
>> files, and another in one of the free / open database products.  This 
>> would allow porting in small pieces while the applications continued to 
>> be used, and updated.
>>
>> Looks like others have faced similar problems.
>>
>> But to get back on subject, while my RMS experience was years ago, and 
>> it wasn't really deep into the internals, I'm wondering how you 
>> intercept the updates?  Are you talking data field granularity, data 
>> record granularity, or other?  For what I'm considering, I'm thinking to 
>> modify the database access code.  Don't know whether you're looking to 
>> make modifications to RMS, or something else.
> 
> Any RMS service which has the potential of modifying data is intercepted.  
> Services such as $CREATE, $PUT, $DELETE, $UPDATE are of interest.  THere's
> no need to bother with things like $GET.  What is captured is the data, the
> entire record if you will, passed to the RMS service.  In the case of the
> $DELETE, the "before image" is captured; that's the content of the record
> removed.  Also, and it's optional and depends upon the application, $UPDATE
> can also provide the "before image" prior to the new "updated" data.  The
> fun comes in with locking, synchronizing and obtaining the "before image" 
> data.

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.

Then there is writing new data.  And global buffers.  My, you really 
have gotten yourself into a quagmire.

:-)

> 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.
> 
> 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.

Looking at it positively, it's all my code, and I can change it.