× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: CHGPF Question
  • From: DAsmussen@xxxxxxx
  • Date: Sat, 27 Sep 1997 03:41:50 -0400 (EDT)

Dave,

In a message dated 97-09-22 10:29:25 EDT, you write:

> >> Let me throw out a design strategy for discussion. (It's not an original
>  >>  idea, by the way; it goes back to S/38 days.)
>  >
>  >Not sure why, but I'll bite.
>  
>  Come on, Dean, you know you can't resist a good debate. :-))

I think that we may have been on the list together for FAR too long!  Yes, a
lot of my discussions were thrown out there merely to elicit responses.  I DO
agree though, that I was perhaps a bit too offensive in some of my taunts.
 Peer debate is how we learn.  Although I still am not convinced of a GOOD
reason to use LVLCHK(*NO), I CAN see the thinking behind it (remembering my
OWN days in that position).

I would say to Art and other LVLCHK(*NO) supporters (ABSOLUTELY NO offense
intended) that you buck up and inform the client of the impact of the change,
and that you WILL NOT do it until the system is available for a full
re-compile.  I would NEVER advocate lying to a client, but in this case "what
they don't know won't hurt them".  It's in THEIR best interest, especially
should YOU be hit by a bus.

Again harping on a seemingly self-serving policy, you SHOULD have a clause in
your contract that states "work after business hours is at time and 1/2".
 File changes should be done after hours.  Amazing how often those file
changes become low priority, or even unnecessary, when the client realizes
that they must pay extra for them or take the system down for an hour or so
during the day!

Clients that "require" file changes "on the fly" need some management from
you.  The old adage "lack of planning on your part does not necessarily
constitute an emergency on my part" applies.  As stated (MUCH) earlier in the
thread, database changes require careful thought (although adding a field, as
I stated, is NOT usually "rocket science").  However, adding a field should
NOT compromise the customer's database either.  When you start "putting your
foot down", this sort of client tends to acquiesce.  In issues regarding IS,
the customer is NOT always right.  Had I only learned this MYSELF 15 years
earlier...

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM (for now)

"Where there is an open mind, there will always be a frontier." -- Charles F.
Kettering
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.