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

[David Froble]

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.

> STR$CONCAT was used for a recent "new feature" request.  The control utility
> is written in C.  Not my choice but...  The rest of the code is pure OpenVMS
> internals magic written in Macro32 with bits of Macro64 or Itanium Assembler.
> 
> 
> 
>> My understanding, and it's vague, is that you'd never want to invoke any 
>> code that might throw an error while running in kernel mode.  As Steve 
>> mentioned elsewhere, that leaves out any of the language modules, RTL 
>> modules, and such.  I'd think that that would also exclude STR$CONCAT 
>> and such.
> 
> Well, you could call many of those functions assuming you use their "object"
> brethren.  (see: LINK/[NO]SYSSHR).  However, I'm invoking STR$CONCAT at user
> mode in the control utility for Attunity RMS CDC.  While this does jump into
> kernel mode to perform some interface tasks, it's NOT calling ST$CONCAT (or
> any of the other RTLs of its ilk) when in kernel mode!
> 
>