Re: Calling RPGILE program from C -- C400-L

It is important to remember that the trigger mediator is a generic
function. The unique business logic is in the trigger service programs.

Here is my punch list of things the mediator had to do.

1. Single point of entrance for all triggers.
2. Fast. Introduce the minimum amount of delay in processing of record.
a. No program calls. Too slow.
b. No database I/O except to load tables. Should only occur once when
mediator loaded or when reload requested.
3. Database driven. All the associations between tables and trigger should
be defined in a table.
4. Program implementing business logic should not be locked nor the actual
tables.
5. Everything should be dynamic. You should be able to instantly turn
trigger on or off, add a new trigger, remove a trigger or re-load a new
version of a service program instantly. .
6. Must be 100% re-entrant.
7. Mediator should be as small and light as possible.
8. In my new version that I developed mediator logic should be changeable
without removing the triggers.

The newer version is running in a 2 billion dollar corporation over about
100 tables being fired 24 x 7 and you hardly know it is there.I have just
been too lazy to put new version out.

On Wed, Oct 29, 2014 at 2:07 PM, Tony Cate <tonyc@xxxxxxxxxxxxxxx> wrote:

Sometimes a gift may not be appropriate for the circumstances. In my case,
the mediator infrastructure is done. Recursion emerged as an issue in
testing. So, we could replace everything we've done with your work or
create a C pgm to be the facing object in the trigger stream and turn the
current mediator pgm into a module. There are a couple of other
considerations that have me thinking the simplest solution, that works, is
the best approach.

Honestly, I could end up using your mediator. It's too early to tell.

By the way thanks for the code you posted. I'll be playing with that in a
minute.

Tony

On Wed, Oct 29, 2014 at 1:19 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

" It seems really convoluted."

Everything that is in the mediator is there for a reason. It is designed

to

be database driven. You can maintain everything in the database and can
instantly turn triggers on or off by table or for everything. You can
update your service programs and instantly throughout the system all the
users have the new version.

Some of the issue that I see and maybe there is a solution but you are
calling RPG programs. What happens if the program is wrong? How do you
unload and since you are calling RPG how are you handling re-entrant
issues? If your RPG issues an update you are going to get a re-entrant

call

and the RPG is going to blow. What I posted earlier solves that problem

by

having a c module for entrance and an RPG module for the other logic.

When

you get to V6R1, you can create a Main program and you don't need the C
anymore.

I guess my only other comment on the "convoluted" is if the code worked

and

works well and is free why does it matter? Don't look a gift horse in the
month.

On Wed, Oct 29, 2014 at 4:56 AM, Tony Cate <tonyc@xxxxxxxxxxxxxxx>

wrote:

I am building a trigger mediator and recursion is the issue. As a side

note

Charles Wilt's note '...at v5r4 RPG programs aren't reentrant...'

surprised

me. At what release are they reentrant?

Anyway, I looked at Alan Campin's code. It seems really convoluted.
Wouldn't a pass thru C program calling a SRVPGM proc do the same thing?

John, what do you mean by 'direct'?

On Tue, Oct 28, 2014 at 5:23 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

Yup - I was going to suggest the same thing if he needed flexibility.

Or

just do it “direct” if not.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 28, 2014, at 4:44 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>

wrote:

Not being funny Tony - but if you are calling an RPG program to do

the

work then why bother with the C at all?

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 28, 2014, at 4:02 PM, Tony Cate <tonyc@xxxxxxxxxxxxxxx>

wrote:

First the code:

*#include <stdio.h>*
*#include <string.h>*

*#include <decimal.h>
#include <stdlib.h>

typedef void RGTRIGCNTL(char[80], decimal(10,0));

#pragma linkage(RGTRIGCNTL,fetchable)

int main(int argc, char *argv[])
{
char *triggerInfo;
decimal (10,0) triggerLen;

triggerInfo = argv[1];
triggerLen = argv[2];

RGTRIGCNTL(triggerInfo, &triggerLen);
}*

*What's going on: trying to write a small C program to attach to

file

triggers.*

Problems:

pragma linkage won't allow 'OS' for a parameter. Everything I've

read

indicates that's what I want. The only "ID' compiler didn't barf

on

is

'fetchable', which is why its there.

It compiles, but nothing happens when I try to step into

RGTRIGCNTL.

The Dev box is V5R4 (long story).

The questions:

Why can't I use 'OS' in linkage? Why isn't my program getting

called?

The last time I wrote a C program was in college, a looong time

ago.

--
*Tony Cate* | Senior Programmer/Analyst | 704.872.2458 x 126
[image: Auction Edge, Inc.] <http://www.auctionedge.com/>
*AUCTION EDGE, INC.* | *Powering Independent Auctions*
STATESVILLE, NC | 704.872.2458
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries)

(C400-L)

mailing list

To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries)

(C400-L)

mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
*Tony Cate* | Senior Programmer/Analyst | 704.872.2458 x 126
[image: Auction Edge, Inc.] <http://www.auctionedge.com/>
*AUCTION EDGE, INC.* | *Powering Independent Auctions*
STATESVILLE, NC | 704.872.2458
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
*Tony Cate* | Senior Programmer/Analyst | 704.872.2458 x 126
[image: Auction Edge, Inc.] <http://www.auctionedge.com/>
*AUCTION EDGE, INC.* | *Powering Independent Auctions*
STATESVILLE, NC | 704.872.2458
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.