× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.