Spooler, Spoolcom, peruse, Supervisor. The confusion!

[Shiva]

Hi all, This one topic I've never understood completely though I've read lots and lots about it. Coming from a mainframe background, I've seen only one Spooler - one place to see all my jobs. (sd;st) Though they are different for different regions (test, development, production) - it has always been like, one spool location for one region. And it was perfect. No confusion.

But the confusion with tandem's spool concept is that there is no one thing called as spool. What is a spool actually? A collective of supervisor and collector and printers, et al!? So there are so many things that you can't enter a command and say, "Boom, this is the spooler!"? Okie.

Forget that. What do we mention in OUT when we compile? If we want our job to be in the spooler. We mention like this:

C /IN <program_code>, OUT $SD.#JNAME/ OBJ; highpin, runnable.

Here $SD is a spooler collector? Then how do we go to peruse or spoolcom of that particular spooler? By entering that alongside the peruse or spoolcom command? Like:

peruse $SD (or) spoolcom $SD

Like this? But I have a case, in G series tandem, in a system - where we submit like this, and we enter there peruse giving such a command. All this is fine. But read the following.

I recently read a command called: Spoolcom collect.

It should show all of my spooler collectors, right? For that system, probably. In the above case, it did not show my spool collector at all!? And I guessed it should show many, but it showed only one name there. I don't know why or what. It was not $SD. Something else. $S, it was. And only that was present. Why so?


Case 2 now: I work in a J series tandem as well, where I use a similar command to compile:

C /IN <program_code>, OUT $SG.#JNAME/ OBJ; highpin, runnable

Say in this environment that $SG is the spool collector. (I also have to say that, no matter what I give - even a spelling mistake - it goes right into the correct $SG spool collector, I don't know how!)

And if I give the following command:

peruse $SG - I get some error saying that unable to open. But if I just give : peruse

I'm able to see my job. It does not give any information about the name of the collector after I enter peruse. So I don't really know if I'm working with peruse on $SG. But I see my job.

And like before, if I give the command spoolcom collect - I'm able to see a lot of collectors (nearly 8) including $SG.

I don't understand why G & J series give such different results - may be they are configured in such different ways. But since I don't even understand the way how things work here, it seems all very complex.


Can some Sherlock Holmes, clarify on this? :)

[Shiva]

Also is there a way to delete some 10, 20 jobs in one go? From your spool collector? Just because it's a clutter. del, just deletes one job at a time.

[Keith Dick]

I think most of your confusion would clear up if you read the introductory section of the spooler manual, where it explains how the pieces fit together.

Briefly, the spooler supervisor controls the collectors, print processes, printers, etc.

You send a spooler job to a spooler collector.

PERUSE and SPOOLCOM talk to the spooler supervisor to work with jobs in that supervisor's collection of processes.

The default spooler supervisor name that PERUSE and SPOOLCOM uses is $SPLS. So when you don't tell them any different, that is "the spooler". But you can give the spooler supervisor's name on the PERUSE or SPOOLCOM command line, and they will work with the jobs under the control of that spooler.

I don't know how to explain that your OUT file works properly even when you misspell it. An exact example might be helpful. Did you misspell $SG or the part after $SG? Some possibile explanations are: the misspelling you made happened to be another valid collector name, you misspelled the part of the name after $SG.#, and it created a holding location not connected to a printer, you misspelled the part after $SG.# and it happened to be another valid location connected to a printer, your site uses a $CMON that edits the OUT files of your commands, and it just happens that what you misspelled is something it replaces.

spoolcom collect will show all the collectors controlled by the default supervisor, $SPLS. There apparently is at least one other spooler supervisor in your system controlling the collector you used.

You should be able to learn the names of all the supervisors with the command:

STATUS *, PROG $SYSTEM.SYSTEM.SPOOL

The process name of each of those processes will be the first thing on each process' output line.

SPOOLCOM can delete multiple jobs in one command. You can supply a number of selection criteria to determine which jobs to delete. Look up the exact syntax, but I believe something like

SPOOLCOM JOB *,USER

will list all the jobs owned by you

SPOOLCOM JOB *,USER,HOLD!,DELETE

will delete all the jobs owned by you. (Maybe the ! goes after the DELETE -- I don't remember right now.)

SPOOLCOM JOB *,LOC #xyz

will list all the jobs that have location #xyz

SPOOLCOM JOB *,LOC #xyz,HOLD!,DELETE

will delete all the jobs that have location #xyz

SPOOLCOM JOB *,USER,LOC #xyz,HOLD!,DELETE

will delete all your jobs that have location #xyz

There are more options for selecting the jobs. You can do more than list and delete, too.

If I didn't answer some of your points, ask them again.

[Shiva]

@Keith: Thanks again for the detailed explanation. I'll go read the Spooler manual, first thing tomorrow! Thanks again.

[Warren M]

@Shiva, Something you will find common across many Tandem subsystems, including the spooler, is that there is a "manager" process that keeps track of the subsystem and multiple "worker" processes that manage individual tasks.

The spool supervervisor ($system.system.spool) manages the collectors, jobs, locations and printers which are the objects that comprise a specific spooler environment.

An installation can run multiple spooler environments on a system, or they might run just one, depending on the needs of the installation. There might be a different spooler environment for different groups sharing the system. This can reduce resource conflicts.

The spooler was written back in the days of TNS/1 so they were originally some pretty small limits in the spooler. For example, the original limit was 4K jobs per spool supervisor, but this was later raised to 65K jobs with the Spooler Plus product. Running multiple spooler subsystems was a way around these early limits.

A spool collector can have 256 opens (1024 with SP+). So if you want to have more than that number of concurrent files writing to the spooler, you need multiple collectors. Collectors are often setup with different size data files. Sometimes a shop will create a $S and a $L collector, with the $L collector assigned to a data file allocated to accept large jobs. Collectors can also be set up with Safeguard securty to that only members of a certain group(s) can write to a particular collector. It all depends on the needs of the organization.

[Shiva]

I get that. And I was confused when I was learning with respect to my organizational structure as it was a bit different from what was quoted in the book.
Hence most of the confusion, but should've guessed it. :)