|
Hans, I have added some more detail. We really look forward to new releases now so that we can take advantage of the new RPG features. David Morris >>> Hans Boldt <boldt@ca.ibm.com> 09/29 11:38 AM >>> >David Morris wrote: >>Full support for parameterized types, by far most important. So we could >>write our own %range, %in, etc. procedures. >I assume you mean being able to pass any data type >and have full operational descriptor support to be >able to handle the full range of types. That's correct, some sort of options(*vartype) for prototypes and full operational descriptor support. >>Real support for system pointers. So we can dynamically call procedures >>without worrying that it won't work some day. >Could you clarify what the problem is? One case would be if I want to dynamically execute a procedure I have to first activate the service program that contains the procedure. The API that activates a service program expects a system pointer. It appears to work if I call the MI C function RSLVSP with a procedure pointer, and then pass the returned pointer to the activate program API. This does work at this time but I have heard that this is not an officially supported capability. >>Support for file alias so we could use the same file twice. So we can take >>full advantage of blocking without having to use convoluted overrides, etc. >I'd like more information on what you want here >as well. We do have some ideas already on making >more file specs options available which should >alleviate the need for overrides. In I/O modules I have found we could improve performance by about 33% for reade and 45% on read (actual case benchmarks) through a combination of overrides and access path sharing. To accomplish this I had to rename the file in the F specs and perform an override before compiling. One file was used for keyed access, and the other for sequential access. Another alternative would be a file level keyword that forced blocked reads or a new block value block(*justdoit). >>*Continue return point from *PSSR. So we don't have to code EXSR *PSSR, >>especially for statements that don't support (e) or error indicators. >We've wanted this type of thing for a long time. >But, we've never adequately resolved what to do for >cycle functions. Or at least, that's been our excuse! >Also, depending on implementation, there may be a >slight performance penalty with this. Must be really hard when the program is *NOMAIN. >On the other hand, we've also been thinking of other >ways to handle exceptions, such as TRY & CATCH >statements. >Cheers! Hans >Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.