Re: Where are all of the /400's going. Was: QUSER on ODBC requests

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