× 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.



Try defining zip with different properties and see if it flies.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Joel Cochran <jrc@xxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
08/25/2004 05:25 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Subroutines vs Subprocedures was RE: Indicators






On Wed, 2004-08-25 at 10:06, Joel Cochran wrote:
> Wouldn't you want to avoid this though?  You would have to ensure that
> the local variable name is unique, which kind of defeats the purpose of
> making it local... although, back to my other statements about
> guaranteed initialization and similar items, I guess I can see a benefit
> to this.  In fact, this could come in very handy when using columnar
> functions and such for calculations... hmmm... now you've got me
> thinking...

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


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.