Re: Would it be a reasonable to ask IBM's programmers to, write a %sortsfl(sfl: column)

The system still has some significant design strengths. Being able to
easily view a job's call stack. Object authority is very nice and
straight forward. The concept of a job, which persists as it
transitions from job queue, to active, to complete with its associated
output and joblog is great for organizing and troubleshooting work
that runs on a system. Features can be added to joblogs to give them
a hierarchical structure. Also, allow additional info to be stored in
the joblog. Like, a copy of the CSV text stream that was used as input
to a called program. It would be very useful if reports written as XML
documents could be viewed from the perspective of a completed job.
Just like you can currently view spooled output of a job.

Having an integrated database is superior in practice to the database
server concept used in Windows. Superior because it is easier to admin
and write code against an integrated database than a server database.

System backup and recovery works very well on IBM i. Much more
functional that what I know of Windows Server. ( It is amazing that
these great features of the system were design by presumably a handful
of people some 35? years ago )

I see poor performance of components of the system like stream files
and the JVM as an indicator that IBM mgmt has historically starved the
system of development dollars. The 16 meg segment size limit of the
system is a limitation imposed by the capabilities of computer
hardware from the 1970s. SLS has to be overhauled or reevaluated as
the basis of the OS itself. I am fairly sure that a liberal and
sustained application of programmer hours could solve all of the
performance shortcomings of the system.

If the question is can the system remain viable into the future, I
think the answer is a definite yes, but that IBM has to open source
it. IBM is simply not in the operating system, run time framework and
programming language business anymore. Judging by the seeming failure
to hold any of the higher ups accountable for the Moffat fiasco, ( the
day traders were caught on tape scheming about where to place Moffat
next. As in, they had been instrumental in putting him into his
current job, so they could assume they could move him elsewhere. ) I
have zero confidence that anyone running the company has the authority
or vision to run a world class software company.

-Steve


On Wed, Dec 9, 2009 at 2:39 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx> wrote:

Wow.  John, in your whole tirade, the only complaint I can see against
RPG is that subprocedures require too many lines of code to describe
their parameter list...  is that correct?

And because of that, you think that nobody uses procedures (Which I
don't agree with, by the way.  More than 60% of RPG shops are using
procedures these days, and the ones who aren't are doing so because they
are maintaining the status quo -- not because it's too many lines of code)

I agree with you that "information hiding" (encapsulation) is very
important, but RPG does that as well as any other language does.  Yes,
via procedures.

Really, the biggest problem with this platform isn't RPG.  It's OS/400.
 OS/400 has some modern features, it's true, but by and large it's an
outdated OS operating on an outdated paradigm.  TCP/IP works on OS/400,
but doesn't perform as well as it does on other platforms.  Stream-file
access (which by all logic should be faster than database!) performs
very poorly on OS/400 vs. other platforms.  Apache, Java, WebSphere,
Tomcat and PHP are all examples of things that we have on OS/400 that
perform better on other platforms.  OS/400 just isn't designed for the
type of workload that these modern techniques require from an OS.

Plus, have you tried installing OS/400?  It's not exactly a
user-friendly process.  You have to go through hundreds of pages of
documentation.  No other software installation anywhere puts you through
that!  And the documentation isn't very good.  If you aren't already
familiar with it from decades of doing it, it's REALLY hard and really
scary.

OS/400 (or IBM i -- sorry Trevor) needs a LOT of work if it's going to
be viable for the future.  It's still designed and optimized for 5250
workloads, and really nothing else.

The other really big problem with this platform is the people don't
actively learn and incorporate new concepts. They keep doing things
exactly the same way they always have, without learning about new
features or how it can help them.  Only when the rest of the company
puts pressure on them do they take the time to learn something new.

TCP/IP is a great example.  With the TCP/IP software I distribute, I've
discovered than more than 80% of shops out there don't have the DNS
resolver configured on their system.  You'd NEVER see this in a Windows
or Unix shop.  Not only that, but people in this community are baffled
about TCP/IP when something doesn't work.  No Windows or Unix admin is
so ignorant of how TCP/IP works!

There's just this general attitude on this system that people shouldn't
change the way they do anything, or learn anything new until they are
forced to do so.  (That includes RPG programmers as well as OS/400
admins, by the way.)