IBM products inconsistency with date obtention - &SYSDATE in clists 
Author Message
 IBM products inconsistency with date obtention - &SYSDATE in clists

I find it very regrettable there are so many different ways
to get the current date in MVS. I know at least 4 different methods :

- SVC 11 (TIME LINKAGE=SVC)  : used by a majority of languages and products
- IEATTIME PC routine (TIME LINKAGE=SYSTEM) : recent, not widespread
- STCK : used by DB2, LE370, etc. (a computation is then necessary to get a
readable date)
- CVTDATE : still used by different system components (old versions
of SVC11 simply reused CVTDATE)

My problem is date simulators used for y2k projects do not support ALL
4 methods.
This problem gets harder when IBM changes
from time to time its way of getting the date !

In OS/390 v2r5 (TSO/E 2.6) it seems &SYSDATE variable
in Clists is now derived from cvtdate, as it is unsensitive to date
simulators
(at least to mine, DATE2000/MVS). Whereas REXX DATE() function
IS sensitive ! And TSO TIME command IS ! And ISPF &ZDATE variable IS !

It's a pity a definite policy has not been implemented as regards
date obtention in products. This makes y2k testing very difficult
(am I obliged to set up a y2k time machine or partition only
to get a correctly changed &SYSDATE ??).
Your comments (and IBM's) are welcome.

-----------------------------------------------------------

Have a look at my page "Is there life after MVS ?" at :
< http://www.*-*-*.com/ ;



Tue, 10 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists
Has the time svc been fixed?  Last time I looked you got 00YYMMDD in r1 or
r0.  I forget which.


Tue, 10 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists
: Has the time svc been fixed?  Last time I looked you got 00YYMMDD in r1 or
: r0.  I forget which.

It must have been more than decade ago that you looked. ;-)
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Tue, 10 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists
Really, have they fixed it to YYYYMMDD?

I would swear it was still 00YYMMDD as recent as the last contracting job I
had where I could use assembler and that was December 1997 in of all places
Los Angeles.



Tue, 10 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists

Quote:

>Really, have they fixed it to YYYYMMDD?

>I would swear it was still 00YYMMDD as recent as the last contracting job I
>had where I could use assembler and that was December 1997 in of all places
>Los Angeles.

AFAIK, the first byte of the DATE register is a "century indicator", i.e. 00 means 19, 01
means 20, etc.  That way the change is backward compatible

with kind regards

Volker Bandke
(BSP GmbH)



Wed, 11 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists
: Really, have they fixed it to YYYYMMDD?

: I would swear it was still 00YYMMDD as recent as the last contracting job I
: had where I could use assembler and that was December 1997 in of all places
: Los Angeles.

No swearing or guessing is required.  Just look in the manual.  Go to
http://www.s390.ibm.com/os390/bkserv/ and follow the links from there.

  TIME LINKAGE=SYSTEM returns the date in any of the following formats:

  DATETYPE     Form of Returned Date
  --------     ---------------------
  YYYYDDD      0YYYYDDD
  MMDDYYYY     MMDDYYYY
  DDMMYYYY     DDMMYYYY
  YYYYMMDD     YYYYMMDD

  The date is returned as packed decimal digits without a sign, where:

  YYYY     is the year
  DDD      is the day of the year
  MM       is the month of the year
  DD       is the day of the month

  TIME LINKAGE=SVC returns the date in register 1 as packed decimal
  digits of the form

  0CYYDDDF, where:

  C            is a digit representing the century.  In the years 1900
               through 1999, the macro will return a value of C=0.  In
               the years 2000 through 2099, the macro will return a
               value of C=1.
  YY           is the last two digits of the year.
  DDD          is the day of the year.
  F            is a 4-bit sign character that allows the data to be
               unpacked and printed.
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Wed, 11 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists

Quote:

> On Fri, 22 Jan 1999 22:27:11 -0800, "Bill Bershinger"

> AFAIK, the first byte of the DATE register is a "century indicator",
> i.e. 00 means 19, 01
> means 20, etc.  That way the change is backward compatible

Not exactly. The original specification said the high order byte was
zero, not "reserved". Existing programs which depended on this (for
example, the OS/PLI DATETIME library routine) were broken by the change.
Quote:
> with kind regards

> Volker Bandke
> (BSP GmbH)



Fri, 13 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists


Quote:
>...
>  TIME LINKAGE=SVC returns the date in register 1 as packed decimal
>  digits of the form

>  0CYYDDDF, where:
>...

This is indeed how it's documented, but an easier way to describe it is
as follows:

   0YYYDDDF

where YYY is the number of years since 1900.  

It also avoids offending purists who will claim that if C is a "Century"
indicator, it is turned on a year too soon.  

Michel.



Sat, 14 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists


: >...
: >  TIME LINKAGE=SVC returns the date in register 1 as packed decimal
: >  digits of the form
: >
: >  0CYYDDDF, where:
: >...

: This is indeed how it's documented, but an easier way to describe it is
: as follows:
:  
:    0YYYDDDF

: where YYY is the number of years since 1900.  
:  
: It also avoids offending purists who will claim that if C is a "Century"
: indicator, it is turned on a year too soon.  

I agree.  Perhaps someone should send e-mail to IBM's documentation
feedback userid suggesting a change in the official description.

--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Sat, 14 Jul 2001 03:00:00 GMT  
 IBM products inconsistency with date obtention - &SYSDATE in clists

Quote:


> : This is indeed how it's documented, but an easier way to describe it is
> : as follows:
> :
> :    0YYYDDDF

> : where YYY is the number of years since 1900.
> :
> : It also avoids offending purists who will claim that if C is a "Century"
> : indicator, it is turned on a year too soon.

> I agree.  Perhaps someone should send e-mail to IBM's documentation
> feedback userid suggesting a change in the official description.

I like it too, but then someone is bound to think that 0YYY should
return 0999 this year and 0000 next year :)

Tom Brennan



Sat, 14 Jul 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Withdrawal notice of IBM Ada products Withdrawal notice and transfer of IBM Ada products

2. More Date/Time inconsistencies

3. ISPF & CLISTS

4. gtk, clist & python

5. VisualAge-Test a new IBM product

6. DBI Error when attempting to pass Oracle's SYSDATE to a place hol der

7. Report Writer - in COBOL 2002 (and IBM add-on product)

8. "Whither" IBM's COBOLSet product(s)

9. IBM COBOL-related products

10. LE (language Environment) - Status of IBM and 3rd Party Products

11. IBM PC/AT Prolog products

 

 
Powered by phpBB® Forum Software