t24- VERSION.CONTROL

[cape...@gmail.com]

Hello Guys ,
In t24 the VERSION application can be used to customise input and add
validation, perform update to other tables etc...
Suppose I want every creation of a customer records to update some
local tables , I do not want to have a AUTH.ROUTINE attached to a
specific version because if a different version other than the one to
which my routine is attached is used to create a customer record
update will not occur and I can no longer rely on my local table for
accuate reporting.
1) I thought I could go to the VERSION.CONTROL application and have a
key such as CUSTOMER and add my AUTH.ROUTINE there and see it beging
called regardless of which VERSION is used for input.
Nothing happened
2) I thought I could create a VERSION.TYPE id such as XXX then create
VERSION.CONTROL like CUSTOMER,XXX , then select some VERSIONS of the
customer application and set the field VERSION.TYPE to XXX , so that
my AUTH.ROUTINE is added to a group of version and is called for all
these versions (T24 manuals suggest this )
Nothing Happened ,

Please provide help / comments to help me with this issue.
Note I need to know if there is a way I can control input to an
application via a single point without customising all availables
input screens , as some input screen will surely be created by users
after any setting I put in place now ,

Thanks

[ianp]

Hi
You could implement this through a trigger routine.
ian

[cape...@gmail.com]

Hello Ianp,
I have not used that before , What is a trigger routine and how can I
use it , Please

Thanks

> > Thanks- Hide quoted text -
>
> - Show quoted text -

[Lukasz]

Hi,

To link VERSION to VERSION.CONTROL, make sure field EXC.INC.RTN is set
to YES.
Don't use triggers with T24! Temenos will kill you! :-)

Cheers,
Lukasz

[cape...@gmail.com]

Thanks Lukas , Will try this
But also please I really want to KNOW MORE about "THESE" triggers and
how they could be used and used with T24

Thanks again

[praveen kumar]

Hi,

        Ideally VERSION.CONTROL should work I am not sure why it's not working for you.

Have you set this field EXC.INC.RTN = YES in your version. If not then please do then it will work.

Also you can try TRIGGERS ,if you don't want to do it through versions.

Regards,

Praveen

[ianp]

Lukasz,

I am genuinely curious why the use of triggers to update local files
should be a no-no in T24?

Is there a Temenos policy which precludes their use in T24? I am
interested as we use them a lot in Globus and will someday be moving
to T24...

Thanks

On Mar 19, 6:05 pm, "praveen kumar" <pav...@gmail.com> wrote:
> Hi,
>
>         Ideally VERSION.CONTROL should work I am not sure why it's not
> working for you.
>

> Have you set this field *EXC.INC.RTN = YES* in your version. If not then

> please do then it will work.
>
> Also you can try TRIGGERS ,if you don't want to do it through versions.
>
> Regards,
>
> Praveen
>

[Phuong Do Duc]

Your question is easy. Follow these steps:

 

1 - In VERSION.CONTROL, record CUSTOMER (or any Application you want), you attach your SUBROUTINE's name which update to your Local Table at field AUTH.ROUTINE. Commit and Authorised if neccesary (I dont remember).

 

2 - In your SUBROUTINE, now you must specify: Which version will be update by this Routine, you can use these lines:

 

            IF PGM.VERSION EQ ',ANYNAME1' THEN

                   <DO YOUR WORK HERE>

            END

            IF PGM.VERSION EQ ',ANYNAME2' THEN

                   <DO YOUR WORK HERE>

            END

...

 

For example, If I want to change something after Authorise in Version name "AZ.ACCOUNT,MDT.FD.OPEN" in my Routine, so I must specify like that:  IF PGM.VERSION EQ ',MDT.FD.OPEN' THEN (no need "AZ.ACCOUNT,MDT.FD.OPEN" because this Routine attached to VERSION.CONTROL, record AZ.ACCOUNT)

I write:

 

            IF PGM.VERSION EQ ',MDT.FD.OPEN' THEN

                   <DO MY WORK HERE>

            END

 

Does it clear for you?

 

Regards.

 

 

 

 

2008/3/19, cape...@gmail.com <cape...@gmail.com>:

--
Đỗ Đức Phương
Mobile: 84 904 302 898
Home phone: 84 4 5543349

[Andrew Trusov]

Hi!

First of all there is field 12.NON.VERSION.RUN in VERSION.CONTROL if it set "Y" then all routines defined in VERSION.CONTROL should run for every version of application, even no version, except the case if in particular version field 73.EXEC.INC.ROUITNE is set

EXC.INC.RTN

Flag to indicate whether the routines defined in VERSION.CONTROL should be executed for this version or not.It also decides whether the features FLD.CHECK.VALUE, NOINPUT.VALUE, NO.CHG.VALUE, REKEY.VALUE, AUTOM.VALUE, MAND.VALUE,D.SLIP.VALUE and GTS.VALUE should be enabled for this version or not. The VERSION.CONTROL record is indicated by the application and VERSION.TYPE of this VERSION record.

So, please, check values in both this fields when trying to use VERSION.CONTROL.

2008/3/19, cape...@gmail.com <cape...@gmail.com>:

[TONY CAPE]

Hello Guys ,

I have comfirmed that setting field 73 (EXC.INC.RTN) to YES makes it possible to call my routine define in VERSION.CONTROL .and Setting the field 12 in VERSION.CONTROL(NON.VERSION.RUN) makes my routine to be called when input is done without any VERSION e.g. CUSTOMER I 9999.

Thank you very much for all your input.

I have also done some reading on triggers , and I like it and think that it better suits what I want to achieve as long as I am not updating core t24 files but only locally developped tables and only on POST WRITE.

Do you guys still think that using triggers to update locally developped tables is dangerous in t24 ?

Thanks again

[Kannan Seshadri]

Badly written triggers can be potential danger to the overall performance of T24.  Temenos neither suggests you to use triggers nor stops you from using triggers. They leave it to the individual implementations to take that decision and also related consequences.

 

Regards

[Lukasz]

Hi Guys,

Ok here's my point on triggers.

1. Keep business logic inside T24
By using triggers you move business logic outside T24, and put it into
database layer. This is not recommended as T24 is meant to be open
system (db independent). Now consider one day you want to move from
jBase to Oracle. Then you hit a problem - at the moment you can't have
Oracle triggers working with T24 (T24 common area won't be visible in
Oracle). So you will end up moving your business logic back to T24.

2. Don't assume T24 will be available in the trigger
Another issue - I presume your trigger will contain some T24 related
logic. So in this trigger for example you will assume that T24 common
area is initialised - and it will be if database updates occur only
from within T24. But if it happens that you edit a record from jBase
only, you will probably end up with some error (e.g. when trying to
use F.WRITE inside trigger).

3. If there is an error, HD will always point that it is because
triggers ;-)
This is from my experience.

So I think version routines provide better control as you have read
above. Still, you can consider using triggers for things that are not
related to T24 (like update of logs or whatever).

Regards,
Lukasz

On 20 Mar, 09:42, "Kannan Seshadri" <kaneso...@gmail.com> wrote:
> Badly written triggers can be potential danger to the overall performance of
> T24. Temenos neither suggests you to use triggers nor stops you from using
> triggers. They leave it to the individual implementations to take that
> decision and also related consequences.
>
> Regards
>