I know we use them, but whenever one of the programmers wants to debug a
program they take them off, which causes us other problems as we have processes
which rely on the trigger output.
This would be my biggest beef with UV at the moment.
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson
Sent: Saturday, 27 July 2013 7:32 a.m.
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
> 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:
>> 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: firstname.lastname@example.org
>> Subject: Re: [U2] Universe Triggers
>> In addition to the other responses you have received, I suggest the
>> 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.
>> 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 mailing list