• Subject: Re: CHGPF Question
  • From: "Chris Rehm" <Mr.AS400@xxxxxxx>
  • Date: Mon, 22 Sep 1997 10:15:44 -0400

>> know it is the wrong thing to do, but you did it anyway as the "quick
>> and
>> dirty" solution. LVLCHK(*NO) is no more short sighted than hard coding
>> department numbers or using two digit years.
>I didn't say dirty.  You said dirty.  It was Quick and is working.

Dirty is a matter of degrees, I suppose. Two digit date fields "work".
Hard coded department numbers "work". Would I recommend them? Plan them
out of choice? No, but I would use them if that is the option that works
within given time constraints. 

But when someone pointed out the short sightedness of my solution, I would
probably say, "I know, but I had to do it." No sense justifying what I
disagreed with in the first place!

>It's a disservice if it doesn't work.  It's a service if it works.

Again, a matter of degrees.

>> I've coded untold zillions of lines of RPG that use two digit years.
>> To
>> date, they run just fine and the customers are making big bucks. But I
>> am
>> not going to try and say that this was the right thing to do because
>> it
>> was quicker and nothing bombed. The show ain't over.
>It was the right thing to do back then.  Programmers had to save disk

No, 2 digit years was short sighted back then, too. I am pretty sure that
the reason many of us used them wasn't to save disk but simply because the
system date supplier (udate) gave us a 6.0 response to work with. 

I went through the same as everyone. I had a customer with a S/32 that was
so limited we had to unload payroll to load GL, and vise versa. But if
udate was 8.0 instead of 6.0 I would have just accepted it without
thinking about it (quite as I accepted 6.0 without thinking about it). 

The point is that many things we do "because it works" are short sighted
solutions which our customers have to pay us to fix in the future. 

I did have a case where a customer wanted to change a department name and
I discovered that the departments were all hard coded into tables at the
end of programs. I recommended that we create a little disk file and a
maintenance job etc. to clean up the problem. The customer (a personal
friend) ask me if I couldn't just do a quick modification because they
were waiting to run paychecks and I agreed. A couple years later I was on
his site as well because they were having a problem with payroll. It
turned out that he had been trying to save money hiring trainee
programmers and that some of them had learned by copying existing apps.
Now they had pay descriptions that didn't match from program to program
(so when the report said FICA adjustment, the check said Jury Duty Pay). 

He paid for cutting corners. But HE made the decision to do it. I charged
him for the clean up.

>Art Tostaine, Jr.

Chris Rehm
You have to ask yourself, "How often can I afford to be unexpectedly out of 
Get an AS/400.
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].