×
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.
I know several similar issues are in the archives, but I suspect this
one could be solved with a PTF? Or else I need to know the rules...
I have an SQLRPGLE source that the compiler doesn't like (SQL0312 -
Variable not defined or not useable), but it was okay last December in
the v5r4 world. Here's the deal:
A global variable Account# is defined as 10 A.
inline subprocedure #1 defines a local variable "Account"
like(Account#).
Inline subprocedure #2 defines a local variable "Account"
like(Account#).
Precompiler appears to have a limited tolerance for defining Account
with "like(Account#)", because if I just change subprocedure #2 to
explicitly define "Account" as 10 A, it's okay with that.
I recall issues with locally defining variables of the same name in V5R4
until Gina told us about a PTF that made that all better. And when I
first wrote this code, and compiled in v5R4 (with the amazing PTF), it
was cool, even with all subprocedures using like(account). We went 6.1
and supposedly all pertinent PTFs last April. My project was installed
to production this morning, but two programs wouldn't compile
(CRTSQLRPGI) until the "like(Account#)" code was replaced with explicit
"10 A" definitions. (I tried compiling from both WDSC 7.0 and from PDM,
with the same result).
Is there a PTF for 6.1 that makes the Precompiler as smart as it used to
be? If not, do I understand correctly that we can only define a local
variable as "like" in one subprocedure when using the same local
variable name in multiple subprocedures?
Michael Koester
As an Amazon Associate we earn from qualifying purchases.
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.