RE: Floating Point Question

Yes, sounds interesting. Yes, those API names would be handy.

>>> -----Original Message-----
>>> From: Nelson C. Smith [mailto:ncsmith@gate.net]
>>> Sent: Saturday, August 14, 1999 2:36 AM
>>> To: MIDRANGE-L@midrange.com
>>> Subject: Re: Floating Point Question
>>> 
>>> 
>>> -----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
>>> +---
>>> 
+---
| 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
+---