We use this same concept. The triggers themselves are globally cataloged, but all they do is check a table then based on the file in question, call a 2nd locally (DIRECT) subroutine. Debugging is simple for us and never clobbers the live code when developing in a test environment on the same box.
JRI -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, July 29, 2013 11:35 AM To: U2 Users List Subject: Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers I must say, I use triggers in UD with no problems. When converting from D3 to UD I had a hard time getting them to work. However, with useful suggestions from several on this list I was able to get them working properly. They turned out to be a bit more robust than the D3 triggers. I've been able to "debug" the trigger several times when problems appeared, but haven't for a number of years as they work as expected now. The structure took a while to get my head around, but I simply have two trigger programs (globally cataloged): U2.MASTER.TRIGGER.D U2.MASTER.TRIGGER.U ...which handle all delete and update triggers. Inside each program a file is read that actually provides the trigger subroutines to CALL (via a CALL @...). So, I can insert any subroutine as a trigger in any account. These programs are cataloged locally. I don't remember any problems debugging these subroutines. Just a thought. Bill ------------------------------------------------------------------------ ----- Original Message ----- *From:* perry.tay...@zirmed.com *To:* U2 Users List <u2-users@listserver.u2ug.org> *Date:* 7/29/2013 6:24 AM *Subject:* Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers > That and the expense of their usage. > > Perry Taylor > Zirmed, Inc. > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles > Stevenson > Sent: Friday, July 26, 2013 1:32 PM > To: U2 Users List > Subject: [U2] [UV] Do you avoid TRIGGERS because of the difficulty > using DEBUG or RAID with them? Was: Universe Triggers > > How many people avoid using triggers BECAUSE of the virtual > impossibility of using RAID with Triggers? > > On 7/26/2013 12:33 PM, Phil Walker wrote: >> I won't be holding my breath Charles ;-) >> >> -----Original Message----- >> From: u2-users-boun...@listserver.u2ug.org >> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles >> Stevenson >> Sent: Friday, 26 July 2013 9:22 p.m. >> To: U2 Users List >> Subject: Re: [U2] Universe Triggers >> >> re. triggers & Raid, I could not agree with Phil more. Well said. >> Come on, Rocket! >> >> On 7/19/2013 1:32 AM, Phil Walker wrote: >>> Ken, >>> >>> I am glad you raised the issue about debugging a program with a file which >>> has a trigger attached. I have been on to UV (Vmark/Ardent/IBM/Rocket for >>> ages about fixing this pushing for the ability to be able to step into the >>> trigger code, but at a VERY MINIMUM being able to debug the program and >>> perform the write on the file, and in effect step over the trigger >>> subroutine and carry on debugging. The issue is the trigger subroutine >>> cannot support input, so what UV have done is basically say you are using >>> the debugger so you are inputting debug commands so you will abort. They >>> need to turn this restriction off for debugging so that either of the above >>> two scenarios is supported. >>> >>> In a Microsoft world I can debug anything through the connected world of >>> web/databases etc...... >>> >>> Have had no feedback from UV >>> >>> -----Original Message----- >>> From: u2-users-boun...@listserver.u2ug.org >>> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford >>> Sent: Friday, 19 July 2013 9:48 a.m. >>> To: u2-users@listserver.u2ug.org >>> Subject: Re: [U2] Universe Triggers >>> >>> Dan, >>> In addition to the other responses you have received, I suggest the >>> following: >>> 1. Have one master file trigger subroutine (globally catalogued) that calls >>> subroutines (locally catalogued) tailored to individual files. This means >>> you don't have to stop and restart Universe when a new trigger is required >>> or a change to an existing one. If the master subroutine changes, you do >>> have to restart Universe. >>> 2. Use a control record that records the subroutine name and state of the >>> trigger for each file having a trigger. >>> 3. Use a program to change the state of a trigger, using the control >>> records in 2 above. >>> 4. Make sure all background processes that have a file with a trigger open >>> are logged out when recompiling the subroutine for that file trigger. >>> 5. Remember that you can't do anything to a file with an active trigger >>> whilst in the RAID debugger (it will crash). Rather, if you are testing a >>> file trigger subroutine, drop the trigger and use a trigger testing program >>> that calls the subroutine after taking a copy of the record being changed, >>> pausing whilst you change it in another session, and then resuming, calling >>> the subroutine. >>> >>> If you would like samples of any of the software mentioned above, let me >>> know, and I can send them to you. >>> >>> Regards, >>> Ken Ford >>> Universe Software Developer >>> t 07 3013 8605 | f 07 3002 8400 >>> e ken.f...@firstmac.com.au | w firstmac.com.au > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://cp.mcafee.com/d/FZsScz9J5As-yyCyCCrKrhKyC_t6WpEVdEThjvKyCyqejqd > QkTXETpKrhKyCqenSm63hOrBie-8N1i6BFRxhJrUOH7BPq6BFRxhJrUOH7BPpEV847D7kn > -LPVEVhujuWZOWtQneujvjK_ORQr8EGETpVkffGhBrwqrhdICXCXCM0pYGjFYjfNVJdIzM > 071dnoovaAVgtHzqptKDNErrjbJQ-d2V2Hsbvg57OFeDNc_7CQSOf00jpEVvjvdwLQzh0q > mMCCqnjh0qmMC6jiWq80WFEwblrd46CqOgd4091oq4wAd0Iod413XqTjPh1lQQgj9-q849 > eKOISvcIq86Wiwhd40sd38j2hEwH4Qg0Ig3gUQg69j9Cy2pfRihEw0nq96y09MAp-dfd40 > 9z8yh-d3tPpJSX > > CONFIDENTIALITY NOTICE: This e-mail message, including any > attachments, is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. ZirMed, Inc. > has strict policies regarding the content of e-mail communications, > specifically Protected Health Information, any communications > containing such material will be returned to the originating party > with such advisement noted. If you are not the intended recipient, > please contact the sender by reply e-mail and destroy all copies of > the original message. > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://cp.mcafee.com/d/k-Kr4zqb8VZ55d5dcTsSzt5d-WdQPhOrhKyC_t5d4QsCQrE > FLThKPsSzt5cQsLIIc6zATaAtYhy2AdbjH2zqTNBmfbCQdbjH2zqTNBmfbCPhOg8feeELZ > vDPhOyYCZRXBQXEKsYC-Dt_BHEShhlhKPOEuvkzaT0QSCrpdTdTdw0PVkDjUCvzPqrp7w0 > e2qKMM-l9OwXn6QOXtfzgSSCnrFYq5O5mUm-wafBitfyp-fdFJAu00CPhO-C-r1vF6y0QJ > xdcQKCy0QJxccCBQQg1Rjh0mGSq8dcRAwq80i2MQ918q1oMq827SRKDCy2HFEwCjYQg8it > tBpI-poQgdQB0yq80Uq6gC4zh1m9Ew1ow6xNEwciCjd44OvGAzh00KQid40jx8PYquq80j > 6h4zYq6XCQOnb_ME4 _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://cp.mcafee.com/d/avndxMArhp7fEEFEFFCXCQrEFLThKCqejqdQkTXEFECzASzt5d-WdSrCQrEFCzBZBxwQsCVkzLycgkxFqtokrm-cGNVsSxFqtokrm-cGNVsSqei11VNR5_HY-qeknATKLsKDt5PDATQXLYJt6OaaGdSul3PWApmU6CSjr9KVKVI06vaAWv4PYurjr8Y01MjlS67OFek7qUSCnrFYq6SQOXtfzgKgGT2TQ1hYGjFYjfNVJdIzM04SqenQTPobZ8Qg6BI9FCBQQg6BI9xAQKCy0eGq82RmPh1FCIA3h02gm6x893gb63h0g-SJQYQgltd44OvCy12jHIHdDPb6y1KAE4jh073gO4MAq8aNd40b40Qed41ykOpEwCjZkAq805SyhEw2s96vzjPh02oO8AvzgTsTtWb _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
