× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



<I wasn't sure if Nathan was planning on replying...  One reason why
something like Sametime is so effective.>

Joe,

Thanks...  See inline.

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta
| Sent: Saturday, December 15, 2001 11:11 PM
| To: midrange-l@midrange.com
| Subject: RE: Where are all of the /400's going.
|
|
| > From: Nathan M. Andelin
| >
| > My idea of data is what you put in a database, records and
| fields.  In my
| > experience, the amount of data used for marketing and public
| awareness is
| > minimal.  Are you thinking otherwise?  Or would you agree that
| there is a
| > desire to protect the vast majority of data?
|
| I agreed with you 100%, Nathan, until I started actually implementing real
| world web environments.  In fact, the term I have been forced to use (at
| least until someone comes up with something more palatable) is "web
| presence".  Every one of my clients has had a far broader picture of their
| web presence than what I thought it would be when I first started
| implementing their web applications.
|
| For example, most sites have things like mission statements and
| client case
| studies and referals and "in the news" pages, and the clients want all of
| this to interact seamlessly with whatever AS/400 application they are
| planning on enabling.  They already have style sheets and logos
| and banners
| and color schemes, and they probably have invested a good chunk
| of change in
| their corporate look and feel.  This is the primary reason I've focused my
| efforts over the last 18 months on servlets and JSP.  If you happen to
| remember before that, I was a huge thick client advocate, because Swing is
| to my mind a better application niterface than HTML.  But in order to
| integrate with an existing web presence, I had to bite the bullet
| and learn
| how to work and play with browsers (I don't consider applets a reasonable
| alternative, either, but let's not rehash that particular argument in this
| thread).
|
| None of the existing stuff belongs on the AS/400, since it's really just
| static data, and let's face it, DASD on the 400 is a couple of orders of
| magnitude more expensive than what I can get in the store.  Even
| if I build
| a completely raided system and include a redundant machine for failover,
| it's still going to be far less expensive to do it with a *nix or even a
| Windows box than with AS/400 disk.

How much disk to these sites take...?  Unless your clients are IBM, or maybe
Yahoo or Google, I'm not seeing where the cost of disk is a significant
factor.

Seems like I could fit the content of most websites on my 8G 170,
diskspace-wise.

|
|
| > I agree that CPU is priced at a premimum on the 400.  On the other hand,
| > take into account opperational efficiencies.  Web applications
| and static
| > pages often share common graphics, style sheets, and other
| types of files.
| > It's easier to manage that on a single server as opposed to dividing it
| > between two servers.
| >
| > The management argument works both ways.  I've listened to IIS
| / FrontPage
| > Webmasters argue to deploy Web applications on an Intel server
| > for the same
| > reason.  Maybe they simply don't know the 400, and don't want to
| > learn about
| > it.  Maybe the Webmaster resists having to ask for
| authorization to set up
| > directories in the IFS.  Just another hassle, in his mind.
|
| I agree that there is a management issue, and that issue is easier to
| address when you force everything onto a central server.  In fact, I'll
| remember to take that into account when I propose architectures.

I think Nathan said it much more succinctly than I did.  It's not so much
the added Payroll dollars (which appears, by most accounts, to offset any
advantage in hardware price).  It's the political costs.  A lot of people
would like to believe there is no such thing as political infighting within
the same organization.  I'm still looking for that ideal corporation, so I
can submit my resume...;-)


Plus, it's the general confusion that's caused.  Even in the mythical
corporation with no politics, there are contrary objectives.  I've never
seen any studies on the cost of these extra layers of management, which are
due strictly to having mutliple platforms to support.  (I'm not up on the
academic literature, of course, but I haven't seen much industry press on
some hard numbers.)

But one of the easiest costs to grab hold of is how much money is wasted
doing entire OS platform retrofits, within departments or even entire
companies.  Somebody new comes in, new OS platform, hardware, software,
personnel...  Everything gets replaced, except the knowledge the prior staff
had of the business.  These conversions cost a fair bit of money.  Just the
tip of the iceberg, but it would be one of the easiest costs to get hold of.
At the end of the day:  all the money spent converting buys very little
business advantage...  So another new guy is brought in...  yada, yada,
yada...  They cycle continues...


And to be very redundant, different folks tend to support their favorite OS
platform, without regard to what's best for the enterprise.

<aside>
(Of course, I'm not referring to anybody on THIS list... (ROFL...)  But some
folk's views on these technical issues border on fanaticism...  Which is in
complete contrast to passion, which still retains some modicum of reason,
which the typical OS fanatics seem to lack...  (Again, as found on other
lists...;-)
</aside>

This is one of the easiest ways I've seen for the IT department to actually
work AGAINST the goals of the rest of the business.  I've said plenty on
that issue, in prior posts.  Obviously, this is not a good thing, but the IT
departments believe they are doing the right thing, by supporting the "best"
platform (which happens to be the one they know how to work on)...  I hate
to belabor the point, but there are significant monetary losses being
suffered, simply because of the politics of OS platforms.  You can't do a
whole lot about Gates vs. Linus vs. McNealy vs. Ellison...  But maintaining
two, three, four or more OS platforms in a business is NOT a step in the
right direction, IMV.


| The
| tradeoff will be directly related to the amount of static data
| that needs to
| be served, and the logistical requirements of keeping two separate sets of
| control data.  The control data is, as you mentioned, the style sheets and
| graphics, although it can be argued that there's nothing stopping
| an AS/400
| application from using a style sheet or image served from another machine.
| In fact, I think it's Akai that makes a business out of being a
| high-bandwidth graphics server for otherwise low-bandwidth web sites.

I thought it was something like Akamai, but I'm lousy with names (being a
numbers kinda guy...;-).  I'm guessing they don't come cheap either, but
have NO idea how the price/performance compares to 400 disk and memory.
Again, how much disk is static vs dynamic...?  NY Times, mostly static.  But
I mean the "average" business in the 400 arena, and outside of it, both.

|
|
| > Once you divide data and applications across platforms, watch the
| > political
| > turf wars erupt.
|
| The cleanest break is the division between static and dynamic data, the
| fuzziest between secured and unsecured dynamic data.  Anonymous access to
| mission critical data is always problematic, and each client I think needs
| to make that call themselves.  I think that whatever architecture you use
| should be able to handle either host-based or staged data.

Skipping past the issue of multiple platforms, from a security standpoint
only:  are there advantages and disadvantages to a single 400 vs dual 400s
vs single 400 with LPAR?  (I dunno.)

And if your talking about a need to have access to a huge amounts of secure
data, then we're getting back to the original problem:  how do you provide
access to sensitive data, which is generally on the backend.  How to give
access to this, on the Web or via TCP, without compromising security,
effectiveness and Payroll budget?

|
|
|
| > My question is whether [router] <==> [firewall] <==> [400 http server
| > configuration] <==> [application level security] <==> [object level
| > authority] is sufficient?  It seems to me that such a
| > configuration already
| > provides 5 layers of protection?
|
| I'm not sure about this.  You're correct, of course, in your assessment.
| And as long as someone implements all those layers properly, it's a good
| solution.  Rememeber, though, that the original comment that started this
| whole thread was the "requirement" to allow anonymous FTP to the host (or
| FTP with hardcoded user ID and profile, which is essentially the same
| thing).  That blows right through all five of your layers.

Ahhhh...  This is undeniable.  So back to the issue of how to provide
unattended access to secure data.


|
| Joe Pluta
| www.plutabrothers.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.