Viewing LDS Ordinance info in Internet IGI

[Allen]

Everett M. Greene wrote:

Allen <[email protected]> writes:

You apparently never programmed for a bank. Mortgage loan maturities 40
to 50 years away (on commercial properties) and instalment loans with
eight-year payout schedules highlighted the Y2K issue from the start. My
bank didn't have to worry about this in 1962, when we first started to
pragram for an IBM 1401 with a whopping 4K of memory, but by 1966 and
the arrival of our first IBM 360 Mod 30, with a gigantic 16K, we were
getting into mortgage loan processing and all dates were expressed as
yyyy. Also, the time constraints you fretted about were SOP in banking;
three-day weekends were a programmer's dream, as they had an extra whole
day for testing and tweaking. I wasn't officially a programmer, but a
banker who knew as much about computers as most of our programmers did,
to the extent that I sometimes helped debug IBM assembly language
programs. I was in charge of converting our Trust Department from a
manual posting system back in the earlyish 1970s. We scheduled two full
weekends for the conversion, but signed off fully converted and tested
at 4:00 PM on the first Saturday; this was the result of meticulous
planning, testing and before-hand data conversion. I handled a fairly
large number of conversions and on only one did I miss the established
deadline, because I was in the hospital undergoing surgery. The big
secret to successful data processing operations in organizations is
simply communication and mutual understanding. I used to tell people
that I was tri-lingual, that I spoke Banker, Programmer, and
English--three different languages.


Taking your description at face value, you are to be
congratulated on work well done.

I thought if one worked in commercial DP, one had to speak
COBOL as well.

[Now about some paragraph breaks in your writing...]
I spoke it, but used it exactly one time. I needed a program that our

programmers just couldn't find the time (actually inclination) to do, so
I wrote one in COBOL D. It involved a very large reference table, and
native COBOL D supported only start-at-the-top, go one-by-one-to the
bottom: I wasn't about to write an assembler routine for a binary
search, and most of the hits were on the bottom end of the table. It was
run several times a day and brought the 370/145 that it ran on to its
knees, preempting everything else that was trying to run. I thought that
it would shame our programming staff into writing a proper one, but no!
It was run for three years. I H-A-T-E C-O-B-O-L!
Allen

[Ron]

Charlie wrote:

First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.
In early 1970s I had a monthly service billing program with one digit

for anniversary year - it assumed any thing 5-9 was 196x and 0-4 was
197x. Of course by 1975 we had to change it BUT main frame we had was
probably a bit short of capacity compared to machine on which I write this

IBM, I think it was, defined an algorithm that could be inserted in each
program that read the date that made some basic assumptions about whether
the 'yy' should have a '19' or a '20' placed in front of it. It worked and
the proper solution was put off for another day. So, in a number of
instances the problem is still there it is just more hidden. Perhaps the
system users should bear some responsibility for that problem.

Some pre2000 programs would have had 2 digits years with something like
my one digit year - anything 66 plus was 19xx and hence 0-65 would be 20xx

One of my favourite programs, which I use a lot for genealogy, has an
automatic date entry which enters todays date as 5 February 1107, and I
have
to go back and correct it.

Amazing how could genealogy software employ any algorithm for date - it
should allow for full millennium input (ok what about BC)

Calendar programs are very complex on dates - having to allow
calculations for Easter etc- and much the same should be in genealogy
program
--
Ron Lankshear - Sydney Aust (from London- Shepherds Bush & Chiswick)
http://freepages.rootsweb.com/~lankshear/

[Charlie]

"Steve Hayes" <[email protected]> wrote in message
news:[email protected]...

On Sun, 04 Feb 2007 14:21:04 GMT, "Bob Jones" <[email protected]
wrote:

G'day,
The Y2K was not a software problem (as such). It was a hardware problem in
that the onboard memory of early computers had enough memory assigned to
the
computer date function to handle ddmmyy. This meant that when the year
changed from 31/12/99 to 01/01/00 then all the programs that used the
computer time /date would "assume" that the year was 1900 instead of 2000.
The solution was not to upgrade your software but upgrade your hardware to
a
mother board that had the necessary amount of computer memory to handle a
4
digit year instead of the previous 2 digit year. There was very little Y2K
drama for the simple reason that we were given lots of warning (time wise)
and most people upgraded their hardware before 2000 which negated the
EOTWAWKI threat.

Not so.

Computers had enough memory to deal with it from the early 1980s, but
short-sighted programmers still only allocated enough memory for two-digit
years.

Being one of the short-sighted programmers referenced in your post, perhaps
you may want to cogitate upon a couple of issues related to that presumed
short-sightedness.

First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.

A bigger issue that I came across related to converting the history file of
transactions that had accumulated with a 'yy' format to a 'yyyy' format.
One's ability to remove an application system from an operational status for
the time necessary to convert the "master" file depended upon the importance
that the system had in the mind of the user. The higher the importance or
dependancy the less time one was given to convert the old system. One client
I was responsible for had a serious problem in that the system in question
was in use from 8 to 5, five days a week by in excess of 100 staff as a norm
and was expected to be available after hours until midnight from Monday to
Friday. When the revised system was ready for testing and conversion we were
told in no uncertain terms that the problem was ours, not theirs, and we
would have to find a method to correct the situation without taking the
operational system off-line for more than a week-end. Since the chances of
that happening were remote ( there were 100's of programs in the system and
some 50 to 75 files that would have to be converted) a different solution
was needed. The user also refused to run parallel systems until the bugs
were ironed out of the revised system.

IBM, I think it was, defined an algorithm that could be inserted in each
program that read the date that made some basic assumptions about whether
the 'yy' should have a '19' or a '20' placed in front of it. It worked and
the proper solution was put off for another day. So, in a number of
instances the problem is still there it is just more hidden. Perhaps the
system users should bear some responsibility for that problem.

The real source of the "problem" is that a number of computerized systems
were spawned from the
days of the 80 column punch card where the use of non-essential columns was
not approved. Therefore,
those systems started off with 2-digit years and the problems became far
more then just adding two "columns" to the year field.

One of my favourite programs, which I use a lot for genealogy, has an
automatic date entry which enters todays date as 5 February 1107, and I
have
to go back and correct it. At least it can calculate the date correctly,
thoguht, unlike earlier versions of PAF, which report errors in the birth
and
death dates of anyone born or died after 31 Dec 1999

--
Steve Hayes
E-mail: [email protected] (see web page if it doesn't work)
Web: http://people.tribe.net/hayesstw
http://www.geocities.com/Athens/7783/

[Dennis Lee Bieber]

On Wed, 07 Feb 2007 11:20:55 +1100, Ron <[email protected]> declaimed
the following in soc.genealogy.computing:

In early 1970s I had a monthly service billing program with one digit
for anniversary year - it assumed any thing 5-9 was 196x and 0-4 was

The early versions of TRSDOS used just three BITS to store the year
in directory entries (remember, a 5.25" floppy only held around 180KB).
0=> 1977, 7=>1984. TRSDOS files had the common 8.3 name, but also two 8
character passwords (the Owner password was used to modify the
protection level [full, read/execute/modify/delete, r/e/m, r/e,
read-only, execute-only, no-access], and a User password that was needed
to access the file at the set protection level [it was common to leave
the user password blank, but one could set things up so that
"secretaries" needed to know a password just to run a program]).

Around 1982 or 83, an update to TRSDOS came out which got rid of the
user password field, meaning they now had space a full date, and larger
file systems.

Some pre2000 programs would have had 2 digits years with something like
my one digit year - anything 66 plus was 19xx and hence 0-65 would be 20xx

On my previous program we did not have authorization to extend the

file format (the data was shared between government organizations that
were equipped for a record length of X). So all the code had to be
internally modified to take (19)51 -- (20)50 instead of (19)00 --
(19)99. Fortunately the nature of the data meant that there were no
dates prior to the mid 70s to begin with.
--
bieber.genealogy Dennis Lee Bieber
HTTP://home.earthlink.net/~bieber.genealogy/

[Dale DePriest]

Steve Hayes wrote:

On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid
wrote:

On Tue, 06 Feb 2007 06:50:40 +0200, Steve Hayes
[email protected]> wrote:

On Tue, 06 Feb 2007 02:41:36 GMT, "Charlie" <[email protected]> wrote:

"Steve Hayes" <[email protected]> wrote in message
Computers had enough memory to deal with it from the early 1980s, but
short-sighted programmers still only allocated enough memory for two-digit
years.
Being one of the short-sighted programmers referenced in your post, perhaps
you may want to cogitate upon a couple of issues related to that presumed
short-sightedness.

First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.
That in itself seems fairly shortsighted. Even if the program were replaced,
in many instances people would want to keep the data.

When there is only 1.4K (yes 1.4K) of main (and no other) storage,
every BCD character (not byte) matters. Fitting a program into 1.4K
some 38 years before the millennium may have merited many descriptions
but shortsighted was never one of them.

I was thinking more of programs developed AFTER the Sinclair ZX 80.

And what's going to happen to Unix programs after 2038?

Well there were lots of machines older than that. A surprising number of
programs were written in Cobol (even today) and the language itself
encourage a 2 digit year. Initially that was all it even supported, I
believe.

Unix will be saved by 64 bit machines. Note that Unix and for that
matter Windows uses a clock that counts seconds from an arbitrary point
and the 32 bit number used to store that value in unix will overflow in
2038. Windows started later so the overflow with be further in the future.

Dale

--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs

[Dale DePriest]

Ron wrote:

Amazing how could genealogy software employ any algorithm for date - it
should allow for full millennium input (ok what about BC)

Calendar programs are very complex on dates - having to allow
calculations for Easter etc- and much the same should be in genealogy
program

My program does permit BC dates although I do not believe GEDCOM defines
a date in this range.

Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs

[David H Wild]

In article <[email protected]>,
Dale DePriest <[email protected]> wrote:

And what's going to happen to Unix programs after 2038?



Well there were lots of machines older than that. A surprising number of
programs were written in Cobol (even today) and the language itself
encourage a 2 digit year. Initially that was all it even supported, I
believe.

Unix will be saved by 64 bit machines. Note that Unix and for that
matter Windows uses a clock that counts seconds from an arbitrary point
and the 32 bit number used to store that value in unix will overflow in
2038. Windows started later so the overflow with be further in the
future.

There is a problem with the overflow only when the program is taking dates
from the machine. For many programs what is being recorded is "historic"
dates - such as when someone started work or moved house. In theses cases
all dates will be from data input, and this is where many programs fell
down by working only with two-digit years.

--
David Wild using RISC OS on broadband

[T.M. Sommers]

Steve Hayes wrote:

On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid

And what's going to happen to Unix programs after 2038?

By that time, time_t will be 64 bits. The only problems will be
with programs that assume time_t is 32 bits, and with programs
that store time_ts. The former should be fixed now. The latter
category would include system accounting software and
filesystems. However, there is no need to rush into fixing
either of these. It is not likely, for instance, that any
filesystem existing today will still be around in 30 years.

--
Thomas M. Sommers -- [email protected] -- AB2SB

[Steve Hayes]

On Wed, 07 Feb 2007 09:07:37 -0800, Dale DePriest <[email protected]>
wrote:

Steve Hayes wrote:
On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid
wrote:

On Tue, 06 Feb 2007 06:50:40 +0200, Steve Hayes
[email protected]> wrote:

On Tue, 06 Feb 2007 02:41:36 GMT, "Charlie" <[email protected]> wrote:

"Steve Hayes" <[email protected]> wrote in message
Computers had enough memory to deal with it from the early 1980s, but
short-sighted programmers still only allocated enough memory for two-digit
years.
Being one of the short-sighted programmers referenced in your post, perhaps
you may want to cogitate upon a couple of issues related to that presumed
short-sightedness.

First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.
That in itself seems fairly shortsighted. Even if the program were replaced,
in many instances people would want to keep the data.

When there is only 1.4K (yes 1.4K) of main (and no other) storage,
every BCD character (not byte) matters. Fitting a program into 1.4K
some 38 years before the millennium may have merited many descriptions
but shortsighted was never one of them.

I was thinking more of programs developed AFTER the Sinclair ZX 80.

And what's going to happen to Unix programs after 2038?



Well there were lots of machines older than that. A surprising number of
programs were written in Cobol (even today) and the language itself
encourage a 2 digit year. Initially that was all it even supported, I
believe.

I'm sure there were lots of machines older than that, but how many of them had
genealogy programs available for them?

One of the earliest genealogy programs I knew of was Roots, which ran entirely
in memory, and so was fairly limited in what it could accomplish. I had to fit
my family in by usung four separate files.

Unix will be saved by 64 bit machines. Note that Unix and for that
matter Windows uses a clock that counts seconds from an arbitrary point
and the 32 bit number used to store that value in unix will overflow in
2038. Windows started later so the overflow with be further in the future.

Dale

--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[Steve Hayes]

On Wed, 07 Feb 2007 13:43:23 -0500, "T.M. Sommers" <[email protected]> wrote:

Steve Hayes wrote:
On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid

And what's going to happen to Unix programs after 2038?

By that time, time_t will be 64 bits. The only problems will be
with programs that assume time_t is 32 bits, and with programs
that store time_ts. The former should be fixed now. The latter
category would include system accounting software and
filesystems. However, there is no need to rush into fixing
either of these. It is not likely, for instance, that any
filesystem existing today will still be around in 30 years.

I am using a genealogy program that I started using 20 years ago.


--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[T.M. Sommers]

Steve Hayes wrote:

On Wed, 07 Feb 2007 13:43:23 -0500, "T.M. Sommers" <[email protected]> wrote:
Steve Hayes wrote:

On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid

And what's going to happen to Unix programs after 2038?

By that time, time_t will be 64 bits. The only problems will be
with programs that assume time_t is 32 bits, and with programs
that store time_ts. The former should be fixed now. The latter
category would include system accounting software and
filesystems. However, there is no need to rush into fixing
either of these. It is not likely, for instance, that any
filesystem existing today will still be around in 30 years.

I am using a genealogy program that I started using 20 years ago.

Probably not on the same hard drive, though.

--
Thomas M. Sommers -- [email protected] -- AB2SB

[Steve Hayes]

On Fri, 09 Feb 2007 14:22:02 -0500, "T.M. Sommers" <[email protected]> wrote:

Steve Hayes wrote:
I am using a genealogy program that I started using 20 years ago.

Probably not on the same hard drive, though.

No.

It started off on a 20 Meg drive with a faulty controller, and I had to keep
replacing records that got corrupted. When upgraded to a 30 Meg RLL drive,
that problem disappeared.


--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk