STL Time Machine Report #6 
Author Message
 STL Time Machine Report #6

Quote:

>STL Time Machine Report #6 -- Thursday 1998-02-05

   >>some snip  <<
>We finally got the all-important test of our in-core table LRU (Least
>Recently Used) algorithm.  For CICS programmers, just remember that an
>EIBDATE of 1999-12-31 (X'0099365C') is followed by X'0100001C'.  Yup,
>that's right.  CICS EIBDATE uses the same kind of Century Indicator as
>that the IBM MVS "TIME" Macro.  (Cory gets another chance to rant at IBM
>weirdness).  We didn't complete this test in cycle 1 because we ran out
>of time before rollover.  We sweat bullets last time as the seconds
>ticked
>away, and this time the network test script beat the clock.

   >snip <<
>Testing in an LPAR (logical partition) instead of buying an additional
>mainframe doesn't seem to be causing us any problems.  The Time Machine
>LPAR is completely isolated from the production LPAR.  That makes it
>hard to move files into the time machine, and no files will be allowed
>back, except for tapes.

   >more snip<
>Arnold Trembley
>Software Engineer I (just a job title, still a programmer)
>MasterCard International
>"Y2K?  Because Centuries Happen!"

I don't think that this applies to Arnold's testing (because IBM is
recommending LPARs to get around their problem).  However, I thought that
any of you doing Y2K testing of COBOL and/or CICS mainframe applications
should see the following APAR - if you haven't already.  Please note that
the APAR closing code is "DOC" for those who know the difference between
"DOC" and "PER"   (It is medium long - but highly relevant.  I also
apologize in advance for the formating - but I didn't want to try attaching
the "pure" HTML version avaialbe from IBM)

     >> APAR starts here  <<

Item PQ10688

 APAR Identifier ...... PQ10688       Last Changed..97/12/10
 COBOL CURRENT DATE INTRINSIC FUNCTION MAY YIELD INCORRECT DATE.

  Symptom ...... IN INCORROUT         Status ........... CLOSED  DOC
  Severity ................... 2      Date Closed ......... 97/12/10
  Component .......... 568819801      Duplicate of ........
  Reported Release ......... 710      Fixed Release ............
  Component Name LE FOR MVS & VM      Special Notice
  Current Target Date ..97/12/11      Flags
  SCP ...................
  Platform ............

  Status Detail: APARCLOSURE - APAR is being closed.

  PE PTF List:

  PTF List:

  Parent APAR:
  Child APAR list:

  ERROR DESCRIPTION:
  The CURRENT_DATE intrinsic function is the recommended support
  for obtaining the current local clock in a COBOL module.  This
  function supports 4 digit years (for YR2000) as opposed to the
  old method, I.E. the ACCEPT function which handles only two.
  .
  The CURRENT_DATE function will result in an eventual call to the
  LE/370 callable service CEELOCT - the obtain local time service.
  .
  In order to do YR2000 testing many customers have used either
  the REPLY command on IPL of MVS or the SET DATE/CLOCK command to
  alter the current local clock to some time after YR2000. The
  hardware clock will remain unchanged and will reflect the
  current GMT. The change will be reflected via two fields in the
  MVS CVT -
          CVTTZ - which is +/- 15 hours off of GMT
          CVTLDTO - which is the hours + days off of GMT
  CVTLDTO can accommodate date changes well passed the YR2000 from
  today.
  .
  The problem is if the clock is changed via the aforementioned
  methods to after the YR2000, CURRENT_DATE will reflect today's
  date +/- the local offset, not the date changed to.  This is
  is because the implementation of CEELOCT will do a STCK to
  obtain the GMT from the hardware and will add only CVTTZ. If
  CVTLDTO were added it would relfect the YR2000 date.
  Additional Keywords: Greenwich Mean Time CLOCKxx clock ZONE
                       offset
  Verification Steps:
  ------------------
      None necessary.

  LOCAL FIX:
  ----------
   Use the ACCEPT function if two digit years are acceptable.
  ACCEPT does not issue CEELOCT and will yield the proper date.

  PROBLEM SUMMARY:
  ****************************************************************
  * USERS AFFECTED: Anyone using SET DATE to change the date     *
  *                 and attempt to use date routines in          *
  *                 Language Environment, COBOL, C and PL/I.     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The date changed by SET DATE is not returned by certain
  date routines in Language Environment, COBOL, C, and PL/I.

  PROBLEM CONCLUSION:
  SITUATION:  When using certain date routines in various
  programming languages, the value returned will not reflect the
  date set by the MVS command SET DATE.

  RESPONSE:  The SET DATE and SET TIME commands only affect
  certain language statements and commands, not all of them.
  This method does not simulate a future date for Assembler
  programs that get the date using STCK (Store Clock) or certain
  CVT fields.  All appropriate manuals will be updated to reflect
  this.

  Below is the behavior found in each language using the Language
  Environment enabled version of the compiler running under
  Language Environment.  Also included is the behavior of CEELOCT,
  a Language Environment callable service.

  COBOL:  If SET DATE is used to set the date to a date in the
  future for Year 2000 testing, the values returned from
  ACCEPT id-1 FROM DATE (or DAY) and FUNCTION CURRENT-DATE will
  be different.  The value returned from FUNCTION CURRENT-DATE
  will not reflect this date in the future.  The reason for this
  is that FUNCTION CURRENT-DATE was designed to work in both batch
  and CICS, unlike the ACCEPT command which only works in batch.

  PL/I:  If SET DATE is used to set the date to a date in the
  future for Year 2000 testing, the values returned from DATE and
  DATETIME will not reflect this date in the future.

  C/C++: If SET DATE is used to set the date to a date in the
  future for Year 2000 testing, the value returned from time()
  will not reflect this date in the future.

  fortran: If SET DATE is used to set the date to a date in the
  future for Year 2000 testing, the values returned by DATIM and
  DATIMX will reflect the future date.  The reason for this is
  Fortran does not run under CICS, therefore it does not call LE
  Services for these date functions.  It uses SVC 11.

  LANGUAGE ENVIRONMENT: If SET DATE is used to set the date to a
  date in the future for Year 2000 testing, the values returned by
  CEELOCT will not reflect the future date.

  RECOMMENDED METHODS:  The most common methods used for Year 2000
  testing are Date Simulators, which overlay the STCK instructions
  and intercept SVC 11 (TIME Macro) calls, and Time Machines,
  which are LPARs that are isolated and IPL'ed to a future date.
  Either of these methods will provide a more realistic testing
  environment as well as guarantee more accurate results.  The
  Time Machine approach will validate the entire environment,
  including the different ways that IBM products like ISPF and JES
  get the current date, SET DATE will not do this.

  For more information about Year 2000 testing, please visit

  http://www.*-*-*.com/

  TEMPORARY FIX:

  COMMENTS:

  MODULES/MACROS:

  SRLS:      SC28194003 SC26311401 SC26476901 SC28166301

  RTN CODES:

  CIRCUMVENTION:

  MESSAGE TO SUBMITTER:
MESSAGE TO SUBMITTER:



Mon, 24 Jul 2000 03:00:00 GMT  
 STL Time Machine Report #6

Quote:

> I don't think that this applies to Arnold's testing (because IBM is
> recommending LPARs to get around their problem).  However, I thought that
> any of you doing Y2K testing of COBOL and/or CICS mainframe applications
> should see the following APAR - if you haven't already.  Please note that
> the APAR closing code is "DOC" for those who know the difference between
> "DOC" and "PER"   (It is medium long - but highly relevant.  I also
> apologize in advance for the formating - but I didn't want to try attaching
> the "pure" HTML version avaialbe from IBM)

>      >> APAR starts here  <<

> Item PQ10688

>  APAR Identifier ...... PQ10688       Last Changed..97/12/10
>  COBOL CURRENT DATE INTRINSIC FUNCTION MAY YIELD INCORRECT DATE.

>   <snip>

This is excellent information straight from the horse's mouth.  Save Mr.
Klein's original posting if it applies to your shop.  IBM closed out
this problem report by updating their documentation to say, "Yup, that's
that way it works".  

There are two issues here:  How do I get a date with 4-digit year from
IBM MVS/ESA, and how can I test my programs with future dates?

A year ago I tried writing an batch assembler subprogram to return
YYYYMMDD.  I am not a very good assembler programmer.  But I got it to
work fine using the TIME macro with the LINKAGE=SYSTEM option.  In
retrospect I would have been better off defaulting to LINKAGE=SVC and
doing a slightly more cumbersome conversion from BCD to zoned decimal.

Oh, sure, my little program worked, but it wasn't TESTABLE!  ViaValidate
could override COBOL ACCEPT yymmdd FROM DATE, but it could not override
my assembler program with LINKAGE=SYSTEM.  At that time, we hadn't even
begun testing COBOL for MVS and VM, we didn't have IGZEDT4, and any hope
of Time Machine testing was months away.  ViaValidate was the only test
tool we had for batch programs.  

When I got a chance to do some testing with COBOL for this-and-that, I
encountered exactly the problem Bill Klein showed us.  ViaValidate would
override the system date when it was requested in traditional ways, but
could not override the COBOL intrinsic FUNCTION CURRENT-DATE, which had
the four-digit year we wanted.  

If you have the PTF's to install the IGZEDT4 library routine, it will
return YYYYMMDD and ViaValidate will override it correctly.  I don't
know if IGZEDT4 will work in CICS, but I doubt it.  Look in you CICS
manuals for the options under EXEC CICS FORMATTIME.  You can get a
4-digit year returned as a separate field, and it's been available since
at least CICS release 2.1.2.

I suspect most MVS shops will be doing some kind of testing with date
warping tools (ViaValidate, TicToc, Hourglass, or whatever).  You need
to know that sometimes these tools won't work, and take that into
consideration when fixing code and testing it.

If you can IPL your test MVS machine with a future date you won't have
this problem.

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
"Y2K?  Because Centuries Happen!"



Tue, 25 Jul 2000 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. DC Y2K Weather Report (ALC 9, power, Time Machines, How Bad)

2. time and scheduling (was: bug report: [ #447945 ] time.time() is not non-decreasing)

3. bug report: [ #447945 ] time.time() is not non-decreasing

4. bug report: [ #447945 ] time.time() is not non-decreasing

5. Time for a virtual machines newsgroup?

6. Missing figures on reports - one machine only -

7. report generation problems on the WinNT target machine

8. Time for a virtual machines newsgroup?

9. The Mininal Forth Machine, First Report.

10. machine-readable copies of papers/tech-reports

11. Real Time Machine Vision

12. Python time machine and comp.lang.python logos

 

 
Powered by phpBB® Forum Software