On 01/07/2011 05:42 PM, Paul Gilmartin wrote:
On Fri, 7 Jan 2011 17:12:46 -0600, Joel C. Ewing wrote:
On 01/07/2011 02:48 PM, Tony Harminc wrote:
On 7 January 2011 14:36, Paul Gilmartin wrote:
On Fri, 7 Jan 2011 08:33:58 -0700, Larry Dinwiddie wrote:
Run the following PIPE from your Ready prompt
pipe command LISTFILE fn ft fm (DA | sort 63.2 d 57.5 d 66.8 d |>
sorted list a
I tried that, and I got Y2K problems.
Meaning that your VM is configured for 2-digit years, or that the
above pipe assumes it is?
Is that something I can change in the VMSECURE USER dialog?
Setting a global variable in PROFILE EXEC?
If I change it, will LISTFILE (LABEL display 4-digit years.
There was much discussion of this around Y2K. There is nothing
inherently wrong with external user interfaces continuing to use
two-digit year fields for data entry efficiency in contexts where
ambiguity is not possible, just that these values should be stored as
four-digit values when saved in files or databases, and the internal
expansion to four-digit year should be done using floating windowing
techniques based on current date that won't break at an arbitrary future
date.
So how does ISPF store the year in PDS directories?
Y10K is not a concern because it's unlikely the Gregorian
calendar will be in use at that time.
I am irritated by some geology textbooks that specify dates
in years BP (Before the Present)
-- gil
ISPF directory dates are stored in the highly-peculiar IBM Julian Date
format variant used for SMF timestamps: a positive-signed PL4 field
currently defined as 0cyydddF. Although the formal definition at this
point only allows for "0c" being "00" for 19xx years and "01" for 20xx,
this format could represent any year from 1900 through 11899 by the
obvious extension of the date format to "ccyydddF" where cc is the top
two decimal digits of a four-digit representation of "year-1900", so it
may be considered roughly equivalent to using a four-digit
representation of the year. All code changes we made for Y2K to account
for the "01yy" date enhancement assumes this obvious extension for 21xx
and beyond. One can make a valid argument that this is a horrid date
format to keep for another 98 centuries, but not on the grounds that it
can't be made to work. The current definition was an unfortunate
consequence of choosing to reduce Y2K remediation work by minimizing
date comparison problems at Y2K with pre-2000 dates saved in the older
"00yydddF" Julian Date format.
--
Joel C. Ewing, Fort Smith, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
