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

Seems like I inadvertently had something to so with starting this so I
should weigh in with a comment or two and take my lumps :)

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

It doesn't make sense to let the least secure boxes in your organization be
connected to your biggest exposure either. Get a firewall, secure the box
and deal with it.

> > 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 guess it depends on where you see the "business" being done, now and in
the future. If your CEO sees the web as the place to do business, then your
business machine shoudl be there. If your major platform can't be exposed
to the internet, what's the point ? To my way of thinking, if you put an NT
or Unix machine on the net in preference to your AS/400 you are saying a
couple of things:

- The AS/400 is just a "departmental" machine (an internal network server)
- The NT or Unix box is more securable

Essentially you are saying to your bosses (unintentionally or not) that the
AS/400 for one reason or another can't deal with the internet and is obsolete.

If the web is where business is going to be done, then that is where the
AS/400 has to be.

I agree that directly placing the company data on the web is foolish, but
surely that's a matter of  doing the work to implment appropriate security
? I'm less than keen on having a box out in front of the AS/400 on the web
that in my view is more likely to be compromised. Putting an NT or UNIX box
out there is like creating a staging area into your network.

For reasons of scale and security the kind of suggestion Joe made with
having two AS/400's connected by SNA makes a lot of sense (maybe LPAR can
help here) although I have to confess I feel like IBM's pricing conspires
against us in trying to do this. The point is to ensure your CEO knows the
AS/400 is capable of this: don't give this stuff to the NT or unix guys,
you're giving away the high ground for corporate dollars and upgrades.

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

Or another less securable point of entry. Or another database to keep in synch.

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

Why ? Another skill to learn, another product, another layer of complexity,
another thing to break, another thing to secure. This seems like complexity
for complexity sake to me. I can't help thinking that its something of a
contradiction in terms to create some kind of green screen emulation layer
on Microsoft to protect a machine you are supposedly using "as a
communicatons and networking
system"

>I could even write an application- generator is wrong, maybe
>server- interpreter?

The web server products already provide access to the data and an
interface: why add another layer ?

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

And if you deploy your machine on the machine web why not use data queues
to talk from the server to the database. It seems unlikely to me that you
could outdo this in terms of speed, or simplicity.

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


An FTP exit program is not that hard to write - we should consider
ourselves fortunate we get this level of securability. The Unix guys I deal
with don;t talk the same language when it comes to security - they just
don't seem to have any idea about blocking things on their boxes at the
level we can block access.

The point is, at least in my eyes, if you can't put your AS/400 on the web
then your GM is going to invest in where he sees the future. If the future
of the web and connectivity, what's going to happen to a box that your
recommend not be connected ? Where do you think the capital for machine or
upgrades will end up ?

Cheers
Evan Harris