Re: SQLRPGLE cursor questions

@RLA stateless or not

RLA is statefull too, a file could be open or not, the record pointer has a position, records could be locked or released, there is a commit state. Moving the f specification to a subprocedure complicates programming (and is therefore ugly design!). Holding the state of the File you would need statefull variables (last read record, some flags etc.). Giving these variables local scope (to the subprocedure) and making them static, would lead to a monoöithic design; all operations to this file must be done in one procedure, blowing up this procedure and its parameter interface, or you would have to pass lots of information from one procedure to another.
The better modularized alternative with RLA would be, having only one file specification in a module!!! All what has to be done, is done in this module, with a set of procedures dealing with this one and only file (readCustumor(), write custumor(...)...). All what's needed from others is exported, all what's only needed inside is not exported and the state of the file (ass discussed above) is encapsulated in this module.


@Using embedded SQL:

The precompiler is a little bit outdated and declares its variables it will need for file access, next to the SQL statement it needs the variables, giving it generic names (SQLnnnnn). Moving things used in multiple procedures to the local section could make it tricky and would have the same consequence as using procedure local cursor declaration. The precompiler might even get flew, if you need procedure local variables as host variables (if the name is not used anywhere else it works, changing another proceure later on and using the same name of a variable might break the programm!!!). Using SQL CLI, you would have to declare all variables for your SQL calls by your own and could decide, where you want to have them, but again you have the need for statefull data! The easier (and thow!!!) better alternative would be a file access module as pointed out above.

@Cursor names:
Cursor names are local to its module and not visible from outside

@stored procedures:
Cursor names are local to its implementing context and accessed from the caller by a handle, not related to the cursorname used insite the stored procedure.

D*B