Watching Dash Langan self-destruct 
Author Message
 Watching Dash Langan self-destruct


Quote:

>Dash Langan offers up a fairly decent stop-gap windowing technique

.. some of Dr. Peter Crane's feel-good pop-psych.  (he's the
illegitimate half brother of Neils and Frasier,  One of my favorite TV
shows.)

Quote:

>Good luck and good health Dash ... watch that {*filter*} pressure! :-)

>Peter

Of the few hundred legacy code-crankers I know by name, there are
perhaps thirty assembly language mechanics, Of them, three have died.
The first was a fellow named Rick Drimmer who had both an esteem issue
and a temper that caused him to lash out at others.

Rick died chasing some neighborhood pranksters.  The kids did something,
I don't recall what the Washington Post reported.   And Rick chased them
in his car, had a heart attack or stroke (the details don't matter) and
died because of his anger.

I knew Rick from the Planning Research Corporation, we were both systems
programmers on an MVT to MVS conversion job for the U.S. Government in
the 1970's.  The contract was slightly mismanaged and Rick quit by going
home mad at the project manager (who could have been Dilbert's boss but
since this was the 1970's, I called him 'Darth' and made whooo-whooosh
sounds with my hands cupped over my mouth when he left the area. )

But back to Rick, he didn't come back to work and some of us tried to
contact him.  He didn't take calls and after a month sent a 'resigned
due to health' letter.

Ten years after that, the DC area Wizard's grapevine was a-buzz when
the Washington Post reported that a Rick Drimmer died chasing some
pranksters.

About 6 years ago, another local assembly language cranker died, this
was John Duke, who was also wired as tight as a drum.  John liked to
pretend that he was gods gift to the world of computing.  Heavy esteem
issues, stiff as a board, no sense of humor, like Rick you could see the
veins throbbing in his temples.  He stroked out or had a heart attack.

I worked with John Duke at Infodata Systems Inc. in the mid 1980s.

What Peter said in prose, I'm telling you with stories from my personal
experience,  I've seen anger kill two programmers, it ain't worth it.
Both Rick and John were relatively young, both died in their late
thirties or early forties.

I don't ascribe to the pop-psych shtick but I've seen anger kill.
While lots of us had good reason to be mad at the PRC project manager,
we didn't box the anger in and live on Maalox like Rick did.  I started
calling him 'Darth' and making the 'whooo-whooosh' sounds and that
helped lots of us put it in perspective.   His name was 'Jack' and he
wore a hearing aid.  I used to warn the computer operators, when they
started making the 'whooo-whooosh' sounds, that Jack could hear from his
office into the computer room with his bionic ear.   I also called him
'Black Jack' which he liked but when he was a little distance away, I'd
call him 'Fat Jack', he never knew the difference.

I second Peter's good luck and good health.  Laugh at yourself a little.

Cory Hamasaki       http://www.*-*-*.com/
HHResearch Co.     OS/2 Webstore & Newsletter

1,011 days to go.



Sat, 11 Sep 1999 03:00:00 GMT  
 Watching Dash Langan self-destruct

Quote:

> T'is a sad sight indeed *sigh*

> Dash Langan offers up a fairly decent stop-gap windowing technique that has
> validity for some systems which A) process a limited range of dates, and B)
> are probably scheduled for replacement within the next decade or so.

Uhhh, where were you when I pointed out that the "Open and Shut
Window Technique" can last indefinitely?  Where did you get
this stopgap stuff (although the technique can be used on
that basis)?

Quote:
> Unfortunately, he also chooses to take potshots at the programming profession
> in the same presentation in newsgroups whose readership is primarily ...
> programmers!

Unfortunately, I have encountered the necessity of taking potshots
at crackpots.

Quote:

> He asks for comments.

> I comment that his proposal, while not a Dash Langan original, has some value
> in some systems but that he should polish up his presentation and marketing
> skills (you shouldn't insult the potential buyer, or the person who influences
> the decisions of the potential buyer).

I am not out to sell anything to programmers.  Haven't you discerned
this by now?

Quote:
> Instead of a professional response
> along the lines of "perhaps you are right" or "no, I think you are wrong
> because...", Dash goes ballistic in his "Reply to Peter Clark's Garbage".

"Perhaps you are right???"  Why should I tell a boldface lie?
I don't remember ever going ballistic.  How did you ever come to
that characterization?

Quote:

> Others (including some of the most respected contributors to these newsgroups)
> also hazard to venture an opinion

The most respected "professionals" in a typical D.P. department leave
a trail of disasters and assorted, sordid cover-ups behind when they
eventually unceremoniously slip out.  This newsgroup is no different
from the big laboratory known as the real world.

... does Dash act like a professional we

Quote:
> could possibly glean valuable Y2k techniques from? Uh huh nope ... Dash rips
> them to shreds

Take a second look.  I reply in kind.

Quote:
>... not in reasoned argument or in professional discourse, but
> like a ten year old having a temper tantrum.

I sure do get a lot of laughs out of these alleged tantrums.

Quote:
> With each ill-tempered post,
> Dash's credibility plummets (and possibly with it, chances that anyone will
> take his Open and Shut Windowing presentation seriously).

Look, whoever elects not to take any valid suggestion seriously does
so at his own detriment and risk.

Quote:

> It is truly sad to see someone coming apart at the seams like this.

Get real.  If anyone is coming apart at the seams, it is Peter Clark.
I am just going to take this posting as yet another opportunity to
present the "Open and Shut Window Technique" to new readers.  

Our type does not implode nor explode;  we are, however, quite well
known for our belligerence.  Live with it!  You will whether you
want to or not!

Quote:
> Maybe we
> should all pat Dash on the head, give him a lollipop, tell him what a good boy
> he is and maybe, just maybe, he will regain his professional decorum.

If you mean that I should conform to the prevailing standards of
D.P. professional decorum, then I pass.  I don't wish to burn in
eternal hell.

Quote:

>  Laugh at yourself a little.

I'm too busy laughing at the likes of you!

Anyway, the "Open and Shut Window Technique" follows:

Please read this document to the end.  Some important content
is near the end.

This approach will

    1.) eliminate the need for file conversions
    2.) allow you to move individual programs into
        production as they are converted indepen-
        dently of the status of other programs
        (great from an standpoint of keeping things
        organized)
    3.) work for all languages and all data access
        methods and databases
    4.) work for batch and on-line systems
    5.) work for subsequent turns of century
        (as far as 2100 not being a leap year, you
        are on your own with this minor glitch)
    5.) not involve the reformatting of input
        screens unless desired
    6.) not involve the reformatting of output
        reports unless desired

This approach will work for systems whose active
two-digit years do not span more than 50 years,
such as motor vehicle systems (aside from birth-
dates which should already be carried with 4
digit years), manufacturing systems, payroll
systems, order processing systems, and many, many
others.  (Note:  you can also use this approach
partially to buy you more time for a different
permanent solution if the range of active dates
in your system is greater than 50 years but less
than app. 90 years,)

Where you will primarily run into problems in a
program is in date comparisons, however, the
problem exists ONLY when the two dates are in
different centuries, otherwise the existing code
is adequate.  You make the distinction by having
a convention whereby all two digit years less
than n are new century years and all other years
are old century years.  n may be 10 or 50 or
whatever works for your particular system and
whatever you feel comfortable with.

Here is the logic for date comparisons:

If both dates are in the same century, execute
existing logic as is, otherwise, if year1 < year2,
then GOTO the existing GREATER-than logic for
date1 being greater than date2, else GOTO the
existing LESS-than logic for date1 being less
than date2.  Don't expand the years by prefixing
them with 19 or 20; there is no need to do so.

If you are looking for more, there isn't much
more to it than that.  When you are well into
the new century and all the active dates in the
system are new century dates, then go into your
programs and comment out the logic above and
recompile.  Then as you approach the next turn
of the century, uncomment out the comments making
the code active again!  (Save your screams.  Wait
to see what's below.)

You will also have to insert some correcting
code where you calculate the number of days
between two dates.  Here, if both dates are in
the same century just execute the existing code.
Otherwise expand the the new century year to
three digits by prefixing it with a 1 and
expand the old century year by prefixing it
with a 0.  Find the difference between the two
years, and GOTO the appropriate point in the
existing code beyond the point where the dif-
ference was calculated originally.

Again, at an appropriate time in the future,
comment out the code, recompile, and at the next
turn of century uncomment out the code and reuse
it.

You may have a situation where you are browsing
a KSDS VSAM file which is in key sequence accord-
ing to dates.  You are going to have to insert
modification code to end the browse at the end of
the records for year 99 and then restart the
browse for the records for year 00.

There may be situations where dates are used in
arithmetic calculations to come up with a VSAM
RRDS record number.  Depending on how the situ-
ation is handled, you may not need any correcting
code.  If you do, it should be as simple as the
other correcting code described herein.

With this approach, two digits years will always
be interpreted by humans as usual when they input
dates or when they read reports.  However, if you
so desire, you can modify your input programs and
output programs to use 4 digits years, but to
avoid file conversions, you will still carry the
dates in two digits in the files.  (Actually, having
the century prefixed to input and report output
dates will necessitate extra logic for keeping it
working into the 2100's, so it is recommended to
dispense with this for simplicity's sake.)

Remember to keep your correcting code well
contained for the convenience of commenting and
uncommenting it out in the future.  And be sure to
put liberal **** asterisk blocked **** documenting
comments to this effect.

Well, maybe you don't want to comment and uncomment
the code.  A convenient way to determine if your
two dates are in different centuries (and if
your correction code should be executed) is to check
the absolute value of the years' difference.

So now your correction code for date comparisons
will look something like the following.  (Remember,
all dates to be compared must not span more than
50 years, otherwise the following will not work
properly!)

* Note:  vertical lines: "| |" surrounding "year1 - year2" below
* indicate absolute value of the difference of year1 and year2.
IF |year1 - year2| is greater than 49
   IF year1 is less than year2
      GOTO date1-is-greater-so-goto-existing-greater-than-logic
   ELSE GOTO date1-is-lower-so-goto-existing-lower-logic.
* Continue with next program instruction as it was originally.

Some reports will be printed with the data for
the new century dates preceding the old century
dates.  But this is just a minor inconvenience
which will go away when all dates in the system
are in the new century.  Also, it is my under-
standing that if you put your data through
Syncsort, you can specify sort parameters which
will eliminate this problem.


Dash Langan



Sun, 12 Sep 1999 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Self destructing app

2. tk: canvas, dashes, dash patterns, and Windows (sigh)

3. destructed ntx dababase

4. local variable not destructed if the function raised a exception

5. how do i destruct a variable

6. ms vrml viewer beta 3, self destruct on 24/8 help!

7. Self-reproduction or self-changing of Web pages

8. Self-reproduction or self-change of Web page

9. Self-reproduction or self-changing of Web pages

10. self-replicating-code, self-replicating-messages

11. UserList.__getslice__(): copy.copy(self.data) vs. self.__class__(self.data).

12. Buggered image in VW (sorry, I just watched Notting Hill)

 

 
Powered by phpBB® Forum Software