AS/400 How does it look?

[Christopher Browne]

On Thu, Aug 28, 2008 at 12:52 PM, Terrence Enger
<tenger-P1ovA8G34VBEfu+5ix1nRw at public.gmane.org> wrote:
>> 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.

There is a problem to be had with that; if something is to be
considered a "service," it may be extremely unpalatable to "shut down
hard," almost irrespective of the error condition.

There is a necessary difference of perspective there, which may be
part of our respective thinking processes:

- I tend to think, these days, in something of a "server" perspective,
where it is considered a catastrophe for the system not to be
responding.

- If a lot of the processes you work on are "batch"-oriented, then it
would not be surprising for that to inform your perspective, and I'd
think the "terminate early and often" approach would seem likely to be
consistent with that perspective.

I may be projecting, there; note that I don't think it's insulting to
consider having these (or possibly other) variations in perspective.
(Of course "Stupid Windoze Guy" *would* be an insulting view :-).)

We work with complex systems, and it's like the blind men with the
elephant; there *are* varying perspectives that are legitimate.
Indeed, what with there being so many layers of software and hardware
and chemistry and physics, I don't think anybody is likely to have a
single "universal" perspective that covers it all.   I just hope to
have enough perspective to get some of the "standing on shoulders of
giants" thing :-).

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

Automobiles operate via there being many explosive reactions taking
place inside them each second.  There is a risk of "explosive"
parallels :-).

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

I don't have much of a mental model what the "state" of a job, as you
describe it, looks like; I suspect that would have a lot to do with
how they work.

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

I have heard fans of VMS speak glowingly of its ability to handle job
scheduling.

I noticed that one of the respondents on the other list described
having DB2 available *everywhere* as one of the "great features" of
the AS/400 platform; I could easily see ubiquity of fairly
sophisticated job scheduling being of similar value.

I'll observe that one of the things that was "super-popular" about QNX
(an embedded Unix-like system) was its use of message passing (often
known as message queuing) as a ubiquitous, powerful thing; queuing
should appear pretty obviously similar to scheduling, so there are
commonalities to be had.
-- 
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results." -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling
--
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