Fortunately, I do not regularly write programs that are just used to be
SQL script programs. Normally, I include either F or D-specs and other
spaces. I just happened to want to reduce the source line as much as
possible.
I got the full correspondence and IBM seemed to think SE32782 might have
been a fix for this issue on 6.1 but they never absolutely confirmed
this and I did not look into since we are not in 6.1 and do not plan to
go within the next year.
The PMR create is 53261, 550, 000. If they think it's a simple fix then
I guess I do not see why they could not schedule it in the next CUM or
the one after that.
Thanks, Matt
-----Original Message-----
From: Simon Coulter [mailto:shc@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, October 14, 2008 4:17 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: SQLRPGLE preprocessed code mixing with expanded copy book
On 15/10/2008, at 7:09 AM, Tyler, Matt wrote:
FYI, Here's IBM official response.
The developer had the following update...
"I looked into this more on Friday and it is not a duplicate of
SE32782. This problem has been around forever. There are two
simple/easy circumventions. One they figured out is to have a
blank
line. This line can even be in the file that is being brought
in by
the copy. The second is to compile with RPGPPOPT(*LVL1 or *LVL2).
Since the problem is easily to see and there are two easy
circumventions I do not plan to fix this."
That's such crap! It is obvious that the pre-compiler function is
broken because it should not be inserting code inside conditional
compilation unless directed to do so by the programmer.
The pre-compiler is obviously processing the /COPY statement,
including the code in the positive test, inserting the /ELSE,
including the code in the negative test, and then screwing up
completely by inserting the SQLCA before the closing /ENDIF.
Since a blank line "fixes" things the pre-compiler must be inserting
the SQLCA before the previous line rather than after it. Duh! Why
would anyone think that is acceptable?
Given there are two work-arounds it is reasonable to say no PTF but
it should at least be fixed in a future release--preferably the next
one although given the newness of VRM610 they should PTF it in that.
"I do not plan to fix this" implies, broken, can stay broken, I don't
care. It's only a little bit broken so that's OK? Pah! I despair
sometimes.
Perhaps the developer is just trying it on. If I were you I'd reject
the answer explaining why it's unacceptable and what you would accept
such as a PTF in 610 but work-around for previous releases.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
