F9=Retrieve…
I'm creating a DSPF and want to put in some common AS/400 command functions, and one of them would be to hit F9 to retrieve the last command entered. How would I go about doing this? I'm using a mock command line input field and would be sending any commands via QCMDEXC. Any ideas on the F9 feature?
Software/Hardware used:
Software/Hardware used:
ASKED:
June 11, 2008 12:48 PM
UPDATED:
November 17, 2011 12:12 PM
Answer Wiki:
Hi,
I remember doing this many years ago. I seem to recall using the RCVMSG command to retrieve the last messages that were written to the joblog to retrieve the commands. Bear in mind that this may not work if you have no logging for your job.
Otherwise you could write your commands that you execute via QCMDEXC to a file, data queue, user space, etc and retrieve them yourself in your program.
Regards,
Martin Gilbert.
=============================================================
In order to <F9=Retrieve> commands, you must either save each command that comes into your program in an array or file, or you must have the user's job running at a LOG() level that supports automatic saving of commands.
If you store them yourself, then you retrieve them in whatever way you want.
If you have the system store them, then you use RCVMSG or the QMHRCVPM API to receive *REQUEST messages from the job's external message queue. If the user's job has an inappropriate logging level, then the command was never stored for you to retrieve. You'll have to decide if you want to retrieve job attributes when your program starts, change the LOG() if necessary, and reset it back to the original before your program ends.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
All you need to do is call QUSCMDLN (no parameters) from your program. This will bring up the command line window – the same one you get from SEU when you press F21.
It already has a full F9=Retrieve function, built in.
However, you would have no control over the commands that could be entered. What the user can do from that command line is limited only by their security level and user type.
If you use the RCVMSG method, you want to receive message of type *RQS.
Regards,
Sloopy
If you’re using the display file in RPG then just create an array in which to save the commands.
If you’re going to allow users to enter parameters in the commands, you might be better served using QCAPCMD rather than QCMDEXC.
All you need to do is call QUSCMDLN (no parameters) from your program. IMHO
Berita Aladiw | Belajar Aladiw
I agree with Splat. With the qcapcmd api, if the user changes any of the parms, qcapcmd can ‘catch’ the changes.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/qcapcmd.htm
If you really want to punish yourself, you could use the User Interface Manager (UIM) apis. Then your F9=Retrieve is built in. Set aside a few months though. <g>
John B
The dead easiest thing to do would be what Sloopy and others suggested, use the quscmdln.
//—————————————————————
// Prototyped call to get Command Line
//—————————————————————
d #CmdLine pr extpgm(‘QUSCMDLN’)
. . . . .
if dvInKey = F10;
#CmdLine();
endif;
Note that when using QUSCMDLN (or any similar system function that implements <F9=Retrieve> for commands), you still need to have the job’s LOG() level set high enough to log commands. If the job doesn’t log your commands, you can’t retrieve them through system functions.
If you display your own command line, you can simply store each one in an array with no regard for the job’s LOG() level.
Tom
It’s interesting that this question has been running nearly three and a half years now.
OK. I would write a utility program to do this, using a window similar to that provided by QUSCMDLN. But, I would use QCAPCMD to run the command, and store the returned command string if there were no errors, or the original command string if there were (along with an error flag). Storage would be in a local (QTEMP) file with a variable-length field to hold the command string.
If you wanted to restrict by command name or other values, create an exclusion file (non-local, of course). Parse the command string for forbidden keywords, library names, command names (the command name is of course the first word in the string unless they write SBMJOB or similar)….
It does sound useful. I think I WILL write it.