× 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: Survey for AS/400 Developers (ISERIES) DB2/400
  • From: DAsmussen@xxxxxxx
  • Date: Tue, 31 Oct 2000 22:55:54 EST

Rob,

In a message dated 10/27/00 12:52:11 PM Eastern Standard Time, rob@dekko.com 
writes:

> Gee, I code RPG, I've used SQL in my RPG.  I didn't have a gun pointed to
>  my head telling me to do so.
>  
>  Any others?

After a fashion, I _DID_ have a gun held to my head.  BPCS converted to SQL 
in order to promote cross-platform compatibility -- back when that wasn't 
such a good idea on the AS/400.  Bad move for SSA, good move for the 
technicians (many of whom have since moved to other products and platforms) 
that supported BPCS.  I was forced not only to learn SQL in a hurry, but to 
learn how to tune SQL statements.  My clients were suddenly forced to 
purchase the full SQL toolset.   SQL went from being a bad word to a "how can 
we fix this" dialog with IBM, resulting in the recent performance 
improvements that benefit not only "native" programmers, but those using ODBC.

Necessity may be the mother of invention, but it also provides the tools to 
learn a new skill.  Clients and employers _FORCED_ to use new technology (see 
CISC to RISC, S/3 to S/34-36, S/36-38 to 400) somehow come up with the 
previously unavailable funds for new technology when it's the only avenue 
available to them.  If only more vendors would embrace JAVA and ILE, we'd all 
be better off.  But remember -- a single record FETCH cannot hold a candle to 
a CHAIN as far as performance to this day.  Technicians on other platforms do 
not see the latter limitation on those platforms, nor do they experience that 
complexity that we do when it comes to implementing commitment control.

On the other hand, I've found SQL to be most useful in cobbling together the 
various databases of the "major providers" that started out with a good 
design but have since deteriorated in their entity relationships without what 
should have been a requisite database redesign in subsequent releases of 
their products.  The watchword should be "use the right tool for the job".  
SQL won't always be the right tool, neither will be RPG.  Or JAVA, or COBOL, 
or REXX, or CL.

Want to know the _REAL_ weakness in the US IT community (besides managers 
that still won't acknowledge it's value within the enterprise)?  HINT:  It's 
the same weakness that plagues _all_ US workers in the global economy.  The 
language wars.  We learn one language, deny all others without reason, and 
continue to espouse that language even after it has gone the way of Latin -- 
DEAD.  That's why Asia and Europe are now kicking our collective rear-ends 
with the new telecom Internet languages.  No Micro$oft?  No IBM?  No DEC, 
Tandem, UNIX, platform-of-the-month?  BY GOLLY, I _REFUSE_ TO EVEN LOOK INTO 
IT!  Tough to learn a new  language if you don't use it, but even tougher 
when the language that you _ARE_ using becomes obsolete...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"There is something fascinating about science. One gets such wholesale 
returns of conjecture out of such a trifling investment of fact." -- Mark 
Twain
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| 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.