|
Steve,
I don't think Tom was saying it was CASE, or any other tool dependent. I
think he was saying that no sober person would put that line in their
program on their own. Therefore if a vendor see's a program in another
vendor's package with that line then it is pretty obvious that the other
package stole the logic from you.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Steve Landess" <steve_landess@xxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
07/26/2003 08:39 AM
Please respond to RPG programming on the AS400 / iSeries
To: "RPG programming on the AS400 / iSeries"
<rpg400-l@xxxxxxxxxxxx>
cc:
Fax to:
Subject: Re: Move 'ABC' to Numeric?
>>Bill wrote:
>> 2. Move 'ABC' to Numeric? (Bill Hopkins)
>>Anyone know why you would see this in code.
>> MOVE 'ABC' NUM 8P0
>>More code follows; then
>>NUM IFEQ 123
>>More code
>> ENDIF
>>
>>Found in bridge from JDE Sales Orders to PKMS
>
> Tom wrote:
> Does anything happen if it's not equal? Or is there an implication that
something somewhere else won't >happen if the IF-test fails because the
enclosed statements didn't run?
>
> I can _imagine_ someone from years gone by using something like this as
a
part of code that was
> generated so that under different circumstance a different source line
would have been auto-gen'd
>into the code to result in a value other than 123, perhaps because the
referenced numeric field might
> sometimes be signed and otherwise unsigned.
>
> Or perhaps the 'ABC' constant would be used as a marker in the compiled
object in order
>to recognize a reverse-engineered kind of rip-off? A few of these
sprinkled
around weren't
>unheard of and I believe still are used. It might just be a remnant that
never got cleaned up.
Tom -
IMO, This was not code generated by the JDE CASE tool. I have been
working
with JDE software since 1987, and I have never seen anything like this in
any JDE program. Some human bozo coded it. I have seen many modified JDE
programs that had stupid modifications like this.
Once, when I was working at a client in the Dallas area, a JDE _employee_
came in to fix a problem with the invoice print program. Later, when the
program was still working incorrectly, I looked at the mods he made.
Instead
of fixing the real problem, he had coded a GOTO around a block of code so
that the program would not bomb.
This speaks to the need of having a systematic way of QA'ing programs. In
college I was taught the structured methodology and using peer reviews,
the
"ego-less" approach to reviewing code. Too often the mavericks slip
things
in the code that should be caught _before_ the program gets into
production.
Steve
_______________________________________________
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 mailing list archive is Copyright 1997-2025 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.