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



How about this?
 /COPY  QCPYSRC,xtools
c                   eval      testDate = DecToDate( PRMSDT : PRMFMT)
C                   if        testDate = D'0001-01-01'  // bad date :(
c                   eval      testDate = DecToDate ( PRMEDT : PRMFMT)
C                   if        testDate = D'0001-01-01'  // bad date :(
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Joel Cochran
Sent: Wednesday, August 18, 2004 10:48 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Indicators

On Wed, 2004-08-18 at 15:50, Michael Naughton wrote:
> 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.

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

This was a real stretch for me (going back to fixed-format), but here is
what I came up with:

d testDate        s               d   inz

c                   monitor
c                   if        PRMFMT = '*YYMD'
c                   eval      testDate = %date( PRMSDT : *ISO )
c                   eval      testDate = %date( PRMEDT : *ISO )
c                   elseif    PRMFMT = '*MDYY'
c                   eval      testDate = %date( PRMSDT : *USA )
c                   eval      testDate = %date( PRMEDT : *USA )
c                   endif
c                   on-error
c                   eval      PRMERR = *ON
c                   endmon

This solution ends up at 11 lines and a new variable.  Of course, the
number of lines doesn't really matter, but it is comparable to the 9 you
mentioned before.

> Am I missing something?

You are missing readability, which is also the number one offering of
/free, but is that underwhlems you then I'm not sure what to say. I'm
not trying to dig at you or suggest that you need to switch to /free,
just that if you don't at least acknowledge the readability of things
like /free and the PITA factor of things like left-hand indicators, then
we are at an impasse.  

> (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.)

You won't be able to use RESULTING indicators, but you can still use
indicators if you really want to.  

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

Follow-Ups:
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.