See also ../Wallst/WSGD9711.htm#Yardeni

  \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/

    From: Bob Armstrong                       97/11/05 15:49
 Subject: Y2K Info
      To: adam@westergaard.com

 Adam ,
 Here are copies of the notes on Y2K  I  sent John .
  -------------------------------------------------------------------------
  ============================: TUE.MAR,970311 :============================
To:  > INTERNET:john@westergaard.com
Subject:  Y2K and other overflows
 John & Emile ,        | DDT , LOC |>| TUE.MAR,970311,13:27 NYC    -5 + 0

 In settling on a web broker ... ( I have settled on ... partly because its
 on my friend JayWhipple3`s PortfolioAccountingWorldWideSystem , now a part
 of CheckFree . )

 I recently perused your site .

 I`ve never been overly impressed by the year 2000 problem . The reason I
 ( and Jay ) live in APL ( the name of his original company is Security APL )
 is because it is the most abstract , and therefore restructurable , of
 languages . That`s why its main market is very hi level financial systems .
 For instance , one old friend ( and early adopter of CoSy back in the
 `80s ) is a leading actuary in workperson`s compensation reinsurance where
 the timescales are scores of years and the action starts several sigma low
 in frequency and hi in $$$ .

 APL systems are much more prone to the sort of problem discussed in
 ' The Next Date Crisis and the Ones After That ' by Robert L. Glass
 in January`s Communications of the ACM . Luckily , the article is on the web
 at http://www.acm.org/cacm/JAN97/pptext.htm .

 Ironically , I just encountered my own Y2K bug . It`s young . I made it in
 1995 . I was generating DayLines for my future MidWinter CoSy gatherings
 to see what days the party would be falling and I saw the following :
               ================: THU.FEB,990204 :=================
               ================: FRI.FEB,   204 :=================
               ++++++++++++++++: SUN.FEB, 10204 :+++++++++++++++++
 obviously caused by dropped leading 0s .  [ps]

 In simplifying my timestamp to the current form , I made the function

     TS is { 100 base 100 modulo 5 take RA }

 to simply pack vector time stamps in the form  2000 2 4 15 13 55 999 into a
 single floating point number accurate to the minute .
 The bug clearly comes because leading 0s are lost .

 I ended up replacing this definition with

    TS is { ( , transpose 10 10 represent 5 take RA ) pik DIGITS }

 which returns a correct character string . I searched all the 1111 verbs
 which currently compose CoSy to check that TS is not used anywhere other
 than in  DDTFMT  which underlies the  DayDateTime  function you see used
 above .

 While I was at it , you`ll see below I finally added the local time zone
 offset to DDT .

 I must admit , I spent more time on this than I expected , and you can see
 that in CoSy/APL the actual amount of code changed is small . But it has to
 be well considered .

 If you have any questions or comments about all this , let me know .
 Incedentally , now that I am finally wraping up family related business in
 Illinois , I am actively turning to marketing CoSy as it is , and bringing
 together the people and resources to take it where it can go .
 Which is to displace Microsoft`s terminally complex environment [ designed ]
 for Children who run Corporations .

                                       | DDT   |>| TUE.MAR,970311,16:3-5

                                  -- BobA --
          BobArmstrong                                     CoherentSystems
   212-285-1864 ø X:-732-0244                              http://cosy.com
  42 PeckSlip 4B | NYC NY 10038                              bob@cosy.com /

[ps] : This bug is more pernicious in terms of effect because it breaks the
 timestamp into 2 pieces  since SPace is the fundamental delimiter in
 CoSy . |17:11|

  ============================: TUE.OCT,971021 :============================
    From: Bob Armstrong  10:58
 Subject: Y2K starting 971102
      To: John Westergaard 

John ,

 Here`s a Y2K problem of the arbitrary sort I sent you info about back on
 TUE.MAR,970311 .

 It`s on page 8 of the Oct. 20 Electronic Engineering Times . You can access
 it by the URLs below :

http://cmp-pub1.web.cerf.net/en/sbin/iarecord?NS-search-set=/344cb/aaaa003q14
 cb5a0&NS-doc-offset=0&NS-adv-search=0&
http://www.techweb.com/se/techsearch.cgi?action=View&VdkVgwKey=%2E%2E%2F%2E%2
E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fservices%2Fdata%2Fsearch%2Fdata%2F1997%5F%5F%5
B28428%5D&DocOffset=1&DocsFound=1&QueryZip=apollo+bug&SourceQueryZip=+%3Cand%
3E+%28%27EET%27+%3Cin%3E+pub%29+%3Cand%3E+%28issuedate+%3E%3D+9%2F1%2F1997%29
+%3Cand%3E+%28issuedate+%3C%3D+10%2F31%2F1997%29&Collection=coll1997&Collecti
on=tw%5Fcurrent&Collection=tw%5Fdaily&Collection=collinv&ViewTemplate=cmpview
 %2Ehts&&publication=EET"

Or more simply go to :  http://pubsys.cmp.com/eet/news/search/print.html 
 and search for 'Apollo bug' .

Here`s the start of it :

      HP, Mentor can't agree on fix for Nov. 2 Apollo bug
      By Richard Goering
 Wilsonville, Ore. - Mentor Graphics customers still running Apollo Domain
 workstations from Hewlett-Packard Co. will get a nasty surprise at precisely
 14:59 Greenwich Mean Time Nov. 2, when the real-time clock will increment in
 a way that may cause a catastrophic system crash.

 And Mentor and HP offer conflicting advice on what to do about this early
 "Year 2000" problem. Apollo workstations use a 32-bit real-time clock, and
 on Nov. 2 it will increment so that the 32nd bit is set. Some computer
 operations evaluate that bit as a negative number, causing serious problems
 when an application tries to compare time stamps from before and after.
 Documentation at HP's Web site (www.hp.com/go/vintagesw) says the system
may "panic" or hang, in which case "the file system will be at risk."

  ============================: MON.DEC,971208 :============================
    From: Bob Armstrong  09:40
 Subject: Date overflows
     To: "john@westergaard.com" 
     CC: Adam Kaplan 

John & Adam ,
I happened to pull up the following when looking at
 http://www.wrs.com , Wind River Systems , an embedded systems
operating system provider .
Note there are  3  overflow dates they warn about  other than  Y2K .
-- BobA --   http://Cosy.com
    ---------------------------------------------------------------------
 To our customers:
  Wind River's Tornado development environment, including the VxWorks
  real-time operating system, will not be affected by the rollover from 1999
  to the year 2000.
  The VxWorks system clock itself is simply a count of ticks, and there is no
  conversion between it and calendar time. The concept of calendar time is
  only applicable to file system-related functions. In VxWorks, real calendar
  time is maintained by the user and provided to Wind River's
  MS-DOS-compatible (dosFsLib) and RT-11 (rt11FsLib) file system libraries
  through call-outs or specific time-setting functions.
 Wind River products use the following timing specifications:
  ANSI C--VxWorks uses ANSI C time specifications, which are "year 2000
   compliant." ANSI C will have its own rollover in the year 2038, when there
   will be 31 bits worth of seconds since 1/1/1970 to deal with. There are
   some plans within ANSI and/or POSIX to handle this rollover via extensions
   but, as of yet, no proposals have been formally adopted.
  dosFsLib--Wind River's dosFs file system is year 2000 compliant. Like
   MS-DOS, dosFs encoding can handle dates through 12/31/2099.
  rt11FsLib--The RT-11 file system is also year 2000 compliant, but can only
   handle dates through 12/31/2003. Wind River does not plan to support
   rt11FsLib beyond the year 2000.

 - It`s that 2003 date which is in the sort of embedded systems Ed Yardeni
  is concerned about .


                                  -- BobA --
          BobArmstrong                                     CoherentSystems
   212-285-1864 hf X:-732-0244                              http://cosy.com
  42 PeckSlip 4B | NYC NY 10038                              bob@cosy.com