×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.




This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Not to pick a fight or start a war Adam, but what platforms do you know of
that do not have a COBOL compiler on them, and what better language is there
for writing client server business applications that thousands of people can
probably understand?

However, I am biased! but I do agree with your suggestion about Java, I just
disagree with the premise of your argument to get there!


-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Thursday, October 17, 2002 10:33 AM
To: midrange-l@midrange.com
Subject: Re: Development ideas


To agree with Joe, I would look at a Java solution.

You can develop for one platform and have a lot of flexibility to move to
another if needed.

The same expertise your coders have on making the server side application
components will also extend to make a java "fat client" or web based applet.

JDBC will interact with nearly all databases out there (from DB2 to
PostgreSQL (open source)).

The only thing I would recommend besides Java would be C, then next
"portable" language.

I think when redeveloping applications, you want to avoid "lock in"
situations,which would be the situation when using RPG or COBOL.  You will
be basically forcing reliance on the AS/400. Going a Java route, it makes
you more adaptable, as I see it.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Thursday, October 17, 2002 10:46 AM
Subject: RE: Development ideas


> > From: McBride, Catherine
> >
> >      We have an opportunity to rewrite an entire system using whatever
> > platform we select.  It's currently mainframe based.  I have been
> > asked what
> > development languages and tools there are for the AS400.  We have
> > an 820 and
> > use RPG and COBOL already.  What this programming group seems to
> > be looking
> > for is object-oriented type stuff, though.  We're fairly new to the
AS400
> > world.  Is there GUI-based application development for the AS400?  What
> > languages?  The programming staff would like to be able to
> > develop and test
> > quickly, and have a full complement of programming tools to work
> > with.  The
> > programmers who would be writing this system have VB and SQL server
> > experience.  If any of you have suggestions for us, we'd be very
> > appreciative.   Thanks much!
>
> Wow!  What an opportunity!
>
> There are a million questions that should probably be asked, but let me
> preface this by saying that the iSeries (a/k/a the AS/400) can work and
play
> just fine in an SQL environment.  Many of the folks on this list are very
> versed in using SQL, especially the wonders of stored procedures, to
> efficiently interface between languages such as VB and the more
> business-oriented languages such as RPG and COBOL.
>
> Okay, on to a couple of your questions.  There is no native GUI for the
> iSeries, although there is extensive support for browser-based UI.  Is
your
> application going to require a thick-client interface or a browser
> interface?  If thick-client, are you a Windows shop or will you be using
> non-Windows platforms at some time?
>
> The reason I ask these question is because they will determine your choice
> of UI development tools.  The fact that your developers are primarily VB
> folks means they will be skewed towards Windows thick client interface,
but
> you need to be sure that this is what your end users need.  For example, a
> thick-client interface may not be the best for Internet access.
>
> And even if you do go with a thick client, I would suggest looking
carefully
> into an n-tier architecture, where there is little or no business logic on
> the workstation.  Instead, the business logic (validating transactions,
> updating the database, and so on) would be written in a traditional
iSeries
> language such as RPG, and the thick client would access these programs
> either through stored procedures or through a more traditional
client/server
> protocol.
>
> In this sort of tiered architecture, the iSeries is a powerful server.
It's
> built in security and auditing features make it a great centralized data
> repository.  Not only that, with a good n-tier design, you can support
> different UIs based on your needs.  The same business logic servers can
> support thick clients written in VB, Linux application written with Java,
> and browser-based applications usnig servlets and JavaServer Pages.
>
> Anyway, I just thought I'd chime in on some of the things that make an
> iSeries a great server for an application such as this.
>
> Joe
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 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.