• Subject: Re: CODE/400
  • From: DAsmussen <DAsmussen@xxxxxxx>
  • Date: Sun, 8 Mar 1998 23:31:15 EST

Chris,

Sighhhh, responding despite the fact that I feel that all that can be said on
the subject has already been said...

In a message dated 98-03-07 03:18:00 EST, you write:

> > 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
>  
>  Dean, they will sure care a lot when they try to get that Basic app
>  running on the AS/400 Dean. 
>  
>  Again, you skip the point that Code is for AS/400 shops.

Again, _YOU_ skip the point that the platform on which the sofware runs _DOES
NOT MATTER_.  _Data_ is the key.  Most large corporations have adequate
clients on every desktop to run a well-written client application (and NO, I
_DO NOT_ consider SSA's latest offering to be well-written).  Other than it's
slow service of SQL clients, the AS/400 becomes irrelevant as a development
platform as more vendors seek to move their software to a more "OPEN"
environment.  Funny that PC's would eventually prove themselves more open than
UNIX...

>  > with a C/S application, which CODE _won't_ do.  Small shops probably
aren't
>  
>  Wrong. You can license the VA RPG piece (which happens to be part of the $
>  figure being bandied about) and your RPG guys are cutting and pasting
>  objects together into PC based applications, either standalone or
>  accessing AS/400 data. 

Fine, first time it's been mentioned, though.  Would that imply that its
client abilities aren't that strong?

>  Dean, your argument lacks substance. The product, Code/400 provides a way
>  to develop for AS/400s. VB does not. If you own an AS/400 and want to
>  develop code on it, Visual Basic is not even an option. 

Chris, you are just _WRONG_, and stand to be crushed by the very forces you
espouse championship for.  You have just _MISSED_ the very substance of my
argument.  Change -- it's coming, and being stuck in the "eeeeew, it won't run
on the AS/400, wahhh, wahhhh, wahhhhhhh" mode will only seal your fate.  VB
does _NOT_ run on the AS/400, but it can grab a buncha' data off of one in a
hurry.  You mention that VA/RPG will develop client applications almost as an
aside, while _I_ contend that client development should be what is
_highlighted_ in the product.

As an application platform, the AS/400 is _DYING_.  As a server, it is
_SOARING_.  Which is exactly why IBM has done the things to it that it has.
"We don't need no stinkin' OS or development tools" for the /400.  Perhaps
I've overused VB as an example, only because it's what we're using at my
current site.  JAVA's "a-coming", and there are a _LOT_ more people signing on
to it than _EVER_ did for C.

>  What happens here is you are applying faulty logic. Simply because
>  Code/400 can do what VB can do (ie. build PC apps) you treat it like VB
>  can do what Code/400 can do. This is defective logic.

My logic is not faulty, other than my attempts to persuade _YOU_ to "think
outside the box".  Your argument that VB will not write AS/400 code elicits,
in the words of my favorite morning radio hosts, "STUPIE!".  Of course it
won't, but that's irrelevant.  The people that will actually _PAY_ for CODE
without a discount (and probably the only ones that _could_ get a discount)
will more likely look away from RPG to something that more people can write
in.  VB can do everything that CODE can do as far as management cares...

>  > 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
>  
>  Odds are they will choose a language that actually works on the computers
>  they are running. 

They did.

>  Dean, do you suppose that businesses all through the US would switch to
>  publishing all their documents in Chinese if Chinese word processors were
>  cheaper? Or would they take into account that not all of their target
>  audience knows Chinese?

You've _JUST_ toasted your _OWN_ argument here!  Of course they wouldn't buy
your word processors, but they _WOULD_ buy a programming language that has at
least 10 developers available for every _ONE_ that knows CODE/400.  On the
other hand, if we were all fluent in Mandarin, I wouldn't put it past
Corporate America to purchase your Chinese word processors, either ;-).

>  > 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.
>  
>  Here you are refering to RPG that runs on the AS/400. Again, this is the
>  code that the VB product will not generate. The PC based program, written
>  in VB, could have been created in RPG with VA RPG, part of the Code/400
>  product. So, if you had researched the potential, you could have licensed
>  Code/400 and had a tool that allowed you to both build PC side
>  applications AND increase productivity of RPG programmers (thus reducing
>  the actual cost of RPG coding).

Chris, you're giving me a headache.  On the one hand, you keep harping "AS/400
development, AS/400 development, AS/400 development, and then you come back
with this.  Pick a patch of dirt and stand on it.  You're making me dizzy...

>  > 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"?
>  
>  Chiseled in stone. ie, you still use cave-man tools to do RPG. If IBM
>  hadn't dropped it, you'd still be using POP. 

Ahh, I get it!  The only reason IBM dropped POP was that 90% of the world was
using it for free!   Oh, but "you don't gain market share by allowing a
product to be stolen", now do you ;-)?

>  And just how "cross platform" is VB?

We currently use it to access databases on an ES/9000, some DECs, some
Tandems, the AS/400's, some RS/6000's, and some SCO/UNIX PC's.  How cross-
platform do you want?

>  > >  "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.
>  
>  Please review your posts. 
>  
>  > 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".
>  
>  I see. So your position is A: Since the Case tool you use has not been
>  upgraded as expected two years ago it isn't as good as SEU (um, when was
>  that last big boost in SEU?) and B: Although you experience and my
>  experience both show that AS/400 are highly resistant to adopting any new
>  development methods, we have not managed to gain a market sample and all
>  the shops we haven't seen are out their refusing to buy Code/400 because
>  Visual Basic is cheaper.
>  
>  Does that sum it up?

Are you sure you don't have a position in the Clinton cabinet?  To be able to
assemble more than several of my e-mails into the above statement would
certainly be word-smithing worthy of that esteemed group ;-).  I cannot decide
if you are so blinded by your allegiance to the AS/400 that you refuse to see
the validity of my arguments, or if you are just being purposely obtuse.

What I am _TRYING_ (obviously without much effect, as you hang on every word,
rather than the content) to say is, the shops that could provide the revenue
that would make CODE/400 a viable product don't care about the language.  Yes,
there is resistance in the AS/400 world to change.  Yet those that could
afford $1K, US, per seat are opting for VB.  What more do you want?

>  > >  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.
>  
>  Why is this so difficult to understand, Dean? The RPG programmers ARE
>  programming in RPG. There is no connection between that and Visual Basic. 

I'm leaning towards "purposely obtuse"...

>  You keep running round and round with a bunch of bull about price of VB
>  and VB programmers being cheaper and whatnot. What the heck does that have
>  to do with it?
>  
>  If you have an RPG programmer, and she is writing RPG code, then a tool to
>  make that go faster is Code/400. Buying her Visual Basic, new shoes, a
>  copy of War and Peace, an instruction manual for assembling a swing set, a
>  new universal remote, and/or ACME Fake Vomit (now with Corn!) will not
>  affect the rate of RPG production. 
>  
>  If the shop does not have an RPG programmer that they would like to have
>  be able to work faster, then Code/400 doesn't seem to make much sense. 
>  
>  The point is, Code/400 helps RPG programmers work faster. The product will
>  more than pay for itself. 
>  
>  This has nothing to do with deciding what language to develop in! This has
>  nothing to do with what platform to develop on! This has nothing to do
>  with comparing client based processing to host based processing to client
>  server processing to network processing. 

You're just _NOT_ getting it, are you?  I at first thought that you were
taking my turn at "devil's advocate", then that you were just "jerking my
chain" -- but you really don't understand the issue, do you?  That's sad.
I've done everything short of writing it in crayon, so let's see if I can take
the simplification one level further down...

CODE/400=Good, People that can afford it=Many.  SEU=OK, People that can afford
it=ALL w/ADTS.  People that can afford CODE/400=don't care about development
language _or_ AS/400 platform.  People that can't, say SEU=OK.

>  This has to do with those shops that, for WHATEVER reason, have decided to
>  employ people writing RPG code. If these particular shops are spending
>  $60,000 annually to keep an RPG programmer in place writing code, then
>  Code/400 can help them to get increased results for their money.
>  
>  > >  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
>  
>  I certainly am Dean! I didn't say that I believed what you said, I just
>  reiterated it. Recall that you were quoting me a story of a shop that
>  could not use Code/400 (and I have no idea why, since it is Code/400 we
>  were discussing) and telling me that they could have a VB programmer in
>  the shop immediately. 

Errrrrrrrrr!  Because most of the applications are BPCS, and run on programs
written in the AS/Set CASE tool.  However, the CORE of the operation uses VB-
based touch-screens that interface to the AS/400 BPCS database via ESS/400.
OS/2 was not a "corporate direction" at the time the system was built (over
two years ago), and CODE was not viable _FOR US_ at the time.  That's _NOT_ to
say that CODE wouldn't be a good choice for someone today.

>  > Last I heard, JAVA Enterprise came free with V4R2.  Is that not the case?
>  
>  One license. I guess so shops can steal the rest, eh?
>  
>  > 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.
>  
>  Dean, you must have missed several of my posts.
>  
>  > 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...
>  
>  I know you are aware that Visual Basic applications do not run on the
>  AS/400. The above paragraph makes it seem as though you think they do.

Chris, give me your mailing address.  I'll send you a dollar so that you can
buy a clue...

Regards,

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

"What you will do matters.  All you need is to do it." -- Judy Grahn
+---
| 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-Ups:

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.