|
midrange.com
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Simon,
I agree that IBM included date support because it was in the database,
(not that they've included BLOB manipulation in RPG though - like anyone
would do that :-) ). I just shot that example out there as easy for
others to grasp.
A question about your code. You have two input parameters but your
samples never pass the second parameter. Won't that cause problems - as
coded?
Forgive me if that is nitpicking. I do understand your point. I do
create many subprocedures. I just wanted to see if I missed something in
the code.
I assume that validDate was an indicator field for those that like to have
a debuggable return value, and not a date field. Is my assumption
correct?
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Simon Coulter" <shc@flybynight.com.au>
Sent by: rpg400-l-admin@midrange.com
08/23/2002 09:44 PM
Please respond to rpg400-l
To: rpg400-l@midrange.com
cc:
Fax to:
Subject: Re: It's That Time Again! The 2002 RPG Enhancement Poll
Hello Rob,
You wrote:
>Having IBM do the trivial sometimes comes up with some better idea's.
Not always :)
>For example, everyone had a set of date routines for dealing with
>numeric numbers. However I like the functionality of true date fields
>much better.
This is not a good example. Dates, times and timestamps were implemented
in the database therefore they become accessible to any data processor
(Query, SQL, HLL, etc.) therefore it makes sense to provide built-in
support for those data types. (But look at how many systems **still**
use numeric 'dates' thus requiring the language to support conversions
when we should be using the native types.)
What I object to is the seemingly endless requests for Toronto to provide
trivial RPG IV specific functions whose sole purpose seems to be to
provide a BIF to replace an op-code so free-form RPG looks better by
avoiding the switches out of /free and in again. Hence my comment that
the proposed %TESTD, %TESTT, %TESTZ functions are a waste of Toronto's
time and money because:
D testDate PR 1N
D aDate 10
D aFormat 10
P testDate B EXPORT
D testDate PI 1N
D theDate 10
D theFormat 10
D validDate S 1 INZ(*ON)
C SELECT
C WHEN ( theFormat = '*YMD' )
C *YMD TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*MDY' )
C *MDY TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*DMY' )
C *DMY TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*CYMD' )
C *CYMD TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*CMDY' )
C *CMDY TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*CDMY' )
C *CDMY TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*JUL' )
C *JUL TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*ISO' )
C *ISO TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*USA' )
C *USA TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*EUR' )
C *EUR TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = '*JIS' )
C *JIS TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = $LONGJUL )
C *LONGJUL TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C WHEN ( theFormat = $JOBRUN )
C *JOBRUN TEST(DE) theDate
C EVAL validDate = NOT(%ERROR)
C OTHER
C EVAL validDate = *OFF
C ENDSL
C RETURN validDate
P testDate E
took 15 minutes to code and verify with the reference manual and allows
me to code:
C IF testDate( birthDate )
or
C IF NOT(testDate( birthDate
))
or
C EVAL validDate = testDate( birthDate )
Of course, if variables were allowed in Factor-1 for the TEST(x)
functions it would be simpler still. Wack that function in a service
program, shove that in a binding directory, name the binding directory on
a common H-spec that is /COPYed into the program template, and we have an
instant new language extension.
This example needs testing and possible additional support for *YYMD,
*MDYY, *DMYY, etc. Consider it open source; if someone creates the
corresponding time and timestamp (really easy) functions we'll be done
and Toronto can concentrate on complex things. The same thing could have
been done with the date duration BIFs and there are other examples such
as ALLOC.
Having said that, perhaps Toronto do have something grander in mind but
that doesn't change the essence of my proposal which is to improve the
LANGUAGE rather than the code. If the language improves the code will
too. Toronto have given us the ability to extend the language via
procedures so let us stop asking them to do the stuff we can do for
ourselves.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
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-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.
