|
|||||||
|
|
![]() |
|
|
Back to Basics: The Copy Screen Feature by Kevin Vandever Have you ever tried to research a software problem remotely? The user attempts to explain the options and menus he negotiated, while you frantically write down each word, asking questions and interjecting assumptions as you go. How about providing remote training or a demo over the phone? It just doesn't cut it, does it? Well there's a better way to accomplish these tasks, and it doesn't involve purchasing an airline ticket. Come on in and check out how the copy screen feature can help. The Start Copy Screen Command The copy screen feature allows a user to have his 5250 display data copied to another display station. The copy feature can go either way--meaning that the person who runs the command can choose to either copy the data stream to another workstation or receive a copy of someone else's data stream. The 5250 data stream can also, or additionally, be copied to a database file. This comes in handy when the receiving device is not available or you want to analyze the data at a later time. To activate this feature, run the Start Copy Screen (STRCPYSCN) command and press the F4 key. There's not much to running this command. You must enter a source and an output device. The source device is the device (screen) that will be copied, and the output device is the device that will receive that copied screen. The device is distinguished by the device ID, which can be found using the Display Job (DSPJOB) command, and referring to the job name on the upper right portion of the screen. If the job that is initiating the copy screen command is going to be either the source or the output for the copied data, you can use the *REQUESTOR keyword in the one of the two parameters, depending on the role your job will play. You cannot use *REQUESTOR for both source and output devices. If you don't want to copy the data stream to another device, but instead want to copy it to a database file, you can use *NONE as the value in the output parameter. The third parameter allows you to select the job queue that will be used to submit the command. The remaining parameters are there, in case you would like to copy the screen to a database file. This latter feature can be done even if you also copy the screen to another device. Enter a file and library, the member you are going to use, and whether you plan to add or replace the records. The file will be created for you, if it doesn't already exist. In fact, you should let the command create the file for you the first time, so that the data description is correct. When you successfully run the command, an inquiry message will be break on at the source device:
Type reply (if required), press Enter.
From . . . : KVANDEVER 09/23/03 18:07:59
Cause . . . . . : Start copy screen has been requested
with output to QPADEV000S. Reply C to prevent copy screen
or G to allow it. (C G)
Reply . . .
This message allows the user at the source device to either prevent or allow the copy, and, in most cases, it stops users from having their screens copied without their permission. Some Rules to Follow You're almost ready to rock and roll, but there are a few things to take into consideration before you can copy one device to another. Both display devices used in the command must be defined on the system. The displays must be of the same type. If, for example, one device is monochrome, the other must also be monochrome. This goes for character positions, too. Each device used in the command must be configured to display the same number of characters both vertically and horizontally. If you intend to use the job that is running the Start Copy Screen command as the source device, the output device must be at a sign-on screen; otherwise, you will get an error stating that the output device is not available. The same is true even if the job running the command is neither the source nor the output device. The job running the command does not necessarily have to be the source or the output device. It can be the instigator for two other devices. Just remember that anytime the output device is not the device running the command, that output device should be at the sign-on screen. The output device will be one screen behind the source device. This is not a huge issue, in my experience, but depending on what's going on, it can be a little confusing. The last thing to note is that the source and output devices must be on the same machine. If you are on a different machine than your users, you can pass through to their machine and run the command as you would locally. Why Would I Use This? In the opening paragraph I hinted at some potential reasons to use this command, and you may have already come up with your own. It comes in very handy when the software support or help desk staff is not located near its users. In that case, a support person can start a copy screen session for a user. All the user has to do is to answer the inquiry message with a G and then perform his job as normal until the software issue arises. If the user has to go through many steps to get to the issue, or the support staff doesn't have the time to watch along, the data can be copied to a database file and analyzed at a later time. I recommend doing this even if you don't plan to use the file. It's always good to have an alternative, in case something happens while watching the copied screen. Another use for this feature is for training or doing demonstrations. Imagine training the users while in the comfort of your own office or cubicle? All you need is a speakerphone and the Start Copy Screen command. You can talk to the remote customers on the phone as you navigate through the screens. The users will see everything you do. In this case the user's screen would be the output device, and copying to a file is probably not necessary. The last potential use is along the same lines as my first example but with a different spin. Say you wanted to audit someone's screen navigation for a long period of time, or the problem that you are trying to troubleshoot is so difficult that it's hard for the user to duplicate it. You could simply copy that user's screen to a database file, and not to another device, and let that user work all day. You then have a complete log of the user's navigation to use for a variety of reasons. It's Okay to Copy You should now have a pretty good idea of how to use the copy screen command. If you have remote users or customers that you have to support and train, the copy screen command might just become a necessary tool in your shop.
|
Editors
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |