Re: Floating Point Question -- MIDRANGE-L

-----Original Message-----
From: Colin Williams <Williamsc@technocrats.co.uk>
To: 'MIDRANGE-L@midrange.com' <MIDRANGE-L@midrange.com>
Date: Friday, August 13, 1999 6:01 AM
Subject: RE: Floating Point Question


>That sounds like something very interesting. Do you have some examples
>for us mere mortals.


No magic here, just a lot of different procedures and service programs
involved here doing different things, so I'm not sure which area you are
most interested in but as an overview....

The new stuff I've been playing with lately started out as a reaction to all
the maintenance problems I was having over the past year or so with my
triggers.  Because they are so tightly integrated in with the file that
triggers them, it was almost impossible for me to make changes to a
production trigger unless I wanted to get up at 3 a.m.  Even then, I had to
fight batch jobs and backups.  If a user even thinks about using a file, it
holds a lock on the trigger, preventing you from even turning it off, much
less make changes to it.  Since some of my triggers do a large amount of
field editing, they are constantly changing as business rules change.

I noticed, however, that procedures in service programs didn't have this
problem.  I can replace them anytime during the day without effecting the
users.  So I built a single trigger program that is used by all files.  The
only thing it does is call a trigger procedure in a service program.  Since
that's all it does, it never has to be changed.

The called trigger procedure (which is also generic),  then calls other
procedures that are specific to a file (contains the externally-defined data
structure, etc).  This works great, since they can be modified and promoted
to production and the system handles everything with QRPLOBJ and without
crashing the users.  The only problem was with many triggers, my Select
routine with hard-coded procedure calls was getting kinda long.

In response to a post on some other subject, Barbara Morris mentioned a
method using a couple of API's to start up a service program and return a
pointer to a procedure in that service program.  Then, by using that pointer
to a procedure, you could call the procedure itself using a generic name
rather than the actual name of the procedure.  Using this method, I could
call any trigger-handling procedure by simply calling the
"generic_procedure" and using the pointer to the actual procedure name.
This replaces the big long hard-coded Select list with a single call.  Also,
I don't have to recompile it every time I add new triggers.  Am I explaining
this right, Barbara?

So anyway, the result of all this is a true DLL on the AS400.  The first
procedure which calls the trigger-handling procedure for a specific file
does not know who it is calling at compile time.  It is determined only at
run time just before the call.  You don't even have to include the
prototypes to the specific trigger-handling procedures, just a generic one.
Cool huh?  This may not be a first for the lab types in Toronto, but it was
certainly something new for me (and to be able to write it in RPG).

It worked so well, in fact, I started using the same scenario to call SQL IO
modules.  You could use it to call any procedure on the fly, if you had some
way of knowing what procedure name you wanted to call.  I do this with a
tight naming convention of the procedures and service programs which is
based on the file name.  By getting the file name out of the trigger buffer,
I know what procedure and service program to call (at run time, after the
trigger has already fired and the calling procedure is already active).

The only real problem I'm still wrestling with occasionally is recursive
calls. Since all files use the same generic trigger program, cascading
triggers create recursive calls to the same trigger program.  This is solved
easily enough as far as the recursive call is concerned by putting the
trigger program in an activation group using *NEW.  However, I do have
problems with data management trashing the first trigger buffer with
subsequent trigger buffers.  It seems to want to write them in the same
place or something.  My only defense so far is to make sure I am through
with the first trigger buffer (or have what I need saved internally) before
updating any other files from the first trigger.  This is kinda clunky,
since I may not always know in what order triggers will fire. This area
still needs more polishing.  Once, they get a little more stable, this might
be some good code to post to one of those shareware sites we've discussed
here before.

The only thing really new or unique in all this are the two API's called to
activate the service program and call a procedure based on a pointer.  I
don't have their names here in front of me but if you are interested, I'll
get them for you.  They have been discussed here previously in other
threads.  Other, than that, it's just procedures in service programs.  Ain't
ILE wonderful?





+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---