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



A couple of things that I feel should be pointed out, as someone who
switched from VB6 to .NET and now am managing an iSeries environment.

I really believe that the missing piece in the discussion is the user
interfaces and their impact on technology.  VB6 in it's day and now .NET
are attempting to provide cutting edge interfaces through fat client and
web browsers.  I don't think that RPGIII has nearly the same mission,
making it a much easier task to maintain backward compatibility.  From
an interface perspective, it is not attempting to keep pace. Our users
are starting to reject green screen, and I think it will only get worse
over time.  .NET is an easy way for us to provide friendlier custom
looks at our iSeries data for managers and other information users,
prolonging the life of our core applications for the data generators out
in the plant who are perfectly comfortable with the older interfaces.  I
think they compliment each other.  Java could also provide this
function, as Joe suggests, but I am put off by the different class
libraries, IDE's and other underlying technologies being advanced by the
different players now.  Choice is a two edged sword in development
tools.

Joe, I also don't think it is fair to judge backward compatibility by
comparing 10 year old games to System 38 programs. Games almost by
definition are pushing the envelope in terms of the hardware they are
released for, nearly guaranteeing they will crash and burn on later
hardware.  There is a planned obsolescence in the gaming world that
makes this a poor comparison.

We also need to remember that Microsoft only has full control of one
side of the equation, the software.  IBM retains full control of both
the hardware and software, making compatibility much easier again.
Apple is currently using this argument to resist the idea of Mac OS
running on standard PC hardware, by the way.

I would also submit that part of the problem was that VB6 and COM were
not great products.  VB6 had a lot of quirks and feeble object
orientation capabilities.  I am not at all sure it was a model worth
continuing.  DCOM and Visual Interdev were even worse.  Yes, Microsoft
could have done a better job of backward compatibility.  I used the
conversion tool to open some of my VB6 projects in .NET early on, and
decided that the resulting code changes left me with an indecipherable
mess.  I was lucky, I only had a few applications to rewrite.  However,
from a programming standpoint, .NET is a far superior product compared
to the things it replaced.  Pure speculation on my part, but I really
believe the .NET framework will have a longer life than the VB6 runtime
because it is a much firmer foundation than the disjointed set of tools
that MS had before.

I really don't enjoy defending Microsoft, they have done a lot of lousy
things to their users over the years, such as $500 office suites, DCOM,
Windows ME and Software Assurance among others.  However, in this case I
think they are getting something of a bad rap.

Thanks for a great forum.

Jim Reinardy
Badger Meter, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, June 16, 2005 4:18 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: RPGIII compiler vs Visual Basic

> From: Walden H. Leverich
> 
> If you called up
> IBM and said the chain opcode wasn't working in a RPGIII program and
you
> wanted them to fix it as part of your warranty think they would?

Absolutely.


> Also, the issue w/Longhorn has nothing to do w/VB running, but rather 
> has to do with the runtime DLL (VBRUN60.dll) being distributed as part

> of the OS. If you distribute the DLL yourself it should continue to
run.

But won't be supported.

Walden, you and I are disconnecting major here.  Maybe you don't
understand how OS/400 works, being as you've been ensconced in the Dark
Side for so long... if I were to take an old S/38 program and restore it
on a brand spanking new iSeries and it caused a machine check, I could
call IBM and expect a fix.

Not only that, but for the most part, I could make changes to the
source, compile it, and expect THAT to work.

Do you understand this concept?  Do you understand the incredible
magnitude of this capability compared to what passes for support in the
Microsoft world?


> Of course, the exact answer to what will and won't run in the final
bits
> of Longhorn can't be answered until it's released, but early betas of 
> Longhorn have been seen running VB apps.

And here's another difference between the philosophies of the companies.
IBM expects your old programs to continue to work, Microsoft guarantees
no such thing.  You yourself have no idea what the next release will
support, whereas I'm comfortable that my programs will continue to run
and run and run (that's also one of the primary reasons I believe in
make vs. buy, by the way).


> Part of the problem w/shipping the vb runtime as part of the OS is
that
> it then falls under the support timeline of the OS. For example, since

> the vb runtime shipped w/XP and XP doesn't end extended support until
> 2011 MS has to support the VB runtime until 2011.

Says who?  In fact, I'll bet you fifty bucks right now that you will NOT
be able to run VB6 programs on any new Windows machine shipped in 2011
(let's say a Dell shipped with Windows pre-installed).  I absolutely,
positively guarantee it.  Let's pick a nice, juicy VB6 application
today, and stick it in a time capsule and see if it runs in 2011.  (You
can put it in a ZIP file and store it on an iSeries, since you know that
will still be running in 2011.)

Anybody else want a piece of this?


> Since MS has stated
> that support timelines are roughly 10 years post release if Longhorn
is
> released in 2006 and contains the VB runtime that would require MS to 
> support it until at least 2016. And remember, "support" means FIX, not

> RUN.

Microsoft can say whatever they want, but it's just words.  I'd be
interested to know how many programs written in 1995 run on Windows XP.
I know most of my games don't.  And yet, I KNOW that programs written in
1985 in RPG will run on my iSeries, AND I can modify them and compile
them and run them today.

This just isn't sinking in, is it?

Joe

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


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.