Gopi responds:

>Hi Duane
>
>> I ran tests on a 5.5 system that had the updated routines and
>> on an older system that did not. Lets call the 5.5 system 'a' and
>> the older 'non-updated routines' system 'b'.
>
>  I guess, the system 'b' is pre-MPE/iX 5.0.
>
>> 2. NL (Native Language) routines (like nlconvcustdate, nlfmtcustdate,
>>    nlfmtdate, etc) accessed on 'a' treated 2 digit years < 50 as 20xx
>>    dates and years >= 50 seemed to be 19xx dates.
>
>   YY:Split century method (2 digit years < 50 as 20xx and so on)
>   does not apply to these intrinsics.
>
>   These NL intrinsics takes input date in CALENDAR format where the
>   year field can be from 0..127. So, if you pass 25 in the year field,
>   you should be getting the result as 1925 (not as 2025) from the above
>   intrinsics. I verified this behavior in 5.0 and 5.5.

Gopi,

My previous response was too quick to assume I was in error. Not all the
NL intrinsics accept a calendar date as you say!

One of them returns the calendar date (NLCONVCUSTDATE)! It is this NL
intrinsic which now assumes that a date of 01/01/00 is in the year 2000
instead of 1900 and will return a year of 100 instead of 0 encoded into
the returned calendar date.

So, I stand by my original comment:

If you have code that wants to build a calendar date using NLCONVCUSTDATE
you cannot do this for 1900-1949.

BTW, I tried to pass a string of 01/01/1900 and received an error. I was
only able to pass 2 digit years in the text buffer and get a successful
completion. Maybe there is a different format that can be used to force
an evaluation of incoming text as having a 4 digit date.



Duane Percox ([log in to unmask]  v/415.306.1608 f/415.365.2706)
http://www.qss.com/          http://www.qss.com/qwebs
http://www.qss.com/faq3k     http://www.qss.com/qsdk