Discussion:
RDB, trigger, native procedure and ActiveMQ
Add Reply
Arne Vajhøj
2021-05-30 23:47:32 UTC
Reply
Permalink
Rdb features have been discussed here a few times and
some time ago I read a bit in the Rdb manual and found
the section on native procedure.

And since I like playing around with such stuff I
created a little demo.

Setup:

Rdb table -> insert trigger -> procedure written in C -> STOMP library
-> message queue on ActiveMQ

That means that when some application (residing on VMS or
elsewhere) insert data in that table, then another
application (residing on VMS or elsewhere) get
notified in near real time.

C snippet:

void stomp_send(struct dsc$descriptor *host,
int port,
struct dsc$descriptor *dest,
struct dsc$descriptor *data)
{
char host2[256];
char dest2[256];
char data2[256];
simple_stomp_t ctx;
desc2buf(host, host2);
desc2buf(dest, dest2);
desc2buf(data, data2);
simple_stomp_debug(0);
simple_stomp_init(&ctx, host2, port, print);
simple_stomp_write(&ctx, dest2, data2);
simple_stomp_close(&ctx);
}

Define procedure in Rdb:

CREATE PROCEDURE stomp_send(IN VARCHAR(255) BY DESCRIPTOR,
IN INTEGER BY VALUE,
IN VARCHAR(255) BY DESCRIPTOR,
IN VARCHAR(255) BY DESCRIPTOR);
EXTERNAL NAME stomp_send LOCATION 'disk2:[arne.dbmq]cproc.exe'
LANGUAGE GENERAL PARAMETER STYLE GENERAL
BIND ON SERVER SITE;

Insert trigger:

CREATE TRIGGER t1insert
AFTER INSERT ON t1
(CALL stomp_send('arnepc4', 61613, '/queue/t1insert', CAST(t1.f1 AS
VARCHAR(10)))) FOR EACH ROW;

Tested with 3 database clients:
* Cobol on VMS
* Java on PC
* C# on PC
and 1 message queue client:
* Python on VMS

It works.

More details and complete code available at:
https://www.vajhoej.dk/arne/articles/vmstd1.html

Arne
Jan-Erik Söderholm
2021-05-31 10:36:18 UTC
Reply
Permalink
Post by Arne Vajhøj
Rdb features have been discussed here a few times and
some time ago I read a bit in the Rdb manual and found
the section on native procedure.
And since I like playing around with such stuff I
created a little demo.
Rdb table -> insert trigger -> procedure written in C -> STOMP library ->
message queue on ActiveMQ
That means that when some application (residing on VMS or
elsewhere) insert data in that table, then another
application (residing on VMS or elsewhere) get
notified in near real time.
void stomp_send(struct dsc$descriptor *host,
                int port,
                struct dsc$descriptor *dest,
                struct dsc$descriptor *data)
{
    char host2[256];
    char dest2[256];
    char data2[256];
    simple_stomp_t ctx;
    desc2buf(host, host2);
    desc2buf(dest, dest2);
    desc2buf(data, data2);
    simple_stomp_debug(0);
    simple_stomp_init(&ctx, host2, port, print);
    simple_stomp_write(&ctx, dest2, data2);
    simple_stomp_close(&ctx);
}
CREATE PROCEDURE stomp_send(IN VARCHAR(255) BY DESCRIPTOR,
                            IN INTEGER BY VALUE,
                            IN VARCHAR(255) BY DESCRIPTOR,
                            IN VARCHAR(255) BY DESCRIPTOR);
EXTERNAL NAME stomp_send LOCATION 'disk2:[arne.dbmq]cproc.exe'
LANGUAGE GENERAL PARAMETER STYLE GENERAL
BIND ON SERVER SITE;
CREATE TRIGGER t1insert
AFTER INSERT ON t1
(CALL stomp_send('arnepc4', 61613, '/queue/t1insert', CAST(t1.f1 AS
VARCHAR(10)))) FOR EACH ROW;
* Cobol on VMS
* Java on PC
* C# on PC
* Python on VMS
It works.
    https://www.vajhoej.dk/arne/articles/vmstd1.html
Arne
Was it the "database clients" that did the table insert?
If so, it would work from any source, it doesn't matter *how* the
record was inserted into the table, the trigger would fire anyway.
Arne Vajhøj
2021-05-31 19:49:10 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Rdb features have been discussed here a few times and
some time ago I read a bit in the Rdb manual and found
the section on native procedure.
And since I like playing around with such stuff I
created a little demo.
Rdb table -> insert trigger -> procedure written in C -> STOMP library
-> message queue on ActiveMQ
Was it the "database clients" that did the table insert?
Yes.
Post by Jan-Erik Söderholm
If so, it would work from any source, it doesn't matter *how* the
record was inserted into the table, the trigger would fire anyway.
Yes.

That is the whole point. Any program can insert the data and
trigger the send to message queue. And any program can read
from the message queue and take action.

Arne
Jan-Erik Söderholm
2021-05-31 22:10:07 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Rdb features have been discussed here a few times and
some time ago I read a bit in the Rdb manual and found
the section on native procedure.
And since I like playing around with such stuff I
created a little demo.
Rdb table -> insert trigger -> procedure written in C -> STOMP library
-> message queue on ActiveMQ
Was it the "database clients" that did the table insert?
Yes.
Post by Jan-Erik Söderholm
If so, it would work from any source, it doesn't matter *how* the
record was inserted into the table, the trigger would fire anyway.
Yes.
That is the whole point. Any program can insert the data and
trigger the send to message queue. And any program can read
from the message queue and take action.
Arne
OK, fine... :-)
But then I do not see the point in listing three "database clients".
It is simply not relevant.
Arne Vajhøj
2021-05-31 23:17:48 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Rdb features have been discussed here a few times and
some time ago I read a bit in the Rdb manual and found
the section on native procedure.
And since I like playing around with such stuff I
created a little demo.
Rdb table -> insert trigger -> procedure written in C -> STOMP
library -> message queue on ActiveMQ
Was it the "database clients" that did the table insert?
Yes.
Post by Jan-Erik Söderholm
If so, it would work from any source, it doesn't matter *how* the
record was inserted into the table, the trigger would fire anyway.
Yes.
That is the whole point. Any program can insert the data and
trigger the send to message queue. And any program can read
from the message queue and take action.
OK, fine... :-)
But then I do not see the point in listing three "database clients".
It is simply not relevant.
I could have picked any number of database clients and picked
any database clients. I picked those 3 as being illustrative
because they are so different.

There is a point in having multiple database clients. If there were
only one and that application was one that could be modified, then
that application could have send to the message queue instead
of relying on the database to send to the message queue.

Arne

Loading...