Skip to main content

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
I haven't used c$redirect yet, but perhaps a performance workaround would be to have it send messages to threaded handlers.

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
..sure it should be, but i think update operations MUST be synchronized: i can't start a new thread, that is part of my transaction, and never know when it exists. How can i commit such a transaction, ensuring data integrity ? Such thread should be waited for termination, making it useless...



start transaction
write invoice row
redirect: update item stock
redirect: update customer sell amount
update invoice header
commit transaction



The "update item stock" and "update customer.." operations are executed via a c$redirect program fired by the "write invoice row": like it or not, i have to wait these operations in order to do a COMMIT.

Things are even worst if you repeat the PSEUDOCODE above in a loop, processing several thousands of invoices: in a mass update situation (that is the scenario where the problem arises !) i'm sure the TOTAL process time will be greater with the thread method than the "standard" synchronous mode...

ciao!

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
You miss my meaning. If you start the handlers in threads before any I/O operations and leave the threads alive, a single thread could service as many I/O operations as you like(synchronoulsy of course), sending back success/failure messages. The handler only loads once, the first time the thread is launched and remains resident until you tell it to shutdown.
I'm talking in hypothetical terms since I haven't actually done something like this before. I'm just throwing out ideas in case you need to explore workarounds. If you don't like the idea feel free to ignore it.

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
not a bad idea Dan, if i only could re-work my application as i would like...

The handlers are triggered by the runtime itself (you have no control on the "fire" process), and the slowdown occurs exactly in the "automatic" call mechanism by the runtime: when my program gains control, the slowdown has already occurred.

So, the problem does not lie in the trigger itself: it occurs even if i write a "empty" trigger program. Let me attach a small sample: if somebody is interested, download it in a folder and simply run "wrun32 prova.acu".

Speaking about threads, i wrote some threaded "file update service" some months ago, but the project was stopped due to the unreliability of the thread mechanism (especially in thinclient environment)....

ciao.

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
i apologize for the mispost...

[Migrated content. Thread originally posted on 29 December 2004]

I'm making an extensive use of the c$redirect routine.

I think the redirect feature is very useful: it lets you create a sort of trigger(s) to perform additional file operations without reworking the application logic: cascade delete(s), additional updates atque cetera.

For these pourposes i write down a "pre" and a "post" handler, that are installed in every program of my application.

The reverse of medal is that the presence of the handlers slows EVERY file operation: the rate of the slowdown is in the range of 10 to 1 !

Of course you can notice it in print programs, or in programs that perform mass update operations, such as monthly invoicing, statistics updating, and so on.

The slowdown remains the same even if I "empty" my handler programs, that now read only:


Procedure Division.
Exit Program.

For this reason it seems that there is something wrong in the internal call mechanism that
triggers the handlers.

My suspect is the runtime feeds my handler programs with the linkage items HANDLER-FILE-INFO (see the "handler.cpy" copy ) looking for the physical file information on disk at EVERY call. If my suspect is exact, why don't take the physical file info at the OPEN call only, and keep them stored for the subsequent calls ? (...if isn't exact, let me apologize for this stupid suggestion..!)

I've sent Acucorp Italy a sample program that opens input a Vision file and performs a read-next cycle on all its 17,500 records: with redirect OFF the process time is in the range of 0.4 seconds, while in the redirect ON scenario it takes about 4 seconds !

Finally, it seems there are not workarounds for this issue... anybody around using c$redirect ? any idea or suggestion ?

thanks in advance to everyone, ciao.


Runtime version 6.1.0
Version 6.1 is even worst :mad:



BTW, wish everybody a happy New Year!
not a bad idea Dan, if i only could re-work my application as i would like...

The handlers are triggered by the runtime itself (you have no control on the "fire" process), and the slowdown occurs exactly in the "automatic" call mechanism by the runtime: when my program gains control, the slowdown has already occurred.

So, the problem does not lie in the trigger itself: it occurs even if i write a "empty" trigger program.
Let me attach a small sample: if somebody is interested, download it in a folder and simply run "wrun32 prova.acu".

Speaking about threads, i wrote some threaded "file update service" some months ago, but the project was stopped due to the unreliability of the thread mechanism (especially in thinclient environment)....

ciao.
Terms & ConditionsAccessibility statement