John, Joe, Brad, Evan

(Sorry, long post.  But a difficult subject.  Thought I better split into
two, for length.  Second part relates directly to the first, and more to the
topic.)

(continued from Part 1 of 2)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All that to say:  how this relates to this thread is that it's real tricky
business trying to decide when the CW is right on target, and when it's
heading 180 degrees in the WRONG DIRECTION...!

To get back on-topic:  I don't mean to imply that someone with less
experience than I have can't teach me a thing or two.  But I don't know if
the following POV will make much sense, unless your experience goes back to
OS/400 version 2.


When they started pouring a lot of development dollars into TCP, back at
OS/400 version 3, I thought it was a waste of resources.  (I mean, SEU
hadn't seen enhancements for years.. so why pour money into TCP, which few
400 shops used, back at that time.)  Clearly, this was a MAJOR-LEAGUE GOOF,
on my part.

(OTOH, another IBM made a MAJOR-LEAGUE GOOF, about that same time, IMHO:
they couldn't find enough MI programmers, so they re-wrote a lot (most?) of
OS/400 in C++.  At the time, I thought that was a GOOD move, but now I see
that as being one of the biggest mistakes in the history of computers.
Because that has resulted in a lot of the fundamental assets of the iSeries
being watered down by today's CW.  The baby has been thrown out with the
bath water, now, and I think abandoning MI has an AWFUL LOT to do with this
fact.  Software Group doesn't want to support MI, because C++ programmers
are a dime-a-dozen, but MI is still one of the greatest creations existing
in computer history, nonetheless.)

So the issue of whether 400's should be connected via TCP is very difficult
for me to decide.  The resources ARE NOT going into SNA...  That DOES factor
into the decision.  TCP provides MUCH BETTER performance, no doubt, but
who's to say that isn't because IBM doesn't put any resources into SNA...?
Who's to say if IBM will EVER put significant resources into SNA...?!?

I dunno...


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do we need n-tier design?  I can't even guess, from my knowledge, if this is
CW or not.  That's the issue:  is this another example of CW gone
haywire...?!?  I dunno.

Do we need n-tier platforms?  I can answer that one.  If the iSeries
improves, in just a few areas, this becomes CW that MAKES NO SENSE
WHATSOEVER...!  The theory that adding another platform is as easy as adding
another programming language to your toolbelt, IMV, shows that both these
are hard points to defend.  I base that on experience.  Adding layers to
already extremely-complex-enough business problems, is NOT the direction to
head to...  IF ANOTHER ALTERNATIVE SOLVES THE PROBLEM...  Any alternative
will do.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do we need a new programming paradigm, to solve today's business problems...
IMV, the CW is sadly mistaken on this point.  With abundant due respect to
Joe, and just about everybody else:  In my experience these new paradigms
cause one overwhelmingly significant problem, which overrides any possible
benefit they might, and DO, have...  Only the best of the best can make
EFFECTIVE use of these "new" paradigms.  One of these "new" paradigms, OO,
has been around for 20 years or more...  If it was the sliced bread and can
of peas, more people would have become proficient enough for it to have made
a signficant dent in the programming bottle-neck.  I haven't observed that.
IMV, it's just not a SIGNIFICANTLY SUPERIOR method of doing modular
programming, to make it the panacea it's billed as.

Again, IMV, modular code--> "it's a good thing" (tm).  New paradigms--> each
gets more complex and adds more layers of abstraction.  The KEY (in my
experience) is getting code to model the business AS CLOSELY AS POSSIBLE,
and TOO many layers of abstraction are MUCH WORSE than TOO few.  (I'm still
formulating views on what that "right level of abstraction" is, BTW.)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It *sure seems* like LPAR is the way to go on this, but I don't know enough
about it.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here's the thing:  these could all be separate threads, and IMV there should
be more than one thread going on this subject.  These issues are all
interwoven, but they do not DEPEND on each other, precisely.

IMV, here's the question... which I don't have the answer to:  CAN the
iSeries be made ABSOLUTELY SECURE...?!?  When I say "absolutely", I allow
for the absolute fact that Rob and others have stated...:  given the time
and resources, anything can be hacked.

So when I say "absolutely", I mean almost impossible to crack.  Subtle
difference, but I said "absolutely" to imply an *extremely* small likelihood
of being cracked, using EASY TO IMPLEMENT security features, that allow
SUFFICIENT access to secure data, WITHOUT SACRIFICING performance and
man-hours (either user's or admin's).

These, of course, involve trade-offs.  But I'm fairly convinced that you CAN
make these diverse and contrary objectives meet somewhere towards the
middle.  I don't have sufficient knowledge to DO this, but still I think
it's do-able.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One reason I said, at the start, that I can't pursue this too far:  lack of
academic degree.  That's bull-hockey, in a sense.  Of course what I'm
meaning is that I lack a great deal of knowledge in a lot of these areas.
Everybody does, so that's just a given.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

More questions than answers, I s'pose.  But I think separating this into
distinct, but related threads will go a long way to actually shedding more
heat, than light, on this issue.

jt

(probably off-line most of the day...  a few things backing up...)-:



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.