Re: Replace command processor

On Tue, Aug 30, 2016 at 10:20 AM, Jim Oberholtzer
<midrangel@xxxxxxxxxxxxxxxxx> wrote:

Not so fast. What you've done is replaced the routing program, not the
command processor. Eventually the command has to get to the command
processor.

QCMD is a request processor.

So a job starts and that routing program runs. As soon as it hands control
off to the next program in the program stack, it won't get back to the
routing program until that program ends. That's not the command processor.
Most routing programs do the following (including QCMD) :
* Set the attention key if desired
* Set the initial iASP if there is one (SETASPGRP)
* Call the initial program on the users initial program parameter
* Go to the initial menu set on the user profile
* Loop back to the initial menu

I'm pretty sure QCMD doesn't do any of the above. What QCMD does is
attempt to receive a *RQS message from the *EXT message queue. If it
succeeds, it (essentially) drops the message into a QCMDEXC and
executes it. If it doesn't find a message (and is running
interactively) it throws up the command entry screen. If you type
something and hit enter, it is written to the *EXT message queue as a
*RQS message and the process is repeated. Generally, when a job is
initiated, the message on the *EXT queue is a call to the initial
program (which would possibly execute the tasks above). All QCMD is is
a loop reading *RQS messages from the *EXT queue.

Chris Pando
chris@xxxxxxxxx