|
Not going to mention anything about the /free, currently not in use here, nor do I see it happening anytime soon. Been given a directive now to "focus" on Java programming (lucky me huh). As for coming in handy, you are right. It is definitely much easier to use the indicators at times. I've just stopped using them on personal preference. I never was found of the left hand indicators. I've run across code in the past that have used them and I can't get past seeing 14 left hand indicators jumbled together to perform or not perform an action. Find it hard at times to see just what is going on at a glance. Example: c n99 cann98 cann97 corn96 cann95 cann94 cann93 corn92 cann91 cann90 cann89 cann88 cann87 Exsr One And yes I saw that once before. What a mess that was. So indicators used sparingly for small functions I can see, but like the example above, I would much sooner see a nice If statement using variable names that mean something. Ron Power Programmer Information Services City Of St. John's, NL P.O. Box 908 St. John's, NL A1C 5M2 Tel: 709-576-8132 Email: rpower@xxxxxxxxxx Website: http://www.stjohns.ca/ ___________________________________________________________________________ Success is going from failure to failure without a loss of enthusiasm. - Sir Winston Churchill "Michael Naughton" <michael_naughton@xxxxxxxxxxxx> Sent by: rpg400-l-bounces+rpower=stjohns.ca@xxxxxxxxxxxx 18/08/2004 01:20 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> cc Subject Re: Indicators I've tried to stop using indicators, too, but sometimes they just seem really handy. The other day, I came across a situation where I just couldn't see _not_ using them. I wanted to test two 8,0 fields to see if they held valid date values, based on either *ISO or *USA format, and if either one of them was bad I wanted to set an error flag. My code ended up looking like this: * Test passed date & set error flag if bad C Select C When (PRMFMT = '*YYMD') C *ISO TEST (D) PRMSDT 99 C N99*ISO TEST (D) PRMEDT 99 C When (PRMFMT = '*MDYY') C *USA TEST (D) PRMSDT 99 C N99*USA TEST (D) PRMEDT 99 C EndSL C 99 Eval PRMERR = *ON The shortest non-indicator version I could come up with was this: * Test passed date & set error flag if bad C Select C When (PRMFMT = '*YYMD') C *ISO TEST (DE) PRMSDT C If NOT %Error C *ISO TEST (DE) PRMEDT C Endif C When (PRMFMT = '*MDYY') C *USA TEST (DE) PRMSDT C If NOT %Error C *USA TEST (DE) PRMEDT C Endif C EndSL C If %Error C Eval PRMERR = *ON C Endif which is a difference of 16 lines instead of 9. Is there a better way to do it? Or is there some other reason why avoiding indicators in this case is "better"? I fully agree that in many (most?) situations there are better ways, but "most" is not "all", and I'm not sure that indicators won't remain useful in the future. . . . Am I missing something? (PS: don't bother telling me that when I switch to /free I won't be able to use indicators. I know that. If I'm forced to switch, I'll give up indicators, but IMHO that's not a good reason. So far, I find the benefits of /free underwhelming, and I'm a guy who has done a fair amount of programming in Visual Basic and DIBOL -- both very free-format.) Ron writes: >Yes I stopped using numbered indicators a while ago, Mike Naughton Senior Programmer/Analyst Judd Wire, Inc. 124 Turnpike Road Turners Falls, MA 01376 413-863-4357 x444 mnaughton@xxxxxxxxxxxx -- 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. This OutBound email has been scanned for Viruses
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.