But, when an interactive job starts, QCMD simply starts the menuing system QUICMENU, and that does the command processing, not QCMD See the program stack below, I called QCMD from the menu command line. See where it appears on the stack? QUICMD is the command processor for the menuing system. It does not drop back down to the routing program QCMD.
Type Program Statement
QCMD QSYS /0519
QUICMENU QSYS /00C1
1 QUIMNDRV QSYS /0607
2 QUIMGFLW QSYS /04D7
3 QUICMD QSYS /056F
4 QCMD QSYS /01C8
The point about routing entries was that while you can replace the program for the interactive routing entry with your own command processor, as soon as you call something that presents a command line, you are back to either that third party command processor restrictions, or IBM's depending on how that command line was produced.
Here's a possibility, you could create a menuing program and set it to be your routing program, and it could provide a command processor with your own filtering routines, but every job entering a subsystem uses those routing entries. You might be restricting the capability of your administrators by doing that. Maybe better to make your command processor an initial program for specific users, and the initial menu = *signoff, so if they somehow end your command processor, they get signed off. Then you could prevent any programs or commands that present an IBM command line, or just limit capabilities.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----Chris Pando <chris.pando@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Chris Pando <chris.pando@xxxxxxxxx>
Date: 08/31/2016 02:32AM
Subject: 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
midrange.com
