AS/400 How does it look?

[Terrence Enger]

On Thu, 2008-08-28 at 09:33 -0400, Christopher Browne wrote:
> On Thu, Aug 28, 2008 at 9:07 AM, Terrence Enger <tenger-P1ovA8G34VBEfu+5ix1nRw at public.gmane.org> wrote:
> > On Thu, 2008-08-28 at 02:37 +0300, William Muriithi wrote:
> >> Terry,
> >>
> >> Many thanks for your explanation. I am now more knowledgeable on
> >> AS/400 platform. You really did a good job and I noticed it triggered
> >> some serious conversation over there. It did even get off topic and
> >> become car technology discussion. Noticed a lot of people there still
> >> think a solid car is safe. Someone corrected them very well, an easily
> >> collapsible car is far much safe.
> >>
> >> Regards,
> >>
> >> William
> >
> > William,
> >
> > I am really surprised by the level of interest over there.
> >
> > The self-sacrificing car seems like it should give some lesson to us in
> > computing, but I am stuck trying to figure out what that lesson might
> > be.
> 
> It's pretty clear:  You need to be sure to solve the *right* problem.
> 
> At first glance, having the car survive the crash *seems* like the
> right idea; if it's not too badly damaged, that seems an obviously
> good thing, right?
> 
> Unfortunately, its survivability distracts people from the *real*
> goal, which is to preserve the lives of the passengers.

The closest parallel I can think of here is a programming practice which
really bugs me.

It is somewhat common for a program to catch run-time errors and eat or
mangle the diagnostic information.  I suppose the programmers do this in
aid of user-friendliness or something.

My own preference goes to the opposite extreme:  upon occurrence of a
run-time error, halt.  Halt hard.  Right now!  And be in the user's face
about it, too.  I have even been known to override a system message
definition to disallow the carry-on response.  When the program must
catch (what the system deems to be) an error, catch the smallest
reasonably catachable set of errors; hmm, sometimes go beyond what comes
easily.  I hate to brag, but my users end up seeing very few system
messages.

( Of course, there are lots of times when something that the system
calls an error is to the program a perfectly normal situation.  And
there are times when an error condition really is an error, but it is a
common condition which for which the application can give a better
message than the system can.  These are not what I am talking about. )

Still, the automotive parallel is not very close.
> 
> I browsed the thread; certainly some interesting points were made.
> Everyone didn't agree, but that's a good sign of there being at least
> some diversity in the group :-).
> 
> Something I'd be interested in hearing more about is the "jobs"
> concept.  

A job tends to cover a significant amount of work.  For example, an
interactive job typically persists from arrival in the morning until
going home at night.  Or maybe just until the user goes out to lunch.
At an installation I recently worked at, typical turnaround for a batch
job was between one and two seconds, but one batch job commonly ran for
a week at a time.

Compared to a task in Linux, a job is definitely a heavy-weight item,
expensive to create and expensive to destroy.  Within the POSIX
environment, some tasks are implemented as jobs, leading to exactly the
serious performance hit that you would expect.

There are compensations.  It is easy to start and end background jobs.
Interprocess communication is efficient, and it is--so far as I can tell
from my limited experience with Linux--easier to program.  One simply
gets out of the habit of running a lot of jobs.  Then, with there being
fewer jobs on the system, the job becomes a quite handy unit of work to
track or manipulate.

> To be sure, the usual Unix notion of "oh, just run cron" is
> severely deficient.  It is unfortunate that there hasn't been an
> outgrowth of free software alternatives to cron that are fundamentally
> better.
> 
> I have asked about this sort of thing before, both on this forum, and
> elsewhere; here's some summary of my thoughts...
> http://archives.postgresql.org/pgsql-admin/2007-07/msg00034.php

There is an awful lot there, more than I am prepared to read now.  Here
is what I can say, just off the top of my head.

The system i lets you define as many job queues as you find useful.  A
queue may be restricted to one job at a time, or it may run several jobs
at once.  (Well, actually, each job queue is a priority queue, and you
can specify the maximum number of executing jobs per priority.  But that
is TMI, so I didn't write it, okay?)  Job queues can be held or released
individually or in groups.  In my own programming, I have never needed
more than a small part of the available functionality.

The system includes a basic job scheduler.  Add-on products are
available for prices from four digits on up.  I have never had any
excuse to look very far into the "on-up", but some of these products
claim to offer complete lights-out operation.  Myself, I cannot imagine
how to remove a backup tape for transmission off-site without turning on
a light in the computer room, but that is what they claim <grin />.

The basic scheduler can schedule a job for a specific date and time or
for repeated execution on particular days of the week or of the month,
with the possible exception of a list of particular dates.  The
scheduler lacks any concept of a collection of jobs, leading to ...

(*) There is a lot of entries on the scheduler.  Very simple programs of
the form 
        call step1
        call step2
        call step3
    help quite a bit, but the nuisance remains.

(*) Maintenance of the entries is tedious and error prone.  For
production jobs, I limit how often I make changes (this part comes quite
naturally), and I have a customer person check each action.

(*) The scheduler knows nothing about dependencies between jobs.  In
practice, I have not found much difficulty here.  For example, I want
day-end complete before month-end starts, so I send them to the same
one-job-at-time job queue.  Still, I can imagine that even a slightly
more complicated environment would require more control and that that
control would most economically be provided by an add-on product.

Cheers,
Terry.


> 
> I'd be interested in hearing what AS/400 (or whatever it's sold as
> this week :-)) has as its "basic concept."

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists