Re: [OT] Screen (was Affecting Inst. Change)
On Fri, May 11, 2007 at 12:06:09AM EDT, Ron Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/10/07 22:34, cga2000 wrote:
> > On Thu, May 10, 2007 at 06:04:06PM EDT, Ron Johnson wrote:
> >> On 05/10/07 11:27, william pursell wrote:
> [snip]
> >>> be sitting in the editor where you left it. It provides
> >>> continuity by allowing you to leave your shells running
> >>> for months at a time without having to put those
> >>> phenomenally lame signs on your monitor that say,
> >>> "please don't log me out, I'm running a simulation
> >>> that may take a while and have to lock up this terminal
> >>> because I don't know any better."
> >> Yes, but competent OSs have batch queues for running such jobs. Why
> >> Unix has never had such a capability is beyond my understanding.
> >
> > Not an authority on these matters but maybe this may have to do with the
> > fact that the hardware was designed to do heavy batch processing in the
> > first place. And so the OS .. and later .. the applications followed
> > suit.
> >
> > Assuming what I have in mind is an example of a "competent OS"
> >
> > :-)
> >
> > So your question might be turned around as in .. how come an OS like
> > MVS, for instance .. has/had at least four "job schedulers" that I can
> > think of off the top of my head .. and all of them save one from
> > third-party vendors.
>
> Because JES2 & JES3 suck?
They're not the most lovable beasts I have encountered so far, but
they usually do their stuff without bothering anybody.
On the other hand, they cannot really be compared to "cron". The way
they categorize jobs is based on making the best global use of the
system's resources. A crude example might be that a given job will not
be started because it belongs to a predefined category and the local
configuration of JES2 or JES3 specifies that only two such jobs should
execute concurrently .. and as luck would have it there are already two
other jobs that belong to the same execution class that are currently
running .. and even when either one of these two jobs ends it may very
well be that this particular job will not be released just yet ..
because there are already a couple more such jobs ahead of it in the
queue.
I can't think of anything comparable in the *nix world .. although by a
very wild stretch of the imagination .. they seem to me somewhat closer
to some form of daemonized incarnation of the "nice" command than to a
job scheduler like "cron".
The mainframe job scheduling applications that I had in mind, such as
OPC/A .. CA-7 .. CA-scheduler .. Control-M .. are a lot closer to cron
.. insofar as they work with databases of job definitions similar to
crontabs that specify that such and such conditions must be met before a
given job is released for execution .. date and time .. naturally ..
"cron" ibid. .. but also other interesting prerequisites such as the
creation of a file .. the successful completion of another job or job
step .. etc.
My understanding is that on current mainframe environments these
functionalities have been integrated into software such as Tivoli or
CA-Unicenter .. but since I haven't been anywhere near a mainframe in
what .. fifteen years .. ?? I wouldn't bet a nickel on that. These are
pricey software that won't make sense for the guy who's been running the
same batch jobs every night for the last thirty years on some old rusty
IBM-4381 .. but probably worth considering when you manage a large data
center with state-of-the-art sysplex technology that's become too
complex to be handled manually.
> > It's just about all these machines do but they do it very well.
> >
> > So if you are serious about running hundreds of jobs every night that
> > basically open a bunch of files do a few million I/O's and close the
> > files .. all without any form of human interaction .. you probably want
> > one of those.
>
> IBM's big systems are the canonical examples, but other OSs also
> have batch queues. OpenVMS & OS/400 being other examples, but VMS
> is also an excellent interactive OS.
Which .. MVS .. z/OS .. etc. clearly are not .. Doing something as
trivial as a *nix shell's "|" in such a batch-oriented context is not
possible .. and getting two different processes to communicate by any
other means requires some rather complex programming.
But as mentioned earlier.. these particular machines and their extensive
peripheral environments were mostly designed to execute programs that
loop over millions of pre-programmed GETs & PUTs with some very
elementary computing in-between.
And not much else.
Interaction with human beings apparently didn't initially strike the
designers as a useful feature .. came in later .. as an afterthought ..
exemplified by CICS .. kind of a minimal sub-OS with its own memory
management .. task scheduling .. threading .. etc. running inside the
"real" OS..
Incidentally, one clear sign of the mainframe world's recognition of the
*nixes is the fact for the last ten years at least .. MVS can run a UNIX
as a subtask.
http://www-03.ibm.com/servers/eserver/zseries/zos/unix/
Even has SMB for goodness's sake..
;-)
Thanks,
cga
Reply to: