> The less current the data needs to be, the better the argument for > offloading it for two reasons: security and system load. This is reasonable it's scary. It doesn't make sense to respond to the Eunix and Microshaft zealots by being an AS/400 zealot. > The latter is pretty straightforward. Unless you have lots of extra > processing power, there's really no reason to serve static web pages from > your mission critical machine. As the currency requirements rise, this > argument becomes less valid in an inversely proportional relationship; if > you're constantly having to make requests to your mission critical server in > order to serve your web pages, you might as well run your web application on > that machine. Maybe. Do you mean from the AS/400? Why anyone would open up their AS/400 to the Internet, particularly as a web server, is beyond me. Unless you have two of them, and the company data is on the other one. > I think you are (missing the point). Data duplication may add complexity, > and perhaps some maintenance, and even some overhead, but properly done it > will never compromise security. It will in fact always enhance security by > providing in effect another firewall. Generally this is true. > > Some of the wisest words that I ever heard on this list were Evan > > Harris' response to the question "Should I put my production /400 > > on the internet?" Evan's answer was "If you don't, it won't be > > your production system much longer". The reality of the > > situation is that if we (collectively as a community of AS/400 > > aficionados) don't get security figured out on this machine to > > the point where we are comfortable putting it directly on the > > internet, the OS/400 is doomed to a dwindling legacy of green > > screen apps that may get maintained, but won't be enhanced. I have a strange solution for that - write green screen apps on Microsoft, using the AS/400 as a communicatons and networking system. You could run them on the INS, so they would still be 'inside' the AS/400. IMAHKI (If My Alzheimers Hasn't Kicked In) you can run IBM DB2 on NT (whatever they are calling NT these days). I could even write an application- generator is wrong, maybe server- interpreter? > one AS/400 running Websphere communicates > via APPC over SNA to a backend AS/400 (with no external TCP/IP access) that > actually hosts the database and the associated server applications. > There has to be a radical shift in the application development paradigm, and > it will take (HORRORS!) programming. Your primary business application > server has no business doing user interface, except possibly for dumb > terminals on shop floors. For pretty graphical UIs, let the end user eat > those cycles, be it in their browser, their wireless device, or their > thick-client workstation. Let me devote my server cycles to database > transactions (at which point maybe even those SQL requests might have some > throughput <grin>). To do that, I need a simple, flexible, robust > machine-to-machine communications methodology (and ODBC is not the answer). I thought of using two of my target scsi boards, one for reading, one for writing, to pass data in both directions between AS/400 and NT. It would be very fast. RPG program on the AS/400 reads a data request on the input 'tape', then writes the data on the output 'tape'. Faster than greased lightening and very little overhead (much less than tcp/ip) . > Heck, on my system I have a firewall > that blocks port 21, and an internal non-addressable network, and I STILL > only start the FTP server on my AS/400 when I need it. I am trying to think when that would be. It seems reasonable to make the AS/400 the FTP client, not server.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.