Open victorizbitskiy opened 3 years ago
Hi Victor, I have flavored simplicity here...I had no use for running in a group on a remote application server and didn't mind running on all groups of the current server. I see no problems of having an additional optional parameter on Thread and ThreadFactory with defaulting somewhere.
Hi @xinitrc86!
Yes, this is exactly what I wanted to suggest 😊
Still no ability to define a group, but according to documentation destination in group is preferable over destination "none". Now destination in group is being used.
Still no ability to define a group, but according to documentation destination in group is preferable over destination "none". Now destination in group is being used.
Hi @xinitrc86! Could you please provide a link to the documentation?
Sure, this has:
Parallel-processing is implemented with a special variant of asynchonous RFC. It is important that you use only the correct variant for your own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees.
I don't know what it does technically, I suspect it has less overhead or manage resources a bit better. With this addition, I am being able to slightly increase the number of threads and still have a performance gain where before the extra number of threads would actually decrease the time to complete the same process.
There is currently no way to specify a server group (RZ12) when the FM ZTHREAD_START is called. Is this a bug or a feature?