× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, like I said I end up relearning this all the time.

But try having the global zip have different attributes.

Also, try putting it into a DS.

>From the manual:
v5r2 - "The names of host variables must be unique within the program, even
if the host variables are in different procedures."

v5r3 - "The names of host variables must be unique within the program, even
if the host variables are in different procedures. However, if a data
structure has the QUALIFIED keyword, then the subfields of that data
structure can have the same name as a subfield in a different data structure
or as a stand-alone variable. The subfield of a data structure with the
QUALIFIED keyword must be referenced using the data structure name to
qualify the subfield name."


Charles


> -----Original Message-----
> From: Joel Cochran [mailto:jrc@xxxxxxxxxx]
> Sent: Wednesday, August 25, 2004 6:26 AM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Subroutines vs Subprocedures was RE: Indicators
> 
> 
> OK, stop the presses... I just tested the following code and 
> it worked:
> 
> 0000.01 d subProc         pr
> 0000.02 d zip             s              5a   inz('22980')
> 0000.03
> 0000.04  /free
> 0000.05    subProc();
> 0000.06    *inlr = *on ;
> 0000.07  /end-free
> 0000.08
> 0000.09 p subProc         b
> 0000.10 d subProc         pi
> 0000.11
> 0000.12 d zip             s              5a   inz('24401')
> 0000.13 d zipDS         e ds                  extname(allvazips)
> 0000.14 d sqlStatement    s            200a   varying
> 0000.15 d                                     inz( 'select * +
> 0000.16 d                                     from allvazips +
> 0000.17 d                                     where zipcode = ?' )
> 0000.18
> 0001.00 c/exec sql
> 0002.00 c+  declare zipCursor cursor
> 0002.01 c+      for zipStatement
> 0004.00 c/end-exec   
> 0004.01 c/exec sql
> 0004.02 c+  prepare zipStatement
> 0004.03 c+     from :sqlStatement
> 0004.04 c/end-exec
> 0004.05 c/exec sql
> 0004.06 c+  open zipCursor
> 0004.07 c+   using :zip
> 0004.08 c/end-exec
> 0004.09 c/exec sql
> 0004.10 c+  fetch next from zipCursor
> 0004.11 c+   into :zipDS
> 0004.12 c/end-exec
> 0008.01 c/exec sql
> 0008.02 c+  close zipCursor
> 0008.04 c/end-exec
> 0008.05  /free
> 0008.06    return ;  
> 0008.07  /end-free
> 0009.00 p subProc         e
> 
> Notice that "zip" is defined both globally AND locally and it still
> works!  So now I have to question the ability to use local 
> variables in
> SQL entirely... is there a case where I canNOT use a local variable in
> an SQL statement?
> 
> Joel
> http://www.rpgnext.com
> 
> 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.