Having read all the replies I've got some questions and some comments
(surprise <G>)

Art mentioned that the client was looking to "redevelop ... using .NET"
but made no mention of a database. You can't replace an iSeries with
.NET alone, .NET isn't a database. We can have arguments all day long
about how _well_ you "can" replace an iSeries with .NET and SQLServer,
or Oracle, but if can be done. However, unless all your data is going to
be written to text files you can't do it with just .NET. So, are they
replacing the iSeries with .NET and a database, if so which, or just
extending the existing system with a new browser-based front end?

Art said, but many have implied that "even though I KNOW it's wrong to
go that way, I can't think of how to make my point.  How would YOU tell
them?" well, if you can't think of how to make your point WHY do you
"know" this? Perhaps you should reevaluate your position, if you can't
defend the position perhaps it's not defensible. Perhaps I'm to much of
an optimist, but until someone can show me why I can't do something I'll
believe I can. 

John mentioned the "732 reasons not to use .NET" but Rob had a valid
counter, isn't this the same as "integrity ptfs"? Beyond that, if you
want to count apples and apples, don't forget to count WebSphere, Java
and Apache issues in that mix, because you need all that to cover the
.NET universe.

Additionally, how many issues can't be found on the web for the iSeries.
IBM and the iSeries are great at security by obscurity. How many know
about a "small problem" where you can crash and entire high-end iSeries
by doing a System Request 2 during a query? We're not taking about an
old bug, we're talking about V4R4 to V5R3 problem that isn't PTFd yet. 

Steve mentioned that they have their green and black ERP system running
on IE via WebSpehere and it's slower and not as stable. However, is that
slowness and lack of stability (and screen real estate) really IE's
fault, or is it that the translator WebSphere uses isn't stable. Steve,
question for you, where's the instability. Does IE stop working and XP
hang, or does the interface between Websphere and the iSeries get messed
up? As for the screen, you're using a browser as an emulator, use it as
a browser and you'll get back the real estate you need.

Jay mentioned things you can't do in a browser. I disagree. As for
column headers, since you can't have more than 24 lines on a screen in
5250, simply implement the same limit on the web and use Prev and Next
buttons. However, if you want to take advantage of what the web offers
then you can have fixed headers. Want to see scrolling with fixed column
headers? Look at http://w3.techsoftwareinc.com/scroll.htm  I'm not sure
what you mean by manipulate w/o rerunning select, so I'll leave that
alone. As for validating input w/o refreshing interface, sure you can --
Look at hidden windows or IFRAMES. Why can't you run a job that takes >
1 minute? If you don't want to roll your own, use the native model, it
works fine. I'd like to know why SQL injection "will be a problem" on
the web. A well designed app is immune to SQL injection. However, a
poorly designed one isn't. SQL Injection isn't a function of the choice
of platform, it's a function of the quality of code.

Pete mentioned having to lock everything that is read for update -- HUH?
If I can read it w/o a lock on the iSeries why can't I on the web? As
for data transfer rates, I assume we're looking at "local" machines
since we're speaking of an ERP app. I would imagine it all 10MBit if not
100MBit ether, so rates aren't an issue. As for communication, why not
simply use IBM's .NET provider? It's a native provider that seems to
work well. 

OK, that's all for now. 

-Walden

------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
  


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.