× 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.



Allow me to add one more to Rob's list:

Use of Easy400.net tools - YES!

TomH

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, May 08, 2013 2:52 PM
To: Midrange Systems Technical Discussion
Subject: Re: 20 years of experience, versus one year of experience repeated
20 times (Bradley Stone)

Yes, there is some middle ground. As I stated in that I can cut some slack
in DSPOBJD to an outfile vs the Open list of objects API.
And I can see not converting some vendor code from fixed format to free,
when you're modifying it, so that you could more easily do a source compare
when they come out with a new version.

But, writing new code in fixed? No. Jumping back and forth from /free in
modified vendor code? Yes!
Never having put a subprocedure in production? No!
Must you convert all I/O to SQL? No. But no imbedded SQL when your shop
has 57##ST1? No! Writing new OPNQRYF when you have SQL? No.
Never having had used an API? Very questionable.
Never having had use any Scott Klement techniques? Very questionable.
Use of RDP limited only to that class you took years ago that management
forced you to take? No! No use of RDP because of budgetary concerns? Not
really my preference, but you better have some overriding qualifications.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Bradley Stone <bvstone@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 05/08/2013 03:32 PM
Subject: Re: 20 years of experience, versus one year of experience
repeated 20 times (Bradley Stone)
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Yes, Jim. There is a middle ground as with anything. There is even
further left and right of the spectrum.

Simple black and white examples usually get the point across better. Flow
either way from there as much as you like and you'll find more than just a
middle ground. But no one wants to read about that. :)

Brad
www.bvstools.com


On Wed, May 8, 2013 at 2:23 PM, Horn, Jim <jim.horn@xxxxxxxxxxxxxx> wrote:

Isn't there some middle ground here.

Certainly there is some value to continuity. To change at intervals. Do
you really want everyone to use the latest technique every time they do
something? Do you want to be debugging the latest technique when the
author is gone and you're the one there?

Some of you seem to be experts at many things. Could be that's a bit
like
hiring a concert pianist to fix your guitar. He might get it done,
might
even enjoy it, but may not give you the bang for the buck you are
looking
for, and will the job stand the test of time. Maybe a person who has
been
fixing guitars for 20 years and has "seen everything" will do the job
you
want.

Many of us on this list may have erp systems that are still working
after
30 years (with updates of course). They probably lasted because they
were
fundamentally sound and consistent no matter what techniques they used.
I
certainly wouldn't write them that way now, but they used the simplest
most
consistent technique at the time to get the job done.

Don't start jumping. I'm not suggesting we use more indicators than we
need to, or use goto's and tag's, or go back to tweaking arrays rather
than
using string operators. I love using new techniques I can understand.
We
just need to remember they are tools we use to our jobs, they are not
ends
in themselves.

Jim



message: 1
date: Wed, 8 May 2013 12:33:20 -0500
from: Bradley Stone <bvstone@xxxxxxxxx>
subject: Re: 20 years of experience, versus one year of experience
repeated 20 times

What you've described is the difference between a "programmer" and a
"coder".

Programmers love what they do, try to better themselves, know when and
where to apply those techniques, etc.

Coders write code, fix code and coast to retirement. Throw something
new
at them and they'll fight about "if it ain't broke" and "well, if you
use
xyz then YOU have to support it".

It's the difference when given a task between: "We should be able to
do
xyz
to solve the problem" vs "Ugh.. then we'll HAVE to do xyz and that
will
take a lot of time..."

My .02 adjusted for diabolical and invisible inflation.

Brad
www.bvstools.com




***********************************************************************
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender and
delete the material from any computer. As a recipient of this email,
you are responsible for screening its contents and the contents of any
attachments for the presence of viruses. No liability is accepted for
any damages caused by any virus transmitted by this email.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.