Re: Triggers - enabling and disabling

Would it work to have the CL encode the buffer into a keyed data queue. Have data queue engines, one for each company that read the data queue and process. That way to drop one company, simply stop the correct data queue engine. Now the trigger does not need to do much more work than it does today and the control is in a different place.


Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 10/5/2012 3:33 AM, Åke Olsson wrote:

We do use a CL already. The problem is that all the 25+ companies that sit on the same server share the package program code. We would need to enable and disable per company (i.e. file/library).

Also to change a production program causes a lot of admin overhead these days with all the approval boards, committees and such.

Med vänlig hälsning / Best regards

Åke H Olsson

Box 433 SE 551 16 Jönköping Sweden visit: Brunnsgatan 11
phone: +46 (0)36 342976 mobile: +46 (0)705 482976 fax: +46 (0)36 34 29 29
ake.olsson@xxxxxx www.pdb.se


-----Original Message-----
From: Winchester Terry [mailto:terry.winchester@xxxxxxxxxxxxxxx]
Sent: den 4 oktober 2012 16:51
To: 'Midrange Systems Technical Discussion'
Subject: RE: Triggers - enabling and disabling

One option is to use a CL program for your trigger that accepts and passes the record buffer to a called program. Then you could change the called program to terminate immediately without ever having to change the CL trigger program.

Not sure how efficient this would be with large volumes of record changes...but its seems like it would work;-) We currently use the CL trigger trick to allow us to make changes to the called program without deactivation...

Terry

> -----Original Message-----
> From:midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Åke Olsson
> Sent: Thursday, October 04, 2012 10:44 AM
> To: (midrange-l@xxxxxxxxxxxx)
> Subject: Triggers - enabling and disabling
>
> We have to set up triggering for a bunch of files (15 files in 30
> instances). I can live with having to find a spot when the system is
> down to add the tiggers.
>
> But we would like to turn on and off the activation of triggers more
> or less at will. Status *ENABLED and *DISABLED should work nicely.
>
> The problem is that this operation seems to require private access to
> the file almost as much as ADDPFTRG does - is that really so?
>
> Is there in that case another better way to dynamically switch
> triggers on and off?
>
>
> Med vänlig hälsning / Best regards
>
> Åke H Olsson
> [Description:cid:image001.png@01CA1FE6.387A03A0]
> Box 433 SE 551 16 Jönköping Sweden visit: Brunnsgatan 11
> phone: +46 (0)36 342976 mobile: +46 (0)705 482976 fax: +46
> (0)36 34 29 29
> ake.olsson@xxxxxx<mailto:ake.olsson@xxxxxx> www.pdb.se
>