AS/400 How does it look?

[Terrence Enger]

On Thu, 2008-08-28 at 22:51 -0400, Christopher Browne wrote:
> 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:

Indeed.  I was letting myself be too much influenced by my recent
experience, which is with old code, which is where I tend to find the
too-broad exception handling.
> 
> - 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.

There are catastrophes and then there are castrophes.  I see incorrect
response and incorrect database updates as increasingly catastrophic
beyond a mere failure to respond.

Still, I have to agree with you.
> 
> - 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.

Hmm, less a question of being batch-oriented or otherwise, I think, than
it is a question of serving a well-defined set of users doing narrowly
defined tasks.  Things are, at some level, quite simple.
> 
> 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 :-).

Well said.
> 
> > ( 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 :-).

Oh, my.  A merely disgruntled customer can give me an entirely adequate
level of stress.
> 
> >> 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.

Well, from past experience, I can tell you exactly how I would receive
improved improved scheduling capability:
(*) Ho hum.  Well, it looks useful for a couple of things.
(*) I visit old site which lacks the facility.
(*) I realize that have grown into the habit of using it a *lot*.

Moving forward is easy; going backward really hurts.

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

QNX was the example O/S in a course I once took.  I have never had a
chance to use it in real life (let alone in real-time life <grin />).

One lesson in the course was the value of run-time assertions, and the
way they can help a project reach completion.  Hmm, I guess I have been
using what I learned more than I have bothered to think about.

Thank you, Christopher, for you thoughts.

Terry.


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