× 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: CODE/400
  • From: DAsmussen <DAsmussen@xxxxxxx>
  • Date: Fri, 6 Mar 1998 19:24:44 EST

Chris,

In a message dated 98-03-06 02:19:10 EST, you write:

> I don't know if you are aware of this Dean, but Visual Basic doesn't allow
>  you to write RPG. The two tools are very, very different. I guess this is
>  where I should say, "But Code/400 should be very attractive to management
>  since it would cost thousands per seat to get everyone plastic surgery."
>  Only one of the two choices has anything to do with increasing programmer
>  productivity in an RPG shop.

C'mon Chris!  Managers at large corporations (and perhaps rightly so) don't
GIVE A HOOT about the language used, and really like it when you can come up
with a C/S application, which CODE _won't_ do.  Small shops probably aren't
going to buy CODE _or_ VB.  Large ones care about increasing productivity,
period -- language be damned.  We've got a VB application right now that was
written merely because RPG wouldn't access the data on an SQL-Server Box, a
Tandem, and the AS/400 in real-time fashion.  Yeah, we could have FTP'd the
whole thing to the AS/400 (and it would have run faster), but the Tandem
didn't have TCP/IP installed and data propagation wouldn't have happened in
real time.  All these managers see is that _GOOD_ RPG programmers are hard to
come by, and pricey.

>  > For now.  But I get more and more requests for (pick your PC development
>  > language) skills to write C/S applications that interface to the /400
>  > database.  IBM's market direction is taking hold, and the AS/400 is
slowly
>  > becoming the "server of choice".  What will happen to those whose "
> profession
>  > is" AS/400 application development when there _are no_ applications
(other
>  > than triggers, stored procedures, and database servers) running on it?
>  
>  The reason you get more and more requests for "(pick your PC development
>  language)" is because those tools make you more productive. If you were as
>  productive in RPG, your language of choice would be a valid contender.
>  This isn't likely if you will always insist that the program must be
>  chiseled in stone. 

Not if it's not a cross-platform language.  The other reason is that VB
personnel = easy to come by, cheap; RPG people = hard to come by, expensive.
What did you mean by "chiseled in stone"?

>  > Me neither.  I used to sell software myself.  I was merely playing
"devil's
>  > advocate" on the issue.
>  
>  "Devil's advocate"? You were stating that IBM would be better off to lower
>  the price of their software so it would be more popular with thieves! 

Sighhhh.  If you say so.

>  > >  By the way, why would you think that someone would prefer to steal a
>  > >  cheaper product?
>  >   
>  > Because it was easier to talk management into buying it in the first
place.
> 
>  
>  Oh, I see, because it would be easier to talk management into buying the 1
>  starter copy to steal from. I see. 
>  
>  > And what "evidence" would this be?  The only "preponderance" I've seen so
far
>  > is people unable to talk their management into purchasing CODE/400.
>  
>  Then show me the deep penetration of some other tool into AS/400 shops?
>  Your own statements were that you were upset that you were forced to use a
>  case tool! The evidence is a poll of AS/400 shops! Now, I haven't been in
>  them all, but I the ones I have been in write RPG using PDM/SEU. Mention a
>  better tool on this list and listen to a rash of arguments about why not
>  to use it!

I'm only upset with the CASE tool because it hasn't been improved other than
to fix things that were broken (and there wasn't MUCH broken) for the past
four years.  The newest version, released late 4Q97, fixes a Y2K issue with
the built-in date functions.  The tool was supposed to have been replaced with
a new GUI version over two _YEARS_ ago!  So nothing new -- "it'll be in the
(perpetually promised, yet to materialize) GUI version".  You'll excuse me if
I disregard the "anecdotal evidence" of your "poll".

>  The evidence clearly shows that AS/400 shops do not like to evolve. 
>  
>  > >  What you are telling me is that you think programmers and managers who
...

> > I don't recall either saying _or_ implying that, but let's go with it.  My
>  
>  Then what exactly were you saying or implying when you indicated that IBM
>  should lower the price of Code/400 (an RPG development tool for the
>  AS/400) to be more comparable with Visual Basic (a graphic cut and paste
>  application builder for Basic on a PC)?

Because, again, management doesn't _CARE_ about the language.  All they care
about is personnel availability and price.  I agree with Jon's plan to make
CODE more modular, just like VB.

>  > current primary client has averaged 6 months/employee trying to find
qualified
>  > AS/400 personnel (this _AFTER_ dropping the requirements for knowing
either
>  > BPCS _or_ the AS/Set CASE tool).  They can have a VB "guru-level"
employee 
> in-
>  > house tomorrow -- probably for less money than they pay their _junior_
AS/400
>  > folks.  What I'm trying to say is that all the productivity gains in the
>  > _world_ will not help if you cannot find qualified personnel.  Yes,
AS/400
>  
>  I'll be god damned. That is like hitting me with a hammer. Dean, if you
>  can't find good people, isn't that an even better time to IMPROVE THE
>  PRODUCTIVITY OF THE PEOPLE YOU ALREADY HAVE?!?!?!?! 

Pardoning your "French", I already stated that this client cannot use CODE due
to their use of the aforementioned CASE tool.  More than half of their staff
cannot read the RPG that the tool generates, as it (AS/Set) was sold on a "you
don't need to know RPG" basis.  Yes, it _would_ be a good time for others to
do so, which is why I offer alternatives on how to sell more copies of CODE.

>  If you have to search 6 months to find an employee, and you have five in
>  house (you didn't give a number of employees), and you have a tool that
>  can improve productivity 20%, then what kind of additional justification
>  do you need for trying it?

In this case, the productivity increase would be zero (eight full time
employees, three contractors, BTW).

>  However, it appears that your client has opted for reading Visual Basic
>  ads and wishing desperately he could hire more people to increase
>  productivity?

Now wait just a darn minute!  Weren't _YOU_ the one that argued vehemently
with me about the fact that management _didn't_ make decisions based solely
upon advertising?  I apologize in advance if you weren't.  The client uses VB
where necessary and CODE wouldn't have helped them in the cross-platform
implementation mentioned above.  People that know BPCS and the AS/Set CASE
tool would help productivity, but there just aren't many of us out there.
 
>  > folks can pick up CODE quickly.  Where do you find them?  A VB'er
probably
>  > won't pick up CODE quickly, but he/she is certainly easier to come by
than
>  > someone that can.  If the current developer shortage continues, I can
envision
>  > C/S projects being approved merely because there _ARE NO_ people
available 
> to
>  > do the green screen work.  That would be a bad thing, IMO.
>  
>  I think that IBM has long since realized that AS/400 shops aren't going to
>  learn new tricks. Haven't you noticed that VA for Java is $100? Enterprise
>  edition $1995. 

Last I heard, JAVA Enterprise came free with V4R2.  Is that not the case?

>  This way, IBM has found a way to create a new batch of AS/400 and
>  mainframe programmers even though their customers won't budge. I have seen
>  a few "language of the month" comments about Java here, but I can tell you
>  this: AS/400 shops are forcing Java to succeed or the AS/400 to fail. 
>  
>  > >  If the product cost $5000 a seat, it would be a good deal for AS/400
shops
>  > >  anyway. 
>  >   
>  > Perhaps.  The _actual_ cost isn't the issue that I'm agruing here.  It's
the
>  > _perception_ of that cost by management.  More and more shops are managed
> by
>  > non-technical folks that don't have a _CLUE_ as to the value-add of
something
>  > like CODE.  All they see is SEU="free", VB=$100US, CODE=$900US -- a no-
> brainer
>  > decision for a Harvard MBA looking to minimize expenses for the sake of
>  > minimizing them.  Throw in VB="C/S applications that _MY_ management has 
> read
>  > about as the flavor du jour", and you're dead in the water as far as CODE
is
>  > concerned.
>  
>  No, I am not. See, I understand that the business case for Code/400 is
>  very strong. While you are willing to assume that a guy who got an MBA
>  from Harvard is just an idiot who can't tell the value of investment, I am
>  willing to bet the average one of them can use a spreadsheet. I can show
>  the guy, based on the average cost of a programmer, that betting a two
>  week experiment against a 20% productivity increase is valid. 

Then why haven't you published those figures here, instead of continuing to
"flog the dead horse" that this thread has become?  If anyone even remembers,
it started as a valid request by Jon Paris for valid options to be considered
by IBM to make CODE/400 more marketable.  I think that the former is
desirable, and that _this_ line of commentary has become counter-productive.

>  By the way, I don't bother contending with VB, because it (of course) HAS
>  NOTHING TO DO WITH THE CODE/400 QUESTION! Do you, or your clients, think
>  that they must choose between faster AS/400 development and writing
>  graphic based PC apps? Hey, good news! You can do both! If you don't want
>  to use VisualAge for RPG, then just license Code/400 AND Visual Basic.
>  When I bought Code/400 last, you could choose to license VA RPG or not. 

My thoughts exactly, so why have you chosen to "harp" on it?

>  > Application reliability _RARELY_ appears as part of an ROI analysis...
>  
>  I didn't say it did. I was trying to emphasize the point that you continue
>  to ignore the fact that VB and Code/400 are for different tasks.

And _you_ continue to ignore the fact that there are languages other than RPG
that are valid for use on the AS/400 -- even if they are developed on another
platform.  The differentiation (a word?) between the tasks narrows more and
more every day.  As I stated earlier, an "AS/400 application developer" may
soon be something needed only by those same accounts that refuse to give up
their /36's today...

>  You choose between reliable or not when you make the decision to develop
>  RPG on the AS/400 or Basic on PCs. If, in your wisdom, you have chosen to
>  write RPG on an AS/400, then why in the world would you shop for Visual
>  Basic? 

Not at ALL.  As also stated earlier, the core of my client's business runs on
VB applications accessing data on the AS/400.  It's reliable, it's fast (using
ESS/400 rather than ODBC), and it's accurate.  Our only problems?  No formal
promotion tool for the PC like we have on the AS/400, and when the network
goes down the programs don't work.  Of course, the latter would be true of a
"green-screen" application written for the same environment...

Enough Already...

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

"404 (adj) -- a person or thing that is technically present, but unavailable
or not found."


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