The JADE 2022 release meets tomorrow’s business demands.
The Job Control Facility (JCF) uses method recursion to define and manage job steps within a job. Because generally 2 (but sometimes more for certain job element types) methods are involved for each job step, I have had to impose a limit of 100 job steps per job to avoid getting near to or hitting the 256 method call stack size limit.
The impact of this on major users (Skipton Building Society and Computershare) is that they are forced to break the job decks down so that they call separately defined sub flows. The main negative impact of this is:
Inability to view and maintain the job steps as a continuous stream.
Also, downstream reporting of job execution is misleading.
My understanding is that while the limit is currently hard-coded in C++, it would be a relatively straight forward to make it soft.
One approach would be to have a new method on process that could be called prior to the recursion to indicate that a larger stack size is required, and then another method call on process after the recursion has finished to set the limit back to the current default of 256.
Keith Domigan
For the last 25 years this has been a limitation I have seen in multiple industries within Jade. We're normally forced to write code around this limitation, from intruducing cut-off levels, to offloading data to a collection/file/etc. Can it just be removed completely? There are heaps of tools available to avoid arrays in C++. Vectors, lists, pointer-structures etc.