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



It can not be a question of skills since RPGIV requires no new skill, at
least at the conversion level.  It has to be a question of perception.  

There is a word that always comes to mind in these discussions.  Shibboleth.
 
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: 02/26/04 17:01:42
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Date compare Best Practices
 
The bigger question is why the hell are people not MOVING to RPG IV?
I just don't get it, I know about legacy code and not wanting to break it,
but if we're doing maintenance... why not convert it?
The only reasoning I can think of is that there is an issue with skills.
-Bob
 
 
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of DeLong, Eric
Sent: Thursday, February 26, 2004 4:50 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Date compare Best Practices
 
Hmm?  The 10000.01 trick only works because RPG compilers before ILE don't
care if you truncate numeric digits.  I'd also question whether the RPGIII
community REALLY understands why this works.
 
Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863
 
 
 
-----Original Message-----
From: Booth Martin [mailto:Booth@xxxxxxxxxxxx]
Sent: Thursday, February 26, 2004 4:33 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Date compare Best Practices
 
 
I am beginning to get a tad paranoid here.
 
 
 
What is wrong with the mult 10000.01 trick?  Obviously the entire RPG III
community already understands it.  Also, it works.  Documentation is is no
big deal because it is pretty much self-documenting.
 
 
 
Just because the other lesser languages cannot rely on the values of their
numeric fields is no reason for us to back down and use inferior methods
like the hard-to-understand data structure tricks.  ;p
 
 
 
 
 
 
 
---------------------------------------------------------
 
Booth Martin   http://www.MartinVT.com
 
Booth@xxxxxxxxxxxx
 
---------------------------------------------------------
 
 
 
-------Original Message-------
 
 
 
From: RPG programming on the AS400 / iSeries
 
Date: 02/26/04 14:53:12
 
To: rpg400-l@xxxxxxxxxxxx
 
Subject: Re: Date compare Best Practices
 
 
 
Bob Cozzi wrote:
 
> There is nothing wrong with using the "MULT 10000.01" technique in RPGIII.
I
 
> do it every time I need to convert a date in that old language.
 
> If you use it in RPG IV, then you are right it is a questionable choice.
 
> The only other technique in RPG III is to use a data structure, but that
can
 
> be a bit more complex that the MULT. If you haven't seen it before then it
 
> doesn't matter which one you use because the person maintaining the code
 
> after you will have to deal with it, so just be sure to document it
 
> properly.
 
> -Bob
 
 
 
Well, once you factor in the necessary comments, moving DS subfields
 
still ends up as fewer source records. Not to mention 100-150 times
 
faster. But why use a clear and efficient programming technique when
 
there are some really cool ways (like that MULT trick) to show off your
 
programming prowess? ;-)
 
 
 
Cheers! Hans

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.