Re: Missing from RPG/LE

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
+---