Cobol - The Great Date Debate [Was Re: Layout Hell-o]

Author

The Great Date Debate [Was Re: Layout Hell-o]

LX-i

2004-08-21, 3:55 am

SkippyPB wrote:

> On Wed, 04 Aug 2004 00:09:03 GMT, robert.deletethis@wagner.net (Robert
> Wagner) enlightened us:
>
>
>
>
> And if century is unneeded, then you have wasted two bytes.

The problem is that no one can look into the future and say "we'll never
need the century!" Right now, there is a set of programs I recently
inherited (due to internal reorganization). In the main record for that
subsystem, there is an "estimated delivery date" in the format YDDD.
The thought behind that was "oh, we'll never exceed 30 days or so, so
this will be fine."

Well, this record in involved in an interface with another system, which
has proven to be less than 100%. In fact, the reason it wasn't expanded
with the rest of the Y2K stuff is that the interfacing system didn't see
the need to do it. Well, now we have programs (both in development and
production) that are timing out because of the length of the chain it
has to walk on these records. There are some that are over 10 years
old, and the only way we have of knowing is the date stamp in the record.

Recent analysis showed that some of these up to three years old are
accurately showing as still open (a resync between both systems
demonstrated this). Now, I'm sure that the original designer thought
they were being "efficient", especially when this saved a whole
character per transaction. However, they have been shown to be very
short-sighted, as their original design is now being stretched past its
limitation.

Mr. Wagner had a point a few posts back (yes, I'm way behind - found out
we're expecting #3, and life has been crazy for the last few w

s) that
programmers had seemingly not learned their lesson from Y2K, and were
still trying to be "efficient" at the expense of flexibility of future
use. All he got in response were pedantic replies, but he has a very
valid point. In today's increasingly networked culture, there is
apparent folly by continuing to use proprietary "packed" formats (and
other such techniques) on external data stores. I realize that existing
designs may not be able to be redesigned (as I'm still trying to figure
out a way around my single-year dilemma). But for new development (as
indicated by Mr. Klein's analysis), instantiating this is just asking
for trouble down the road.

The key to this is how the data is exposed. I really like the concept
of the "integer of date" format. It seems to me to be no different from
most relational databases - they don't store the date in YYYY-MM-DD
HH:MM:SS.PPPPPP format, but they _expose_ it to the outside world that
way (or lots of different ways, depending on how you ask for it or how
you configure it). Without hex-editing the database's files, you can't
see the date in its "native" format. While you wouldn't dream of
sending a database repository to someone else (unless they had the exact
same version of software, but even then, it would be flaky), people
routinely try to exchange files created and maintained by COBOL programs
to people whose tools are often no more sophisticated that Notepad.

Ponder this... A programmer decides to use display usage on a
particular file. A few years on down the road, two mergers later, a new
manager decides they need to send that file to an external entity. Is
the system viewed as sluggish and inefficient, or responsive and flexible?

Remember - it's true that Mr. Wagner cannot see into the future - but
neither can any of the rest of either. For new development, in my
opinion, usage display (in files) or relational databases are the way to
go. They provide the greatest flexibility for future (unknown)
requirements.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-08-22, 8:55 pm

docdwarf@panix.com wrote:

> In article <HVvTc.15858$5s3.12357@fe40.usenetserver.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
> [snip]
>
>
>
>
> Gah... this is a variant of the Appeal to Universal Ignorance, usually
> mainfested as a crooned 'you never knoooo-oooooowwww!'.

Does that in any way change its truth? This isn't just some mindless
suggestion, though - it's based on lessons learned throughout several
years of software design. At least where I work (and I've heard this
taught in class as well), my job as a software developer is to read the
requirements from the user and try to decided what they are _really_
asking for.

I recently reviewed a requirement for a "switch" for an interface. I
asked the question - just because we have a switch for another
interface, does that mean we need one for this one? I was told, in
effect, to shut up and color, but it's my job to completely understand a
requirement, so I can provide a system that is responsive to their
current needs, and flexible for perceived future needs.

>
>
> This was similar to a problem Mr Hamasaki found in a system that was using
> single-digit years... it blew up the first time it tried to span a decade.
>
>
>
>
> Gah... systems do not see needs, *people* do.

Okay - "the user community for the interfacing system didn't see the
need to change their system."

>
>
> Bingo. '... their original design is now being stretched past its
> limitation.' Consider: two people get married and buy a compact car;
> this carries them fine. Next a child comes along, the car can still carry
> them and their groceries... no sweat. Then comes along another child...
> what might seem to be a reasonable conclusion?

Either buy a bigger vehicle (sedan, mini-van, SUV, etc.), or rent a
larger vehicle for times when they need more space.

> A reasonable conclusion is that either you get a new car or resign
> yourself to making a lot of extra trips, in essence you redesign the
> solution to your transportation needs. Note that this instance is not one
> of timespan but of 'system volume'... but the conclusion is the same;
> needs have changed to the point where redesign is necessary.
>
> The original system's design might have exceeded the original system's
> requirements; it is not the original system's fault that someone decided
> to try to accomodate the needs of a multi-child family with a compact car.

Right. But it is _my_ fault if I don't learn from that, and make my
designs for future systems more accommodating. And, although it's not
the other system's "fault" per se, I still believe I'm justified in
calling the design short-sighted. I can't believe they didn't have
problems with this during the 1989/1990 rollover or the 1999/2000
rollover. The fact is, they did, but no one (on their end) saw it as a
big enough deal to justify a software change.

>
>
> Likewise, ponder this: a couple gets married and immediately buys the
> largest minivan that's on the market... after all, a few years down the
> line they might have five kids and two Dobermans to ferry about, you never
> knoooo-ooooowwww.

By the time the fifth child comes along, that vehicle will probably have
deteriorated to the point that they need to buy a new one. However,
software isn't quite like a car. Maybe they could pay an extra $2K up
front for their compact car, with the understanding that if/when the
time ever arose that they needed seating for 7, the seats and storage
room would be there with no additional cash outlay. Bits don't
deteriorate, and especially with relational databases, you can carry
around extra capability without it being harder to get into a standard
parking space.

> Needs are evaluated and extrapolated... and systems are designed and
> implemented. If you then try to fit more folks into a compact car than it
> was designed for then the results wind up looking like clowns at a circus.

If you see software design as having to be as rigid as the physical
constraints of a vehicle, then I can see how you would feel that way.
Software developers in 2004 have one thing that the software developers
in 1974 didn't have - an extra thirty years of industry experience.
There are several lessons that one could learn from those 30 years.

One of the biggest lessons, in my opinion, is that systems are often
asked to do things well outside of the narrow scope of their original
requirements. Part of this is due to a lack of understanding between
the system procurers and the designers (often traced back to unclear
requirements). Part of it is also due to people using automated systems
and beginning to visualize other ways the system could meet their needs.
As a designer/developer, I feel that I would be doing a disservice to
my employer/client if I do not apply that knowledge, and design a system
that is flexible enough to do what they initially ask of it, and maybe
just a little bit more - *especially* when it comes to dates.

An example - I was asked to design and code software to allow a golf
"association" to track its members, sign them up for a tournament, place
the people into teams, calculate handicaps, score, and calculate payouts
for top scorers for each day, top scorer within skill level (A/B/C/D),
and overall top scorer. By adding a single foreign key to a few tables,
this application supports more than one organization in its _initial_
state. And, with a simple tweak, if organizations ever wish to share
members, a new table (initially populated with values from the current
Members table) would do it quite quickly.

Was I asked to make a multi-organization-supporting system? Not
initially. After the first tournament, the customer asked me what it
would take to get other golfing organizations loaded into it. Sounds
like I hit the nail on the head with that one. :) (Of course, there
was a little self-serving in that as well - I had hoped that they would
give me rights to the program, and they have. Now, _my_ job is easier!)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-08-22, 8:55 pm

docdwarf@panix.com wrote:
> In article <E95Uc.23224$5s3.1064@fe40.usenetserver.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> There is no way that truth or falsity can be determined... after all, 'you
> never knoooo-oooooowwww!'
>
> (Now you may see why I go 'Gah...'; Wittgenstein once said 'I do not know
> that I do not know' and, likewise, you never know that you never
> knoooo-oooooowwww!)

But you can make an educated guess. Is it smart to make all your dates
also have an associated time, down to 18 digits of precision? Probably
not. Is it a good idea to store off four digits for a year? In my
opinion, that answer is yes. If you answer no (and have a
requirements-based reason for answering no), you don't have a faulty
design - you just have an inflexible one.

>
>
> You and a goodly bunch of the rest of the Programming World... but there
> also comes a point where one must remember that there's no DWIM (Do What I
> Mean) command.

Which makes this job such fun. :) I'm glad I can still keep my fingers
in the code - if I had to go straight design, I'd probably go insane.
(Granted, that probably wouldn't be much of a trip...)

>
>
> Hee hee hee... you had to ask? Frequently the 'requirements' are
> generated for two reasons:
>
> A) 'They got one, now we want one, too!'
>
> B) 'Something like this did... *something* over there, and now everybody's
> talking about it... so maybe it'll do... *something* over here, too!'

Well, I suspected it to be along the lines of "A", and I was correct.
However, the interfacing system has the potential to process classified
information; our is unclassified. So, the requirement exists to "turn
the interface on and off" - but we did get them to agree to let us make
the decision on exactly how (the behind the scenes part) we would do that.

>
> With all due respect... is that in your job spec or a responsibility
> you've taken upon yourself?

Thanks... :) And, it's not in a written description, but it's expected
of each of us. My current project spans a couple of things - first, the
USAF's decision to change the F-22 to an A/F-22, and second, the USN's
decision to track some stuff from the CV-22 in our system. Right now,
our code is littered with checks like "IF MDS = ' F022A A' " or "IF MDS
= ' F0119100' " (that's the engine it uses) because they track their
parts differently from any existing aircraft in the USAF inventory.

The reason they were allowed to do this is that the regulation has
changed, and new aircraft have to follow the new standard. Enter the
CV-22 - they use the same type of stuff as the F-22. So, this project
entails pulling out all these checks, creating a lookup table, and
having the checks look at the table. Now, the original F-22 design was
complete (it works, and satisfied the requirement), but it was very
short-sighted. Quite expensive to go and make the change, but when the
Joint Strike Fighter comes along, it'll be much cheaper and much faster,
as the design is flexible enough to drop other yet-to-be-determined
aircraft into it.

(In fact, now that the "MDS" is now " AF022A A", the original code
doesn't even work. In the new design, that's a one-row change in a
relational table - total cost to the taxpayers of this great land, $.05
(or somewhere thereabout).)

>
>
> Ahhhhhh, that's better... now, reconcile the above with the Workplace
> Truism of 'A lack of planning and foresight on your part does not
> constitute an emergency on my part.'

Okay - but for some reason, the chain of command doesn't like hearing
that sort of stuff. Their users complain when the program times out,
and it's our fault because we *still* haven't fixed it, yet we can't get
the interfacing system's managers to make the change. I can't believe
it would be _that_ complicated of a change - they're in the same
environment our system is in.

>
>
> Oooooo... *someone's* been reading ahead!

heh - yes, I read ahead, but this intrigues me (and you didn't address
it). What is the parallel for "renting a larger vehicle" in the
software design world? (As an aside, we already do the multiple-trip
thing with this interface. The packets have a maximum size of around
3,000 characters, and they send us 80-character lines even when a CR/LF
will do. So, we sometimes get as many as 4 or 5 responses for one
transaction.

(Yes, I asked to inherit this interface - I'm making it my goal to
streamline it and make it more usable. There are programs that people
in the field have stopped using because they just don't work.)

>
>
> Again, with all due respect... I do not believe that you needed to learn
> that single-digit years are more trouble than their systemwide savings
> appear to merit.

Thanks again.... What I learned was not that, per se - it merely added
to something that I've been learning since I figured enough out about
this business to do design. Our systems are routinely asked to stretch
themselves past the point of their original requirement. :) Now, for
this particular case, a second digit would help us immensely. But, it
would still violate the standard that we have in every other place in
our database of storing a 4-digit year.

(What I also learned is that I have an opportunity to be really creative
and come up with a self-sliding 4-year window. I think I'll probably do
something using a 2-digit signed number...)

>
>
> There, you see? I was wrong, single-year digits do *not* generate more
> problems than their systemwide appear to merit... because this system went
> through two rollovers and is still ticking. Why was it not changed
> fifteen years back? In classic Managerspeak:
>
> 'Because it isn't worth the time to put into it, we have More Important
> things to deal with.'
>
> ... and for what reason was it not changed five years back? See above.

Just because the system didn't puke (well, it did - that's what brought
this to our attention) doesn't mean it isn't crappy design. :) And
besides, it only seems to be a problem for us, not them. Why *would*
their management see it as a need?

> Really? Consider the possibility of a couple of 'Irish twins', born nine
> months apart... and a set of 'genuine' twins and you've got five kids in
> five years. My current vehicle is eight years old and has 280K miles and
> change on it, the one I had before that I kept for a decade and it had
> 200+K miles on it... cars don't wear out like they used to, you can go
> (according to advertisements) 100K miles before a tune-up.

heh - not with Montgomery drivers... ;) But yes, you are correct,
_some_ cars do seem to last longer than they used to. (Last December, I
got stuck on the side of I-85 in my 1999 Grand Voyager with a dead
engine - well under 90K miles...)

>
>
> In that it is designed to ofer maximal performance at or below a given
> volume it is *very* much like a car.

Yes, but everything in a car is tangible. People don't expect their car
to have a pop-up calendar from which they can select dates, but they are
happy with the little sticker that JiffyLube puts on their windshield
reminding them when their next oil change is due, or the "time for a
tune-up" light that turns from green to yellow to red (on Hondas).

But, give someone a web page with a required date input field, and
people all of a sudden can't type 2004-08-16 (or 8/16/2004, or
16/8/2004) - "I've got to have a pop-up box where I click a block, and
it fills in the date for me."

Of course, talking about a car, there are those who attempt to push cars
beyond their designed limits - you usually hear about them on the news,
though. Not the same with software... :)

>
>
> Systems have associated costs of operation and design-parameters which are
> predicated on transaction volume. The kind of system an
> accoutant-down-the-street could use, profitably and happily, would be
> incapable of handling the sort of volume that even the smallest of the Big
> 8... errrr, 5... errrr, 3 deal with.
>
> The Big 3 don't use systems designed for one-person accounting shops...
> and one-person accounting shops don't need the overhead associated with a
> Big 3 office's code.

True. I guess that's where "knowing your customer" is very important.
As a USAF member, the USAF's interest in my work is making sure I
produce the longest-lasting, flexible, yet efficient, accurate, and
stable software I can. Now, a contractor may say something along the
lines of "well, this is what they asked for - I think they may need this
too, but I'll just do this really well and maybe I'll get the contract
when they figure out that they need this too."

I don't have that luxury. In fact, I've been asked a few times why I've
done things a certain way, and had to explain myself. The answers I
gave that delivered the least satisfaction are the ones that start with
"well, I was told to..."

>
>
> If there are not such constraints then the same software that single
> accountant uses would work most happily for one of the Big 3. It doesn't.
> You might want to speak with Mr Trembley about designing systems for
> utterly staggering quantities of data; try pushing a hundred million
> transactions through your Pentium and see if it bogs.

Heck, my Athlon locks up with Folding@home... :) We're looking a
2M/day (which, I realize, is small potatoes compared with some other
systems), which is more than we've ever thrown at the base-level version
of the system.

>
>
> Lessons like how to tailor a system to transaction volume? that could be
> done in 1974; some might argue that given the resource-expenses of those
> days it was done better then than now.

Not those lessons - yes, looking back at software development from the
1950s on forward, it's amazing what was accomplished before the chip
speed explosion and the world wide web. I'm not knocking older, mature
designs. What started this whole spin-off thread was my assertion that
storing dates and numbers with Display usage in files makes the design
of the system more flexible for yet-unknown requirements. Today, with
large, cheap disks, I have the luxury of saying that. In 1974, I
probably would be singing a different tune.

>
>
> Perfectly understood... bu there comes a point when redesign is necessary.
> Remember the auto example... a subcompact is fine for a couple, a couple
> and a kid, maybe even a couple and two kids... but there comes a point
> where a subcompact just won't do.

True as well. I understand that concept.

> As my first programming instructor asked the class, Zen-like:
>
> 'What is the first thing a programmer does when given an 80-byte record?'
>
> (pause for reflection and wrong answers)
>
> 'Reserve the last ten characters For Future Use.'
>
> ... and that will, truly, Hold The Fort... until more data are needed...
> or seen as being needed.

In every one of our network records, we have a "spare" field. Part of
that is to pad it out to an even word boundary (4 ASCII character, on
the Unisys 2200), but part of it is for future use. My supervisor is in
charge of maintaining the requirements for every single field in the
database (quite an impressive little folder he's accumulated over the
years), and when a character or two from the spare field becomes pressed
into service, he documents it. Next major release, we name all the
spare usage fields, change the (hopefully few) programs that use it,
then reallocate spares, again, "for future use."

Our relational tables have changed that concept, just because it's so
easy to add a column to one of those. We don't use "Select *", so we
won't impact existing programs.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-08-22, 8:55 pm

In article <HdaUc.23233$5s3.3255@fe40.usenetserver.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>But you can make an educated guess.

You can guess, sure... but you never knoooo-oooooowwww!

>Is it smart to make all your dates
>also have an associated time, down to 18 digits of precision? Probably
>not. Is it a good idea to store off four digits for a year? In my
>opinion, that answer is yes. If you answer no (and have a
>requirements-based reason for answering no), you don't have a faulty
>design - you just have an inflexible one.

You have a design for a system that runs in production, keeping users (and
maintenance-programmers before you) happy for a decade and a half... not
half shabby, neh?

[snip]

>
>Well, I suspected it to be along the lines of "A", and I was correct.

I've never seen the inside of your shop and I listed 'A' as 'A'... but
that might be due to the fact that I have worked in a few shops, here and
there... and in each one of them 'Things Are Different Here'...

.... and if everywhere things are different then everywhere things are the
same.

>However, the interfacing system has the potential to process classified
>information; our is unclassified. So, the requirement exists to "turn
>the interface on and off" - but we did get them to agree to let us make
>the decision on exactly how (the behind the scenes part) we would do that.

How very kind of them... looks like you got away with doing this one Right
but it might be best to try not to get any feelings of security about the
situation.

>
>
>Thanks... :) And, it's not in a written description, but it's expected
>of each of us.

Hee hee hee... it is only expected when the results you come up with are
expected; when you come up with unexpected solutions the reception might
be a bit... chillier.

[snip]

>
>Okay - but for some reason, the chain of command doesn't like hearing
>that sort of stuff.

It has been my experience that most folks who lack planning and foresight
don't like hearing that sort of stuff... might be Human Nature, who knows?

>Their users complain when the program times out,
>and it's our fault because we *still* haven't fixed it, yet we can't get
>the interfacing system's managers to make the change. I can't believe
>it would be _that_ complicated of a change - they're in the same
>environment our system is in.

It might be due to the fact that the task is of insufficient importance to
merit it's own job code and budget... and it lacks those because someone
without planning and foresight (but with control over budget) has not
allocated such things.

If it is important it is more likely that someone will spend a buck on
it... if it isn't important, if a raise or a promotion isn't depending on
it then one waits until one is issued a Round Too-it.

[snip]

>
>heh - yes, I read ahead, but this intrigues me (and you didn't address
>it). What is the parallel for "renting a larger vehicle" in the
>software design world?

Outsourcing your processing or buying time-shared resources.

[snip]

>(Yes, I asked to inherit this interface - I'm making it my goal to
>streamline it and make it more usable. There are programs that people
>in the field have stopped using because they just don't work.)

Not a bad reason to stop using them, aye.

[snip]

>
>Thanks again.... What I learned was not that, per se - it merely added
>to something that I've been learning since I figured enough out about
>this business to do design. Our systems are routinely asked to stretch
>themselves past the point of their original requirement. :)

Hmmmmm... that's like the classic 'I always give 110%, all the time!'...
but if you do it all the time then 110% becomes 100%.

>Now, for
>this particular case, a second digit would help us immensely. But, it
>would still violate the standard that we have in every other place in
>our database of storing a 4-digit year.
>
>(What I also learned is that I have an opportunity to be really creative
>and come up with a self-sliding 4-year window. I think I'll probably do
>something using a 2-digit signed number...)

Ummmmm... last time I looked a single digit can hold any one of 255
distinct values, X'00' through X'FF'... but don't let that give you any
ideas.

>
>
>Just because the system didn't puke (well, it did - that's what brought
>this to our attention) doesn't mean it isn't crappy design. :)

IF PROGRAM-RUNS PERFORM NEXT-ASSIGNMENT
ELSE PERFORM CODE-LIKE-HELL UNTIL DAMNED-THING-WORKS.

If it runs and gives the results that make the person who has say over
signing checks for the system smile... then it runs.

>And
>besides, it only seems to be a problem for us, not them. Why *would*
>their management see it as a need?

There is no 'us', there is no 'them'... there is no 'I' in 'team',
remember? We're all in this together and if one of us has a problem then
*all* of us have a problem.

(You want to see a Major turn red and shoot eye-daggers at you then feed
him this same kind of crap that he feeds you.)

>
>
>heh - not with Montgomery drivers... ;) But yes, you are correct,
>_some_ cars do seem to last longer than they used to. (Last December, I
>got stuck on the side of I-85 in my 1999 Grand Voyager with a dead
>engine - well under 90K miles...)

Sometimes a car's made on Friday, aye.

>
>
>Yes, but everything in a car is tangible. People don't expect their car
>to have a pop-up calendar from which they can select dates, but they are
>happy with the little sticker that JiffyLube puts on their windshield
>reminding them when their next oil change is due, or the "time for a
>tune-up" light that turns from green to yellow to red (on Hondas).
>
>But, give someone a web page with a required date input field, and
>people all of a sudden can't type 2004-08-16 (or 8/16/2004, or
>16/8/2004) - "I've got to have a pop-up box where I click a block, and
>it fills in the date for me."

This seems to be a sort of 'Prelude to Feature Bloat'... 'Well, it's all
right, but I *really* need this... well, now it's OK, but I really need
*that*... it looks pretty good but I really need *the other thing*...
wow, this is really complex, can't you simplify it somehow?'

>
>Of course, talking about a car, there are those who attempt to push cars
>beyond their designed limits - you usually hear about them on the news,
>though. Not the same with software... :)

There are organisations that try to push software beyond limits... and you
read about them in the Finance Pages, going belly-up or being taken over.

[snip]

>
>True. I guess that's where "knowing your customer" is very important.

I disagree. Knowing the job to be done is very important; whenever I get
ask about system design my *first* question is:

I think it can be done... but tell me, what's your expected transaction
volume?

>As a USAF member, the USAF's interest in my work is making sure I
>produce the longest-lasting, flexible, yet efficient, accurate, and
>stable software I can.

The USAF appears to be no different from any other organisation in this
regard.

>Now, a contractor may say something along the
>lines of "well, this is what they asked for - I think they may need this
>too, but I'll just do this really well and maybe I'll get the contract
>when they figure out that they need this too."

.... or an employee can say 'Hey, I'll get away with this for now... and by
the time it's discovered I'll be promoted/transferred and it'll be someone
else's headache'. Neither is unique.

>
>I don't have that luxury. In fact, I've been asked a few times why I've
>done things a certain way, and had to explain myself. The answers I
>gave that delivered the least satisfaction are the ones that start with
>"well, I was told to..."

Hee hee hee... when you conform to my orders how *dare* you invoke the
Nuremberg Defense?

[snip]

>
>Heck, my Athlon locks up with Folding@home... :) We're looking a
>2M/day (which, I realize, is small potatoes compared with some other
>systems), which is more than we've ever thrown at the base-level version
>of the system.

Has anyone thought about renting some equipment - or some time on other
equipment - and running some heavy-volume testing to see what will bring
it to its knees? Naaaaaahhhhh... that Costs Money!

('But bringing the system to a standstill due to unexpected responses to
unprecedented volume will Cost Money, too!' 'You ain't paid to think,
soldier... just Make It Work.')

[snip]

>
>True as well. I understand that concept.

Understanding's the first step... applying what was learned the next.

>
>
>In every one of our network records, we have a "spare" field. Part of
>that is to pad it out to an even word boundary (4 ASCII character, on
>the Unisys 2200), but part of it is for future use. My supervisor is in
>charge of maintaining the requirements for every single field in the
>database (quite an impressive little folder he's accumulated over the
>years), and when a character or two from the spare field becomes pressed
>into service, he documents it. Next major release, we name all the
>spare usage fields, change the (hopefully few) programs that use it,
>then reallocate spares, again, "for future use."

As the Germans say, 'plus ca change, plus c'est la meme chose'.

DD

Richard

2004-08-22, 8:55 pm

docdwarf@panix.com wrote

> Ummmmm... last time I looked a single digit can hold any one of 255
> distinct values, X'00' through X'FF'... but don't let that give you any
> ideas.

Perhaps you take a more recent look, they seem to have managed to
stuff another one in there somehow.

docdwarf@panix.com

2004-08-23, 3:55 pm

In article <217e491a.0408162302.66ba1014@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote
>
>
>Perhaps you take a more recent look, they seem to have managed to
>stuff another one in there somehow.

What a wonderful world it is that has new things to learn in it! I should
apologise for my loose usage above, though; when I said 'digit' I intended
'character', as the examples I gave indicate.

DD

docdwarf@panix.com

2004-08-23, 3:55 pm

In article <FXxUc.24781$5s3.6269@fe40.usenetserver.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>
>Okay - fine. You never knooooo-oooooooooooowwwww! :)

Gah... that is the Appeal to Universal Ignorance.

[snip]

>
>No, it hasn't. I've been told that this has been a problem for over a
>decade, and hasn't been addressed.

It might be good to remind someone that a problem that is not addressed
can be similar to a bank-account that is not addressed... it seems to
slumber but it actually gathers 'interest'.

[snip]

>
>heh - we'll probably end up putting a switch on a screen anyway. The
>other option involves destruction of interface settings, which would
>then have to be remembered and reloaded by a human later on down the
>road.

Relying on a human being to know how to do something, remember when to do
something and actually do it runs perilously close to violating the Mac
Truck theory.

>What we've finally gotten is a retired CMSgt who used to use this
>system on the flightline - he understands what the user wants, and he
>also has enough experience with us as a development team that he's
>beginning to trust what we tell him.
>
>But, I know that could change in the morning...

Not as long as you keep him drunk.

>
>
>I've come up with several solutions that weren't accepted. In fact, one
>made it into the code baseline on accident, and then promptly died.

'I want someone who's made all the mistakes... on someone *else's* dime.'

>
>The problem is that these folks often aren't the same folks who made the
>earlier edict.

Ahhhh... regime change! Watch out, next comes calendar reform.

>Today, I looked at some code that the user swore up and
>down shouldn't be spacing out a field under that condition. But, the
>two lines that spaced out the field were clearly footprinted as being
>entered into the system in 1993, due to a duly documented requirement.

'Whaddaya mean, we asked for it ten years ago... that was ten years ago,
you can't hold us to what we said back then... and what about *this*
difficulty over here, we've been talking about that since *forever*...
whaddaya mean, 'forever' is longer than ten years so you're not going to
hold to it?'

>
>
>That's the rub in all this. Right now, I have a short window of
>round-tuitiveness. By the time enough people far enough up either chain
>get riled up enough about it, I'll be up to my neck in the next project.

If someone of sufficient authority feels sufficiently strongly about your
work-assignment then it might change.

> I was more venting than anything else (although I'd fix it in a
>heartbeat...)

Pardon me for my innate problem-solving views.

>
>
>Ah... Thanks.

Anytime.

[snip]

>
>:) It may (although our compiler doesn't support hex literals)...

Doesn't have to... define an 8-byte binary field, REDEFINE it as a PIC X.

0000 0000 = X'00', add 1 to get
0000 0001 = X'01', add 1 to get
0000 0010 = X'02', etc.

Since you are dealing with an ASCII numeric field for your year you'd lose
everything between X'00' and X'29'... but start working with X'40' and you
have something that could be made to work for the next 215 years or so...

.... but don't let that give you any ideas.

[snip]

>
>heh heh...

Glad you enjoyed.

>
>
>Oh, is that it? I guess I should add that to the list of questions to
>ask dealers when I'm shopping for a car! ;)

That's the Common Knowledge I was taught - 'Never buy a car made on Friday
or Monday, Friday they're sloppy because they're looking to get out,
Monday they're sloppy because of hangovers' - but I do not know of
statistical data to support it.

[snip]

>
>heh - that's the truth. "Add this option. Add the other option. Okay,
>now add these three options, and put these two as sub-options under the
>4th option."
>
>"Man, this thing just has too many options!"

See above about holding someone to what they said.

>
>
>hey - deficit spending is

! (Especially deficit *defense* spending!)

Remind your landlord of that the next time he finds out you gave him a
Goodyear check.

[snip]

>
>True - but do they have 24/7 contracts on their employees, that state at
>any given time they'll willingly give their lives obeying the orders of
>their superiors?

The USAF appears to be slightly different from many other organisations in
that regard.

(small joke - there are military offices in the building which houses my
current client; today I was riding the elevator down and a lass wearing
blues and a set of railroad-tracks got on. I looked at him and said in my
best Official Voice -

'Beg pardon, sir, but I gotta tell ya... I spent a little time at Lackland
a few decades back and... I just can't believe how young they're making
Captains nowadays.

>
>
>I guess I'm just idealistic. Either that, or a darn good catch for an
>employee... :)

'An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.' - H L Mencken

[snip]

>
>That's the fear amongst the managers - how long until it dies?

Behavior modification is a whole 'yuther kettle of wax.

DD

LX-i

2004-08-23, 3:55 pm

docdwarf@panix.com wrote:
> In article <FXxUc.24781$5s3.6269@fe40.usenetserver.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> Gah... that is the Appeal to Universal Ignorance.

Well, "ignorant" can be a fitting adjective at times - address your
audience and all that sort of thing...

>
> It might be good to remind someone that a problem that is not addressed
> can be similar to a bank-account that is not addressed... it seems to
> slumber but it actually gathers 'interest'.

heh - interest rates are at an all-time high! Today we got several
field calls about document numbers (containing the aforementioned
1-digit year) that "all of a sudden" showed up on their reports.

(As an aside, I also learned that there is a resync process that's
supposed to be run once a month - but, obviously, folks don't seem to be
doing that. This whole thing may come down to a policy issue, and not
so much a code issue (although I still need to solve the decade
expansion, or we can't do anything on December 31st every four years...))

>
> Relying on a human being to know how to do something, remember when to do
> something and actually do it runs perilously close to violating the Mac
> Truck theory.

true...

>
> Not as long as you keep him drunk.

:) I'll pass that along to him - he'll get a kick out of that.

>
> 'I want someone who's made all the mistakes... on someone *else's* dime.'

I'm your guy, then. Oh, no wait - it's _your_ taxes that pay _my_
salary. I'm screwing up on *everybody's* dime! (Well, except the
almost 50% of folks who don't pay any Federal income tax...)

>
> Ahhhh... regime change! Watch out, next comes calendar reform.

heh - we're working on that....

>
> 'Whaddaya mean, we asked for it ten years ago... that was ten years ago,
> you can't hold us to what we said back then... and what about *this*
> difficulty over here, we've been talking about that since *forever*...
> whaddaya mean, 'forever' is longer than ten years so you're not going to
> hold to it?'

Well, wouldn't you know it, in looking at that, they found something
else that was actually broken.

>
> If someone of sufficient authority feels sufficiently strongly about your
> work-assignment then it might change.

heh - it looks like my coding dance card is going to be pretty full
through the next few months. Today our high-level design was approved
for our next project, so we'll begin detailed design and coding shortly.

>
> Pardon me for my innate problem-solving views.

Oh, no problem - if I wasn't interested, I wouldn't have carried on the
conversation this long. I do the same thing. :)

>
> Doesn't have to... define an 8-byte binary field, REDEFINE it as a PIC X.
>
> 0000 0000 = X'00', add 1 to get
> 0000 0001 = X'01', add 1 to get
> 0000 0010 = X'02', etc.
>
> Since you are dealing with an ASCII numeric field for your year you'd lose
> everything between X'00' and X'29'... but start working with X'40' and you
> have something that could be made to work for the next 215 years or so...
>
> ... but don't let that give you any ideas.

heh heh - and if I make it smart enough to loop every hundred years, it
could work forever!

>
> That's the Common Knowledge I was taught - 'Never buy a car made on Friday
> or Monday, Friday they're sloppy because they're looking to get out,
> Monday they're sloppy because of hangovers' - but I do not know of
> statistical data to support it.

That sounds like a good science project for some bright kid. Get a
cross-reference of VINs and day of manufacture, then bounce it against
service records from a representative sample of dealerships. True,
you'd miss the do-it-yourselfers, but chances are you'd miss them in
equal proportions.

(Or, do it backwards - get the VINs and number of unscheduled
maintenance visits, then look up the day out of that database - it could
be fun - I'd probably give it an "A" if it followed the proper
scientific process...)

>
> Remind your landlord of that the next time he finds out you gave him a
> Goodyear check.

You (and the rest of the taxpayers of this great land) are paying my
rent for now, but I understand what you're talking about... :)

>
> The USAF appears to be slightly different from many other organisations in
> that regard.

:)

> (small joke - there are military offices in the building which houses my
> current client; today I was riding the elevator down and a lass wearing
> blues and a set of railroad-tracks got on. I looked at him and said in my
> best Official Voice -
>
> 'Beg pardon, sir, but I gotta tell ya... I spent a little time at Lackland
> a few decades back and... I just can't believe how young they're making
> Captains nowadays.

I thought I was the only one to notice. Mine was when they promoted
this kid to Major - he looked like a 16-year-old kid! Come to find out,
he's a year younger than me. Here I am a struggling E-5, and if I had
applied myself coming out of high school, I could be an O-4 by now.
Choices, choices...

> 'An idealist is one who, on noticing that a rose smells better than a
> cabbage, concludes that it will also make better soup.' - H L Mencken

That's great. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Howard Brazee

2004-08-26, 3:55 pm

On 18-Aug-2004, LX-i <lxi0007@netscape.net> wrote:

> I'm your guy, then. Oh, no wait - it's _your_ taxes that pay _my_
> salary. I'm screwing up on *everybody's* dime! (Well, except the
> almost 50% of folks who don't pay any Federal income tax...)

Some people don't pay Federal income tax directly. But anybody who buys
something from a company that pays Federal income tax - is paying indirectly.

Curtis Bass

2004-08-26, 3:55 pm

docdwarf@panix.com wrote in message news:<cfm40m$br5$1@panix5.panix.com>...
> In article <HVvTc.15858$5s3.12357@fe40.usenetserver.com>,
> LX-i <lxi0007@netscape.net> wrote:

>
> Likewise, ponder this: a couple gets married and immediately buys the
> largest minivan that's on the market... after all, a few years down the
> line they might have five kids and two Dobermans to ferry about, you never
> knoooo-ooooowwww.

Your analogy is seriously flawed, as it doesn't take the cost of
computer hardware vs. developer expense into account. If you want
your analogy to be a better, useful representation of the issue, then
"ponder" this: The biggest, most luxurious and _safest_ minivan they
could possibly buy cost ten cents more than the el cheapo car they
"should" be getting, and costs two bucks per year more to operate.

Now you have a quasi-valid analogy.

Curtis

docdwarf@panix.com

2004-08-26, 3:55 pm

In article <163715e7.0408251837.5266d697@posting.google.com>,
Curtis Bass <cmbass_us@yahoo.com> wrote:
>docdwarf@panix.com wrote in message news:<cfm40m$br5$1@panix5.panix.com>...
>
>
>Your analogy is seriously flawed, as it doesn't take the cost of
>computer hardware vs. developer expense into account. If you want
>your analogy to be a better, useful representation of the issue, then
>"ponder" this: The biggest, most luxurious and _safest_ minivan they
>could possibly buy cost ten cents more than the el cheapo car they
>"should" be getting, and costs two bucks per year more to operate.
>
>Now you have a quasi-valid analogy.

Now you have quasi-fabricated figures, as well... but hey, if you want to
make things up then be my guest. I fail to see how you are able to equate
the price-difference between a subcompact car (purchase and operating
costs) and a minivan with such absolute numeric values ('ten bucks' and
'two bucks', respectively); might you be so kind as to supply the numeric
base and calculations you used to arrive at the conclusion that the
difference between the two vehicles is approximately two hours' worth of
work at US minimum-wage rates and the annual operating expense difference
is less than a half-hour at the same rate, please?

DD

Curtis Bass

2004-08-26, 3:55 pm

docdwarf@panix.com wrote in message news:<cgkai6$c6l$1@panix5.panix.com>...
> In article <163715e7.0408251837.5266d697@posting.google.com>,
> Curtis Bass <cmbass_us@yahoo.com> wrote:
>
>
> Now you have quasi-fabricated figures, as well...

No, I have _purely_ fabricated figures, but that doesn't matter
because the numbers themselves aren't important. What's important is
that the numbers are _small_ and not what their actual values are.
The point is that your car analogy is flawed, because it assumes that
hardware is expensive, but it isn't. It's dirt cheap. Quibbling over
the exact numbers is essentially quibbling over "how cheap is cheap?"

> but hey, if you want to make things up then be my guest.

Thanks, I guess, but then, using an inappropriate analogy also
qualifies as "making things up", the way I see it.

> I fail to see how you are able to equate
> the price-difference between a subcompact car (purchase and operating
> costs) and a minivan with such absolute numeric values ('ten bucks' and
> 'two bucks', respectively); might you be so kind as to supply the numeric
> base and calculations you used to arrive at the conclusion that the
> difference between the two vehicles is approximately two hours' worth of
> work at US minimum-wage rates and the annual operating expense difference
> is less than a half-hour at the same rate, please?

As I said, the actual numbers aren't important. What's important is
the accuracy of the analogy, not the accuracy of the numbers. The
numbers are only a hand-drawn illustration, not a high-resolution
photograph.

The point is that the programmer who decides to use display-mode, as
opposed to packed, fields in an outgoing file is _not_ the equivalent
of childless newlyweds buying an expensive mini van. No, the
equivalent is the childless newlyweds getting that mini van for
_NEGLIGIBLE_ added cost, as insurance against whatever the future
brings.

> DD

Curtis

docdwarf@panix.com

2004-08-26, 3:55 pm

In article <163715e7.0408260657.562f3b90@posting.google.com>,
Curtis Bass <cmbass_us@yahoo.com> wrote:
>docdwarf@panix.com wrote in message news:<cgkai6$c6l$1@panix5.panix.com>...
>
>No, I have _purely_ fabricated figures, but that doesn't matter
>because the numbers themselves aren't important.

How interesting... I never knew that purely fabricated figures could make
for a quasi-valid analogy, learn something new every day.

>What's important is
>that the numbers are _small_ and not what their actual values are.
>The point is that your car analogy is flawed, because it assumes that
>hardware is expensive, but it isn't. It's dirt cheap. Quibbling over
>the exact numbers is essentially quibbling over "how cheap is cheap?"

All right... how cheap is the hardware necessary to process year-end
closings for one of the Big 8... errrr, 5... errr, 3 Accounting Firms?

>
>
>Thanks, I guess, but then, using an inappropriate analogy also
>qualifies as "making things up", the way I see it.

A simply fascinating view, of course.

>
>
>As I said, the actual numbers aren't important. What's important is
>the accuracy of the analogy, not the accuracy of the numbers. The
>numbers are only a hand-drawn illustration, not a high-resolution
>photograph.
>
>The point is that the programmer who decides to use display-mode, as
>opposed to packed, fields in an outgoing file is _not_ the equivalent
>of childless newlyweds buying an expensive mini van. No, the
>equivalent is the childless newlyweds getting that mini van for
>_NEGLIGIBLE_ added cost, as insurance against whatever the future
>brings.

The only data you have to support your assertion of this '_NEGLIGIBLE_'
cost is, by your own admission, purely fabricated; extend the analogy from
subcompacts and minivans to stand-alone PCs and internationally-networked
mainframes and things might seem a bit different.

DD

LX-i

2004-08-27, 3:55 am

Curtis Bass wrote:
> LX-i <lxi0007@netscape.net> wrote in message news:<E95Uc.23224$5s3.1064@fe40.usenetserver.com>...
>
>
>
> Another thing that we have, which they didn't have thirty years ago,
> is bloody dirt _CHEAP_ hardware.

This is also true. :)

> In 1974, a thousand bytes of core
> (what we call "RAM" today) prabably cost one hundred thousand dollars.
> Today, a GIGABYTE of RAM cost _LESS_ than _ONE_ thousand dollars.
> When you "ponder" such things, sweating over two bytes per transaction
> seems myopic to disturbing extremes . . .

That's what some folks see as the end of some of the artistry that
programming used to require. I remember when I got a 100MB hard drive
(and it wasn't cheap either!) - I thought, "Wow, I'll never fill this
up! I can install Windows and still have over 90MB free!"

Now I'm feeling crunched with 20GB. I could alleviate that crunch if
I'd get the courage to dump Windows - I just haven't found replacements
for some of the apps I use from time to time. Right now, I've been on
straight Linux for a couple of w

s.

I do understand memory crunches, though. Back when we were using the
COBOL 74 compiler, we did a schema change that changed all instances of
5-position codes in our database to 32-position codes. There were maybe
twenty or thirty of these occurrences. We started having programs that
wouldn't compile because working-storage was too big! (Luckily, that
gave us yet another reason to push for COBOL 85...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Joe Zitzelberger

2004-08-27, 3:55 am

In article <hKwXc.30130$5s3.6061@fe40.usenetserver.com>,
LX-i <lxi0007@netscape.net> wrote:

> Curtis Bass wrote:
>
> This is also true. :)
>
>
> That's what some folks see as the end of some of the artistry that
> programming used to require. I remember when I got a 100MB hard drive
> (and it wasn't cheap either!) - I thought, "Wow, I'll never fill this
> up! I can install Windows and still have over 90MB free!"
>
> Now I'm feeling crunched with 20GB. I could alleviate that crunch if
> I'd get the courage to dump Windows - I just haven't found replacements
> for some of the apps I use from time to time. Right now, I've been on
> straight Linux for a couple of w

s.
>
> I do understand memory crunches, though. Back when we were using the
> COBOL 74 compiler, we did a schema change that changed all instances of
> 5-position codes in our database to 32-position codes. There were maybe
> twenty or thirty of these occurrences. We started having programs that
> wouldn't compile because working-storage was too big! (Luckily, that
> gave us yet another reason to push for COBOL 85...)

My Mac has gotten by for 5 years (a Dual 450 G5) with a 20 gig hard
drive. The only reason I added a new one was for the iTunes music files
this spring. (I discovered iPods and keeping hundreds of discs on my
box)

It is amazing what you can fit in 20 gig if you don't have to keep every
file ever written to your hard drive.

LX-i

2004-08-27, 3:55 pm

Joe Zitzelberger wrote:
>
> My Mac has gotten by for 5 years (a Dual 450 G5) with a 20 gig hard
> drive. The only reason I added a new one was for the iTunes music files
> this spring. (I discovered iPods and keeping hundreds of discs on my
> box)
>
> It is amazing what you can fit in 20 gig if you don't have to keep every
> file ever written to your hard drive.

:) Well, with my current setup, I've got 10G each on WXP and Linux -
after OS installs and such, it's really cramped to do something like
back-up a DVD. I could probably shift it around and make it work, but
on a machine with 30G dedicated to one OS or the other, I wouldn't even
have to worry about it.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-08-29, 3:55 pm

In article <163715e7.0408282016.76cac279@posting.google.com>,
Curtis Bass <cmbass_us@yahoo.com> wrote:
>docdwarf@panix.com wrote in message news:<cgoh3h$gba$1@panix5.panix.com>...
>
>Agreed. Maybe it is just you. Do recall that you provided an analogy
>yourself; what "data" did you provide to support that analogy?

The ones which necessary to support a numerically-inspecific one, of
course.

>
>
>Since you originally came up with the (inappropriate) analogy, perhaps
>you can remind me what data you used to come up with the analogy,
>since "data" seems to be an overriding concern of yours. Provide the
>data than shows how assigning programming resources to provide a
>mechanism to reliably translate packed data down the road is cheaper
>than simply providing a few bytes up front to store values in display
>format.

My analogy was not intended to demonstrate that 'assigning programming
resources to provide a mechanism to reliably translate packed data down
the road is cheaper than simply providing a few bytes up front to store
values in display format', it was intended to demonstrate how a system
which was, under certain conditions, acceptable for a certain lifespan or
data-volume could be, in later years, outgrown, just as a newly-wedded
couple's needs could, quite 'organically', outgrow the subcompact which
served them admirably.

>
>
>Irrelevant. Common sense does not need to be "data" in order to
>support an assertion.

Relevant. Common sense says that heavier objects will fall faster than
lighter ones, remember?

>
>
>Irrelevant. Observation does not need to be "data" in order to
>support an assertion.

Relevant. Observations can disprove common sense, as shown above.

>
>
>Again, you (deliberately?) miss the point.

Perhaps the point you are trying to make has been obscured... might you be
so kind as to re-state it?

>
>
>Caricatures and cartoons can still be used to illustrate a point.
>Political cartoons come to mind.

What 'can be' and what 'is' just might not be the same, as the matter at
hand appears to... illustrate.

>
>
>So you "really" don't get it, then. Not what I would call an
>improvement.

To move from a state of 'apparent' to 'really' is not an improvement?
Some might argue otherwise.

>
>
>What was your supporting data, again?

The fact that a system can be outgrown or that a system which satisfies
one set of conditions becomes less valuable when those conditions change.

>
>
>Appeal to Authority again cited. I am still waiting for supporting
>data, which, again, seems to be a primary concern of yours. Rather
>ironic, yes? Especially considering that "Big 8... errrrr, 5...
>errrrr, 3 Accounting Firm" did _not_ seem to be an original
>requirement in LX-i's scenario.

To which Authority do you see me 'appealing'? The scenario given
originally was a system which was designed to function for a certain
period of time with a certain quantity of data; both the amount of time
needed and the amount of data passed were outgrown, just as the system
requirements of a one-man accounting shop' requirements can be outgrown
when they approach Big 8... errrr, 5... errrr, 3 size.

These are data (given things) and facts (done things).

DD

Curtis Bass

2004-08-30, 8:55 pm

docdwarf@panix.com wrote in message news:<cgst93$92c$1@panix5.panix.com>...
> In article <163715e7.0408282016.76cac279@posting.google.com>,
> Curtis Bass <cmbass_us@yahoo.com> wrote:
>
>
> The ones which necessary to support a numerically-inspecific one, of
> course.

Which "ones" might those be? Can you (afford to) be specific?

>
> My analogy was not intended to demonstrate that 'assigning programming
> resources to provide a mechanism to reliably translate packed data down
> the road is cheaper than simply providing a few bytes up front to store
> values in display format', it was intended to demonstrate how a system
> which was, under certain conditions, acceptable for a certain lifespan or
> data-volume could be, in later years, outgrown, just as a newly-wedded
> couple's needs could, quite 'organically', outgrow the subcompact which
> served them admirably.

Perhaps you need to be reminded which analogy we are discussing. It's
at the top of this posting, but I'll repeat it here for convenience:

LX] Ponder this... A programmer decides to use display usage on a
LX] particular file. A few years on down the road, two mergers later,
LX] a new manager decides they need to send that file to an external
LX] entity. Is the system viewed as sluggish and inefficient, or
LX] responsive and flexible?

DD] Likewise, ponder this: a couple gets married and immediately buys
DD] the largest minivan that's on the market... after all, a few years
DD] down the line they might have five kids and two Dobermans to ferry
DD] about, you never knoooo-ooooowwww.

It certainly appears to me that the analogy under discussion does
indeed suggest that providing a few bytes per record up front is a
non-justifiable expense, which does indeed imply that it would be
cheaper to wait. Of course, as I have already discussed (and you keep
dodging), the analogy is flawed, because usage display isn't as
expensive as your analogy implies. Or, at the very least, you have yet
to provide any data that shows it to be that expensive.

>
> Relevant. Common sense says that heavier objects will fall faster than
> lighter ones, remember?

Well, it would appear that "common sense" is indeed correct, at least
in some cases here on Planet Earth, where I live. If you don't
believe me, just try it yourself with a ball-peen hammer and a
feather. Or a Styrofoam ball and a lead ball of equal diameter.
Unless you live in a Very Special Place, I would wager that, if both
objects were dropped from the same height at the same time, the
heavier object would hit the ground first in the comfortable majority
of the trials, but, I suppose you could score a few pedant points if
you were to use a "height" of one one-hundredth of a centimeter, or
something equally ridiculous.

No, Newton's Laws aren't suspect. On the contrary, in your quest for
pedantry, you are simply ignoring the fact that we have an atmosphere
which can and does exert drag on all falling objects. Heavier objects
are less influenced by this drag than lighter ones, all else being
equal, but the drag is still there no matter how heavy or light the
object, and even if its effect is too small to reliably observe.

In trying to devalue common sense, you unfortunately ended up
displaying a lack of same. To be sure, that which we call "common
sense" can mislead, but to imply that it's universally useless is
unwarranted. And common sense _can_ support an assertion, at least
until the assertion is proved wrong.

>
> Relevant. Observations can disprove common sense, as shown above.

Only at the cost of common sense, "as shown above". Or, to put it
another way, your reasoning is circular; in this particular case, your
"observation" only "disproved" common sense because it was _lacking_
common sense in the first place.

>
> Perhaps the point you are trying to make has been obscured... might you be
> so kind as to re-state it?

Your analogy, as stated and repeated above, is flawed.

a[color=darkred]
>
> What 'can be' and what 'is' just might not be the same, as the matter at
> hand appears to... illustrate.

On the contrary, my illustration is valid regardless of whether it's a
caricature or cartoon.

>
> To move from a state of 'apparent' to 'really' is not an improvement?

Not when the direction is downhill, no. Would you argue that moving
from "apparently mentally disturbed" to "really mentally disturbed" is
an improvement? Or moving from "apparently dead" to "really dead"?
Keep in mind that what _appears_ to be the case may not actually _be_
the case.

> Some might argue otherwise.

<shrug> Let them argue.

>
> The fact that a system can be outgrown or that a system which satisfies
> one set of conditions becomes less valuable when those conditions change.

LX] Ponder this... A programmer decides to use display usage on a
LX] particular file. A few years on down the road, two mergers later,
LX] a new manager decides they need to send that file to an external
LX] entity. Is the system viewed as sluggish and inefficient, or
LX] responsive and flexible?

DD] Likewise, ponder this: a couple gets married and immediately buys
DD] the largest minivan that's on the market... after all, a few years
DD] down the line they might have five kids and two Dobermans to ferry
DD] about, you never knoooo-ooooowwww.

Explain how your "data" supports your analogy.

To me, it appear that your analogy is saying that we _actively_ should
_not_ plan for potential future needs, simply because it would be akin
to a newlywed couple buying an expensive mini-van when all they need
_at_the_moment_ is a small, inexpensive economy car. You appear to be
advocating waiting until the system is outgrown and _then_ redesigning
and expanding it, but not to do _anything_ to anticipate possible
future needs because we cannot "know" what those needs are, and doing
simple things like storing numerics in display mode is too expensive.

If that is not what you are saying, then let me know and I'll stand
corrected.

>
> To which Authority do you see me 'appealing'?

Your personal authority based on anecdotal "evidence".

> The scenario given
> originally was a system which was designed to function for a certain
> period of time with a certain quantity of data; both the amount of time
> needed and the amount of data passed were outgrown, just as the system
> requirements of a one-man accounting shop' requirements can be outgrown
> when they approach Big 8... errrr, 5... errrr, 3 size.
>
> These are data (given things) and facts (done things).

I think you are still

wrt which analogy I am criticizing.

OTOH, if I've simply misread your analogy as stated above, let me
know, and I'll cede.

Curtis

docdwarf@panix.com

2004-08-30, 8:55 pm

In article <163715e7.0408300910.6bc9faba@posting.google.com>,
Curtis Bass <cmbass_us@yahoo.com> wrote:

[snip]

>Perhaps you need to be reminded which analogy we are discussing. It's
>at the top of this posting, but I'll repeat it here for convenience:
>
>LX] Ponder this... A programmer decides to use display usage on a
>LX] particular file. A few years on down the road, two mergers later,
>LX] a new manager decides they need to send that file to an external
>LX] entity. Is the system viewed as sluggish and inefficient, or
>LX] responsive and flexible?
>
>DD] Likewise, ponder this: a couple gets married and immediately buys
>DD] the largest minivan that's on the market... after all, a few years
>DD] down the line they might have five kids and two Dobermans to ferry
>DD] about, you never knoooo-ooooowwww.
>
>It certainly appears to me that the analogy under discussion does
>indeed suggest that providing a few bytes per record up front is a
>non-justifiable expense, which does indeed imply that it would be
>cheaper to wait. Of course, as I have already discussed (and you keep
>dodging), the analogy is flawed, because usage display isn't as
>expensive as your analogy implies. Or, at the very least, you have yet
>to provide any data that shows it to be that expensive.

Ahhhhh, I see... pardon me for my lack of clarity. I was addressing not
only the conserving of space by contrasting display numerics versus
packed; I was attempting to extend this one, very narrow consideration to
a broader view by interpreting a system (and its design) as a solution to
a set of processing considerations, just as the choice of a vehicle can be
a solution to a set of transportation considerations.

I hope this clarifies my reason for supporting the analogy by comparing a
one-person accounting shop's solution to a set of processing
considerations with that needed by the Big 8... errrr, 5... errrrr, 3
Accounting Firms; while both need to address the specifics of accounting a
valid solution for one would be utterly inappropriate for the other.

My error and apologies for being insufficiently specific.

DD

Howard Brazee

2004-08-30, 8:55 pm

I have worked with companies that have bought out others - with incompatible
databases. The problem here wasn't 2 digit years, but that different things
were measured. The big problem in merging their databases was in making sure
that the combined data were meaningful. (Insurance companies are real big in
data mining).

Designing your data for some merger 10 years in the future with unknown business
rules and needs is an expensive proposition at best.

Curtis Bass

2004-09-01, 3:55 am

docdwarf@panix.com wrote in message news:<cgvpi9$d93$1@panix5.panix.com>...
> In article <163715e7.0408300910.6bc9faba@posting.google.com>,
> Curtis Bass <cmbass_us@yahoo.com> wrote:
>
> [snip]
>
>
> Ahhhhh, I see... pardon me for my lack of clarity. I was addressing not
> only the conserving of space by contrasting display numerics versus
> packed; I was attempting to extend this one, very narrow consideration to
> a broader view by interpreting a system (and its design) as a solution to
> a set of processing considerations, just as the choice of a vehicle can be
> a solution to a set of transportation considerations.
>
> I hope this clarifies my reason for supporting the analogy by comparing a
> one-person accounting shop's solution to a set of processing
> considerations with that needed by the Big 8... errrr, 5... errrrr, 3
> Accounting Firms; while both need to address the specifics of accounting a
> valid solution for one would be utterly inappropriate for the other.

Your explanation does indeed clarify your intended meaning, so it
appears that I did at some level misunderstand what you were trying to
say with your analogy, and for that, I apologize. In the context you
explained above, your analogy does make a lot more sense than it did
in my misapplication of it to the wrong context.

> My error and apologies for being insufficiently specific.

"We all make mistakes, Mr. Bond."

I'm rather confident that I also had a hand in the misunderstanding.

Curtis

docdwarf@panix.com

2004-09-01, 3:55 am

In article <163715e7.0408311423.4f422898@posting.google.com>,
Curtis Bass <cmbass_us@yahoo.com> wrote:
>docdwarf@panix.com wrote in message news:<cgvpi9$d93$1@panix5.panix.com>...
>
>Your explanation does indeed clarify your intended meaning, so it
>appears that I did at some level misunderstand what you were trying to
>say with your analogy, and for that, I apologize. In the context you
>explained above, your analogy does make a lot more sense than it did
>in my misapplication of it to the wrong context.

Most gracious of you; I am pleased to have been able to assist in
clarifying matters.

>
>
>"We all make mistakes, Mr. Bond."

Well... that's better than 'No, Mr Bond... I expect you to die!'

>
>I'm rather confident that I also had a hand in the misunderstanding.

Oh, so now you're saying I am not sufficiently competent to generate a
misunderstanding all on my own? How *dare* you... you'll hear from my
seconds in the morning; they'll be coming with an offer for swords at
twenty paces.

Have at you!

DD

docdwarf@panix.com

2004-09-02, 3:55 am

Curtis Bass

2004-09-02, 8:55 am

Curtis Bass

2004-09-03, 3:55 am

docdwarf@panix.com wrote in message news:<cgl0ui$bkv$1@panix5.panix.com>...
> In article <163715e7.0408260657.562f3b90@posting.google.com>,
> Curtis Bass <cmbass_us@yahoo.com> wrote:
>
>
> How interesting... I never knew that purely fabricated figures could make
> for a quasi-valid analogy, learn something new every day.

What you are pretending to not get is that my quasi-valid analogy is
superior to your thoroughly invalid analogy, and also that I am being
up front about the fact that my analogy is indeed imperfect (hence
"quasi-"valid), while you have yet to admit that your thoroughly
_invalid_ analogy is indeed flawed.

>
> All right... how cheap is the hardware necessary to process year-end
> closings for one of the Big 8... errrr, 5... errr, 3 Accounting Firms?

Cheap enough to not sweat a few bytes per record in external storage,
that's how cheap.

>
> A simply fascinating view, of course.
>
>
> The only data you have to support your assertion of this '_NEGLIGIBLE_'
> cost is, by your own admission, purely fabricated;

Wrong I also have common sense. And observation. An illustration
is designed to illustrate, not prove. You don't prove physical laws
with a diagram -- you prove physical laws with rigorous mathematics.
My purely fabricated numbers were an illustration, a diagram, not a
rigorous mathematical proof.

Yet you still pretend to not get it.

> extend the analogy from
> subcompacts and minivans to stand-alone PCs and internationally-networked
> mainframes and things might seem a bit different.

Maybe, and maybe not. What "might seem a bit different" might be
nothing more than the numbers themselves, and your analogy remains
thoroughly invalid, while mine remains quasi-valid, which is still
superior to thoroughly invalid. And, for the record, our PCs that we
are using to post to this newsgroup are, in fact,
"internationally-networked", so I fail to see what significance
"internationally-networked" has, unless it's an attempt to intimidate
(the "Appeal to Authority" logical fallacy).

> DD

Curtis

Curtis Bass

2004-09-06, 3:55 am

wrt which analogy I am criticizing.

OTOH, if I've simply misread your analogy as stated above, let me
know, and I'll cede.

Curtis

docdwarf@panix.com

2004-09-06, 3:55 am

Howard Brazee

2004-09-06, 3:55 am

Sponsored Links