Burns, Bryan wrote:
I need to give a former programmer the ability to CALL a program and I don't know which program and I don't want to give him command line access. This will be temporary until he can specify the programs, at which time I'll just create menu options for him.
Bryan:
I had a bunch of thoughts about this when I first read it, and many of
them have been mentioned in previous responses. My first thought was to
use QCMDCHK to handle the prompting. The QCAPCMD API would be better for
a long-term solution, but QCMDCHK is easier for illustration and quick use.
I put an example program up at:
http://code.midrange.com/90cf1ee208.html
The ?CALL is prompted with QCMDCHK. Once the program, library and
parameters are entered, the resulting formatted command string is
returned to the program. The formatting makes the string predictable.
In the example, the PGM() parameter and its 'library/program' value is
important. We know where the library name begins, and we know the
qualified name won't be more than 21 total characters.
Most of what is done is finding where a '/' and an ending ')' might be.
Those characters let us determine where (and if) a library spec was
entered as well as the program.
Once those are both available, any tests you want to run can be done.
The example does _not_ do extensive tests. For example, it doesn't check
the SYSTEM program in library QSHELL.
That's a possible way to get around the most common restrictions. It is
_not_ the only way, and I'm pretty sure I wouldn't list every one if I
tried to list them all off the top of my head.
You could create a table of restricted programs and libraries. Add rows
to it whenever a new possibility needs attention.
The example is also short on error handling. But most errors shouldn't
be real problems; they mostly could be handled by setting a path back to
the start of this program.
Overall, I'm not clear why you want to give an ability to call
practically any program but don't want to give a command line. It seems
little different from giving command line access to a 'limited
capability' user... except *LMTCPB doesn't allow access to the CALL
command by default, and you probably don't want to change CALL to make
it available.
That means you'll have to set up access even to the example program for
QCMDCHK.
Most likely, you'll do that through an initial program that simply loops
around a CALL to the example program. Or you could take the example and
code a loop into it; then make it the initial program.
Anyway, maybe the example will give you enough of a start. It should
"work" as it is.
If this is a serious effort, consider adding some kind of logging. One
simple possibility is to send the command string to a logging message
queue after it comes back from QCMDCHK. Set the *msgq authorities to
allow adding messages but not deleting.
It was interesting thinking about this. Ask questions if you have any.
Tom Liotta
As an Amazon Associate we earn from qualifying purchases.