|
>> However, procB still passes the xml string as input via a 65K const varying which may now have become the culprit when we optimize the application. Your advice on the best coding practice for declaring the procedure interface would be appreciated. I'm not sure there is a "best" practice for this kind of scenario <grin>. If indeed the allocation of temporary storage is the problem, I'd be going after IBM to fix it - or at least explain it! Hopefully now that they are back from celebrating Canada Day, Hans or Barbara will be able to comment on this. In part the various work-arounds depend on the requirements for the input parm. If only fixed length fields are passed, I would tend to use Options(*VarSize) without the varying or const keywords and either pass in the length of the field using %Size or use descriptors to determine it. If varying fields are required, then you could use the technique that you have applied to the return value on the input side as well (i.e. eval parm = input) but it is not terribly efficient. There are various other options I can think of but they are pretty obscure. I think IBM need to tell you _why_ it doesn't work as is and then armed with that knowledge you can craft a solution (or wait for the PTF!) Jon Paris Partner400 www.Partner400.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.