How to Display the Screen of Another Interactive Job

APIs by Example.

In this installment of APIs by Example , I’ll cover two challenging programming requirements. The first relates to running a program to perform a process in another job. The second deals with communicating the 5250 data stream directly to a display device, without the intervention of a display file or panel group. For the latter, the Dynamic Screen Manager (DSM) APIs provide a robust and straightforward method for handling this requirement. An earlier approach involved manually writing 5250 data streams to a display file record format that included the DDS keyword USRDFN. The DSM APIs, however, clearly simplify that process and make display device communication much more transparent.

The reason for engaging in this interesting endeavor emerged from a request from my company’s service desk. The service desk personnel ask for the ability to instantly peek at a remote interactive job’s screen in order to support and guide users in need of assistance. Having a quick look over the user’s shoulder is far more efficient and less error prone than having users throughout Europe spell out error messages and menu options in different languages over the phone. Looking up the interactive job via the user profile name also proved to be much speedier than trying to identify the remote terminal in question on the network. With this assignment in mind, I started investigating the options at hand to create a Display Job Screen (DSPJOBSCN) command. (For instructions on how to create DSPJOBSCN, see “How to Compile,” below.)

The QWCJBITP API

Running a program in another job used to require ingenious but complex and slightly obscure methods. One approach used a message queue break-handling program in the target job; another involved the collaboration between the Start Service Job (STRSRVJOB) command and the exit program facility of the Trace Job (TRCJOB) program. Using the first method, you had to either patch a user program to system state or enlist the cooperation of the user running the target job. You could perform the latter approach without the target job user knowing that you were running a program behind the scenes. With release 5.4, IBM deactivated the TRCJOB command’s exit program (EXITPGM) parameter. And in release 6.1, a new object integrity enforcement scheme removed the option to patch an object to system state.

Download the save file containing the source code.

Read the entire article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s