On option would be to use PERFORM instead of EXECUTE. It's benefit is
that the PERFORMEd program gets the active select list, so you can do
things like:
PERFORM 'SELECT CUSTOMER-FILE WITH ACTIVE.FLAG STATE.CODE'
PERFORM 'SELECT STATE-TABLE SAVING UNIQUE STATE.NAME'
Instead of
EXECUTE 'SELECT CUSTOMER-FILE WITH ACTIVE.FLAG STATE.CODE' RTNLIST CODES
EXECUTE 'SELECT STATE-TABLE SAVING UNIQUE STATE.NAME' PASSLIST CODES
Or the proc-like:
DATA 'SELECT STATE-TABLE SAVING UNIQUE STATE.NAME'
EXECUTE 'SELECT CUSTOMER-FILE WITH ACTIVE.FLAG STATE.CODE
The downside is that PERFORM doesn't allow any of the
CAPTURE/RETURN/IN/OUT clauses, which could be a killer. Also obviously
you need to do some extra juggling to maintain the correct active list.

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Dodds
> Sent: Friday, January 20, 2006 2:42 PM
> To: Userr group U2
> Subject: [U2] UltPlus to UV
> 
> 
> We are migrating a system from UltPlus to UniVerse 10.1.14.  
> In the EXECUTE statement, when using the RTNLIST or the 
> PASSLIST function the resultant list is a list.varialble or 
> cursor and not a simple variable.  In the UltPlus system it 
> is both or can be used as both.  I am using RTNLIST and 
> PASSLIST as the generic word for the variety of keywords to 
> represent that functionality. 
> 
>  
> 
> In the statement:
> 
>  
> 
>             EXECUTE SENT ,//IN.<INPUT.DATA 
> ,//SELECT.<INPUT.LIST ,//OUT.>OUT.DATA ,//SELECT.>OUTPUT.LIST
> 
>  
> 
> the PASSLIST variable "INPUT.LIST" and the RTNLIST variable 
> "OUT.DATA" can function as both a simple variable and a 
> list.variable while in UniVerse they are only list.variables. 
>  SENT is the beginning of a select statement 'SELECT filename 
> '.  Some statements have just the PASSLIST and some have just 
> the RTNLIST.
> 
>  
> 
> Does anyone know of a clean way of handling this difference?  
> My only solution is to save the list, read it back in as a 
> variable and the use GETLIST/READLIST to activate a 
> list.variable.  This will require multiple variable names and 
> some tricky coding to determine which variable to use where.
> 
>  
> 
>  We have over 300 programs with various combinations of this 
> code and I would rather not address each of them individually.
> 
>  
> 
> Any thoughts or experiences would be appreciated.
> 
>  
> 
>  
> 
> Tom Dodds
> 
> [EMAIL PROTECTED]
> 
> 708-234-9608 Office
> 
> 630-235-2975 Cell
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to