No offense, but what's done is done.  HPYEAR is currently defined,
and I'm not eager to "fix" things that break simply because MPE/iX
changes the format midstream.  I'd rather have a new variable (I'm
easy here, call it whatever as long as I know it's available I'll be
content) that defines the century as well.  That way, I'm not forced
into "fixing" some scripts by a particular OS release, but rather by
the end of this decade.

Regards,
Michael L Gueterman
Easy Does It Technologies
email: [log in to unmask]
http://www.editcorp.com
voice: (509) 943-5108
fax:   (509) 946-6179
--


----------
From:  Steve Dirickson b894 WestWin[SMTP:[log in to unmask]]
Sent:  Thursday, November 21, 1996 5:10 AM
To:  [log in to unmask]
Subject:  Re: Proposal for new HPCENTURY CI variable

<<>Three suggestions, in order of preference:
>HPLONGYEAR
>HPFULLYEAR
>HPYYYY
>

As we ponder the possible names for a new CIVAR which reflects the value
of the year, let's not fall into the situation where we are mired in the
"BackwardCompatibility" problem. Years are (presently!) defined with 4
digits. It seems to me that we should bite the proverbial bullet and say
HPYEAR is the 4 digit year, as of a particular V.U.F And then
hpSHORTyear, or hpyearincentury become meaningful values for the 2 digit
aberration!>>

Bingo. A "year object" is no more sufficiently/correctly identified by a
2-digit value than an "address object" is by a number and street. HPYEAR
should contain the correct year value (which is not limited to 4 digits,
by the way), and users who need to extract the modulo-century (or
modulo-millenium, or whatever) part of it can use 'rht()'. Though it
would probably be handy to predefine an HPsomething variable to provide
the two rightmost digits of the multi-digit year value, since so much
existing software uses that value.

Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]