Copyright 1991-2016 by Kevin G. Barkes

All rights reserved. This article may be duplicated or
redistributed provided no alterations of any kind are
made to this file.

This edition of DCL Dialogue is sponsored by Networking
Dynamics, developers and marketers of productivity software
for OpenVMS systems. Contact our website
www.networkingdynamics.com to download free demos of
our software and see how you will save time, money and
raise productivity! Be sure to mention DCL Dialogue!


DCL DIALOGUE

Originally published November, 1991

FAST EDDIE AND THE TIME MACHINE

By Kevin G. Barkes

I always enjoy stopping by the Doc's house. An inveterate
tinkerer, he's constantly trying to develop off-the-wall
inventions and strange man-machine interfaces. I was pleased
to hear he had recovered from the blender incident with just
a few minor scars, but was puzzled when he told me to rush
over to his place with a copy of the DCL Dictionary.

I found him awkwardly jammed into the passenger side of a
DeLorean, stuffing a MicroVAX 3100 and a 1.21 gigabyte disk
drive under the seat. "Hey Doc," I asked, grabbing an ankle
and pulling, "what's with the VAX?"

Barely acknowledging my presence, the Doc snatched an MMJ
connector which dangled from the dashboard and dived
headlong back into the stainless steel auto. "I need a
stable computing platform for my latest experiment," he
said, legs akimbo. "I can't afford machine lockups, user
application errors, file system corruption, or a system
clock that will be valid for less than a century. VAX/VMS
offers the best environment in which to conduct my
experiment."

"I'm impressed by DEC's grasp of multi-dimensional
concepts," he continued, tossing me one of those funny empty
boxes DEC uses to fill up space in its shipping cartons.
"Look," he said. "A fully three-dimensional analog to a
printed `This Page Intentionally Left Blank' message. This
outfit knows its stuff."

"Multi-dimensional? What are you trying to do now?" I asked,
puzzled by the various clock/calendar displays and what
appeared to be a massive capacitor cycling through various
stages of flux.

"It's not important at the moment," he said. Striking a
conspiratorial pose, he motioned me to come closer. "Quick,"
he said. "What are the range of valid dates and times
supported by VMS?"

Fortunately, I had just read a few articles dealing with the
subject on DSNlink. "The base time for VMS is November 17,
1858," I said.

"November 17?" Doc asked. "I've always been partial to
November 5, myself," he mumbled, half-smiling. "Never mind.
Go on."

"If memory serves, VMS can handle dates through a little
before three in the morning on July 31, 31086. That's when
the 63-bit absolute time representation within VMS goes
negative and all VMS time operations halt.

"However, there's another minor problem," I explained.
"31086 is a five digit number, and all of VMS' time-related
displays and routines can only display four digits in the
year field. But," I added jokingly, "DEC said it would be
fixed in a future release of VMS sometime prior to
31-DEC-9999."

The Doc paled and nearly fell. "What's wrong?" I asked,
grabbing his arm to steady him.

"I just realized my hardware and software support contract
through the year 9999 would cost $42,282,240.23," he gasped.
Recovering, he grabbed his notepad and continued the
interrogation.

"And what is the significance of November 17, 1858?" the Doc
asked, scribbling furiously.

"Julian Day 2,400,000 is November 17, 1858, which is also
the starting date of the Modified Julian Day system.

"The short story is the Smithsonian Astrophysical
Observatory adopted the Modified Julian Day (not related to
the Julian calendar) in 1957 for satellite tracking
purposes. January 1, 1957 was Julian day 2,435,839. The 8K,
non-virtual 36-bit IBM computer used by the SAO kept the
Julian day in the left 18 bits of a 36-bit word, and the
hours and minutes in the right 18 bits of a word. The
problem was the octal representation of Julian day 2,435,839
would have required 22 bits, wasting 14 bits of precious
memory.

"So, the SAO decided to settle on using 18 bits to represent
what was called the Modified Julian Day. From November 17,
1858, this permitted 700 years of timekeeping. Using 17 bits
allowed 300 years, plus one bit to allow for representing
negative time. No star catalog used by SAO was older than
1858, so 11/17/1858 was picked as the starting date."

"I see," the Doc said. "So time calculations in VMS can be
made for approximately 29,000 years into the future, using a
64-bit time format."

"Well, sort of," I said. "Someone recently reported a bug on
DSNlink in the F$CVTIME() DCL lexical function and the
LIB$DAY_OF_WEEK RTL routine.

"It seems that after December 10, 5941, the function will
return the wrong day of the week, due to a problem in the
time calculation algorithm. The routine counts the number of
100 nanosecond intervals from midnight on 11/17/1858, which
is stored in a 64-bit quadword. This number is divided by
600 million to convert it to minutes, and the result is
stored in a longword value. From that date to 12/10/5941 is
7FFFFF80 (hex) minutes, only a little over two hours away
from a longword integer overflow error. Fortunately, the bug
has been reported to VMS Engineering."

"These time calculations can be confusing," the Doc sighed.
"I need a simple procedure that will accept a future date as
input and return a value equaling the number of days from
today to that future date."

"Why?" I asked.

"I need to supply a numerical value to the charging circuit
of the flux capacitor that corresponds to the megafarad
discharge required to produce the required temporal phase
shift," he explained.

"Uh, right. How far in the future do you need to calculate?"
I asked.

"I believe 25 years would be sufficient," he replied.

"Okay. MACRO-32 gives me migraines, and I lost Bruce Ellis'
phone number. What kind of high level language compilers do
you have on your system?"

"Compilers?" he snorted. "Do you know how much a single-user
license for Fortran costs? No, it must be in DCL."

"You're in luck," I said. "Good ol' John ("Fast Eddy")
McMahon of TGV in Santa Cruz sent me a procedure can handle
dates up to 10,000 days in the future." (Program 1)

The Doc was ecstatic. I typed in the command procedure on an
old VT-52 crammed in the back seat of the DeLorean while Doc
closed up the open panels under the dash and dressed the
cables.

As I climbed out of the car, the Doc slammed the door and
started the ignition. "Thanks for the assistance," he
yelled, and punched the accelerator. The DeLorean streaked
out of the garage and was doing nearly 90 mph when it
disappeared behind a billboard. There was a muffled
explosion and an actinic flash, and the silver vehicle was
gone.

"Gee," I said to myself. "I wonder if he realizes that Fast
Eddy's procedure can't handle negative time values?" I
shrugged to myself, grabbed my DCL Dictionary and walked
between the twin pine trees into the darkness.


KERMIT UPDATE

Shortly after the August column containing tips on Kermit
usage appeared, I received a call from Terry Kennedy of St.
Peter's College Academic Computer Center in Jersey City, NJ.
Terry's the current developer of C-Kermit and he passed
along exciting news about some new features of the
ubiquitous file transfer protocol (ftp).

At the time of this writing, C-Kermit is up to version
5A(172). It contains large packets, sliding windows, and
performance equalling the Zmodem protocol, which is probably
the most popular ftp in the PC world because of its speed
and low overhead.

Terry said a soon-to-be-released version of C-Kermit would
contain lots of new stuff, including an extension to the
protocol which will enable it to handle virtually all RMS
file types and include support for ACLs. It will be possible
for the first time to transfer entire directories containing
varieties of file types. So it looks like the Kermit saveset
trick we talked about in August will no longer be necessary.

While RMS file handling is VMS-specific, this C-Kermit
feature is compatible with all Kermits on all platforms. The
information needed to handle non-ASCII files is stored in a
special header within the file. This means that a file can
be transferred from a VMS system to a PC, then to another
VMS system, and still retain the information necessary for
it to be properly reconstituted on the destination VAX.

Other futures include restart capability, a real boon to
persons transferring large files on noisy phone lines. It
will be possible to pick up an interrupted transfer at the
point of failure, eliminating the need to retransmit the
entire file.


******************************

Kevin G. Barkes is an independent consultant and a
Christopher Lloyd fan. He published the KGB Report
newsletter, operates the www.kgbreport.com website, lurks on
comp.os.vms and can be reached at kgbarkes@gmail.com.

**************************


PROGRAM 1

$! DELTA.COM - Calculate the number of days
$! from TODAY until a given date.
$! Return it in a global symbol "DELTA_DAYS".
$! If the program doesn't calculate a
$! good value return negative 1.
$ Delta_Days == -1
$! Upper limit of binary search.
$! DELTA time mathmatics in VMS are limited to
$! a maximum of 10,000 days.
$ Days_High = 10000
$! Lower limit is Zero days.  (e.g. Today)
$ Days_Low = 0
$! Convert the input parameter into a
$! comparison time string YYYY-MM-DD
$! by feeding it to F$CVTIME.
$ Target_Date = F$CVTIME(P1,"COMPARISON","DATE")
$! Test to make sure the date
$! is in the present or future.
$ If Target_Date .Lts. - 
   F$CVTIME("TODAY","COMPARISON","DATE")
$ Then
$ Write Sys$Output "P1 is in the past"
$ Exit
$ Endif
$! Test to make sure the date is
$! within the 10,000 day limit
$ If Target_Date .Gts. -
  F$CVTIME("TODAY+9999-00:00:00.00","COMPARISON","DATE")
$ Then
$ Write Sys$Output "P1 is too far in the future"
$ Exit
$ Endif
$ Again:
$! Simple binary search, we test at the "middle"
$! of the current search range 
$! and then adjust the range
$! accordingly until we hit the desired date.
$  Days = (Days_High + Days_Low) / 2
$  Test_Date = F$CVTIME("TODAY+''Days'-00:00:00.00","COMPARISON","DATE")
$! Test to see if we found the date.
$  If Target_Date .Eqs. Test_Date 
$  Then
$  Write Sys$Output "Days: ",Days
$  Delta_Days == Days
$  Exit
$  Endif
$! If the Test date is too low we raise
$! the lower bound of the search range
$! to the current number of days.
$ If Target_Date .Gts. Test_Date
$ Then
$ Days_Low = Days
$ Else
$! Otherwise we drop the upper bound.
$ Days_High = Days
$ Endif   
$ Goto Again
$ EXIT