Well Steve, the rules are exactly as I stated them: "Rexx is case-sensitive when
it regards data; it is case-insensitive only when it comes to how the Rexx code
itself is written."
It would be a greater stretch to assume that one built-in function (Date) would
behave differently from all the other BIFs in regard to case-sensitivity. And I
think you would have a hard time convincing IBM (or the rest of the Rexx
community for that matter) that only the Date() function should be changed to
disregard case. I have no doubt that such a change would raise the Astonishment
Factor significantly.
If it is that big of an issue, may I suggest that 'SET LANGUAGE UCENG' will
solve your problem, but you may find the cure is worse than the disease. :-)
As for improving the documentation to explicitly state that the output format of
Date('Normal'), and thus the input format for Date('Basedate',mydate,'Normal')
is in mixed case, there are two problems:
1. The documentation seems pretty complete to me already:
"NORMAL -
date in the format: dd mon yyyy. This is the default (dd cannot have any
leading zeros or blanks; yyyy must have leading zeros but cannot have any
leading blanks). If the active language has an abbreviated form of the
month name, then it is used (for example, Jan, Feb, and so on). If Normal
is specified for input_date_format, the input_date must have the month
(mon) specified in American English (for example, Jan, Feb, Mar, and so
on)."
2. The case is dependent on the SET LANGUAGE value (see Note 4).
One inescapable factor is that z/VM and z/OS are running embarrassingly ancient
versions of the Rexx interpreter, ones that are not even ANSI Standard compliant
over a decade after it was written. IBM gave Object REXX to the Rexx Language
Association to support and enhance it as an open-source project (see
http://sourceforge.net/projects/oorexx/).
The Open Object Rexx interpreter supports all the other major platforms
(Windows, UNIX/Linux/AIX, Mac) and is not only object-oriented, but has
"caseless" versions of those routines. Efforts to port the ooRexx code to VM
and/or TSO has stalled for lack of resources and expertise, not interest or
enthusiasm.
Perhaps you would care to help?
-Chip Davis-
[EMAIL PROTECTED]
On 11/20/08 13:30 Gentry, Stephen said:
"It depends." 8-)
In WORDPOS I would it expect it to be fussy, since it is indeed a
specific character string you are looking for. With DATE I would expect
it to be more concerned with the format of the date vs case of the
month. I'm not advocating that DATE('B', . . .) be changed to accept any
case. However what I would suggest that either the doc be changed to
inform the user of the month spelling requirement OR the DATE('B', . .
.) function be changed to disregard case.
Respectfully, let me know what the rules are and I'll play by them.
(or if I choose to ignore them I'll accept the consequences).
But, if we want to play CalvinBall then let me know that too. 8-)
(I like "opposite day" the "least".)
Steve
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Chip Davis
Sent: Wednesday, November 19, 2008 5:36 PM
To: [email protected]
Subject: Re: REXX DATE function
One man's "fussy" is another man's "rigorous" or "consistent" ... :-)
It was designed that way because the default output format returns the
month in mixed case. It was felt that reciprocality demanded that the Date() BIF
accept a date in the same form that it returned it, as long as it was
unambiguous
or, in the case of 2-digit years, windowable. Once you open the door to
variants, things get messy, e.g. should "12Oct2008" be allowed?
Remember, Rexx is case-sensitive when it regards data; it is
case-insensitive only when it comes to how the Rexx code itself is written.
Would you expect that "WordPos('OCT','Jul Aug Sep Oct Nov Dec')" would
return a "4" or a "0"?
-Chip Davis-
[EMAIL PROTECTED]
