Tip for launching a Windows app from the AS/400
provided by Ron Turull and published in the August issue of Inside Version 4.
Remember when you could launch a DOS program from an AS/400. You can still do it if you're running DOS-based PC Support. With IBM's final acceptance of Windows, however, most of us have moved far beyond those days and, for better or for worse (I'm never quite sure which one it is), are firmly entrenched in Windows-land. So we may now find ourselves with a need to launch Windows programs from an AS/400.
For example, on a customer record screen on the AS/400, you may want to provide a function key to allow the user to write a letter to the customer. Since PC word processors are far superior to anything found on the AS/400, you would probably want to launch Word or some other PC word processor using the following steps:
- Copy the customer's name and address to a DLS (document library system) document,
- Launch Word for Windows, automatically opening a form template, and
- Automatically running a Word macro to open the DLO document and copy the customer information into the proper places on the form.
Don't try it yet!
Before you race to your nearest PC to try out the Run Remote Command command, be aware that you have to launch a daemon program on the PC first. The name of the program is CWBRXD.EXE and, once executed, it sits in the background and waits for incoming commands. When it gets one, it executes it. On a side note, ironically, the CWBRXD.EXE program is a DOS program (don't ask me why).
Also, you have to configure Client Access to accept incoming commands. To do this, press the Start button and select Programs. Then, open the Client Access 400 folder and select Client Access Properties. On the properties page select the Remote Command tab. Here you can add which users can submit commands to the PC.
To add a user, press the Add button. To allow all users to submit commands to the PC, specify an asterisk (*) for both the System and User ID fields (leave the password fields blank). Otherwise, add only the users who you want to submit commands to the PC.
If you check the "Automatically start incoming remote command" checkbox, the CWBRXD.EXE daemon program will be started automatically when you open a connection to an AS/400. Alternatively, you can stick a shortcut to the CWBRXD.EXE program in your Startup folder.
2 protocols supported by the RUNRMTCMD command
The RUNRMTCMD command supports two communications protocols, SNA and TCP/IP. You must to know which one the PC you'll be submitting commands to is running. To determine which one a PC is running, open the Client Access 400 folder again (as described above) and select AS400 Connections.
On the resulting screen, in the right-hand panel, right-click the connection configuration the PC is using. Select Properties on the pop-up menu. The Connection type field on the AS/400 Connection tab will show you the protocol the PC is using. Make a note of it because you will need it on the RUNRMTCMD command.
How to use the Run Remote Command command
Now that you have your PC configured, sign on to an AS/400 (you don't necessarily need to use the PC running the CWBRXD.EXE daemon program - in fact, you can use a dumb terminal). On a command line, type in "RUNRMTCMD" and prompt it with F4.
On the Command parameter, enter the PC command you want to run. For example, on my PC, to launch Microsoft Word, I use the command
On the other hand, if the PC is running TCP/IP, specify the PC's IP address for the "name or address" field. Alternatively, if the PC has an entry in the AS/400 host name table, you can specify its host name (see the CFTTCP command for more information on the host name table). Either way, you'll need to specify *IP for the "type" field.
For the Remote user ID parameter and the Remote password parameter, you'll need to specify the user ID and password configured on the PC. If you configured the PC to accept commands from any user, then leave the defaults for these parameters, *NONE.
Here is an example of the RUNRMTCMD command:
The IP address problem
Don't get too excited yet! One of the common uses of the RUNRMTCMD command is to launch a Windows application from an AS/400 program on the PC the user is using. The last clause in the previous sentence is the operative one. When using TCP/IP, how do you determine the IP address of the PC the user is using?
The answer is there really is no way of doing so, at least not that I have found. There is a workaround, but it takes commitment, diligence, and time. The first thing you need to do it get your users on a telnet client that supports device naming. Client Access's PC5250 works fine.
The trick is this: Give each user's telnet configuration a unique device name. When they start a session and sign-on to the AS/400, their interactive job will have the same name as the device name. Part two: Add all the device names that you assigned to the AS/400's host name table. Use the ADDTCPHTE command to add the names. On the Internet address parameter, specify the IP address of the PC and on the Host names parameter, specify the device name. Warning: Doing this creates a conflict that prohibits the use of DHCP.
Once this is done for each user, you can use the RTVJOBA command to retrieve the name of the job. If you properly configured the host table, the job name will be the same as the host name. Then you can specify the job name for the Remote location parameter on the RUNRMTCMD command.
No addressing problem for SNA
SNA doesn't suffer from the "addressing" problem because you can easy determine the remote location name from the device description (which, again, has the same name as the job name). Just use the Retrieve Device Description API (QDCRDEVD) and format DEVD0200 to get the remote location name and, then, plug it into the Remote location parameter.
RUNRMTCMD does DOS programs, too
You can also launch DOS commands and programs using the RUNRMTCMD command. However, if they have any output, it is written to an AS/400 spool file. Therefore, interactive DOS programs aren't an option. For example, you can't launch your old DOS version of Word - not that you would want to anyway.
This was first published in September 1999