Run up to 32 jobs at once from a dumb terminal!
Brief: Group jobs give you multi-session capabilities even on a nonprogrammable terminal. Using group jobs may improve your productivity and response time by making all of your regularly used applications instantly available. You'll learn two different ways to set up and customize a group job environment.
Ever since the first terminal was attached to a mainframe, many years ago, there has been an unending quest to be able to do more with each terminal. From the System/34 and System/36 with the inquiry program option, to the System/38 with the secondary job, to early PC emulators that supported two or three sessions, to group jobs on the System/38, to dual sessions and split screen terminals, and now to PC Support and advanced emulators offering at least five sessions, we have constantly been seeking ways to increase the amount of clutter glowing back at us from our tube.
Since many of us are now working with PCs attached to the AS/400, we may feel that the five sessions allowed with the Work Station Function (WSF) component of PC Support is quite a number. But that's nothing! You may have read right past the "group jobs" mentioned in the list, but a group job is a way to start up to 16 jobs from one session. When you consider that you can transfer to a secondary job and start another 16 jobs from that session, you can have up to 32 jobs active from a "dumb" terminal. And if you have a PC running WSF, and if you're brave, you can start 16 jobs within each WSF session.
The obvious question is, why would anybody want to start so many jobs at once? What is wrong with simply using the primary and secondary job functions on a terminal, or the more restrained multiple session feature of WSF? How devastating is the performance hit, having so much going on at once? How can you keep track of what's going on, when so much is going on from one source?
We will examine these issues and discover how to create, monitor and terminate group jobs. As you will see, starting a group job is not so different from using the secondary job capability. And you may find that judicious use of group jobs with your own applications will actually improve system performance and help your users make better use of those applications.
Advantages of Group Jobs
In many shops, there is a combination of purchased software packages and in- house software. Packages purchased from different vendors (and frequently, even from the same vendor) are usually incompatible. From your users' and operators' points of view, they would like to be able to go from one application to another, quickly and conveniently. If they only have a single session available (as on a dumb terminal), the best that they can do is start a secondary job and toggle between those jobs. If both jobs are in use and they need to go to another program, they will probably have to end one of the programs, work through a menu system, then start the other program. Most systems are not designed to allow users to call any program from any other program because programs within an application usually pass parameters to each other; the communication between programs is restricted to those that are within the application.
Operating in this manner produces a tremendous load on the system. Although it is true that the overhead of a new job is not required, there is the overhead of loading the program, opening the files, then closing the program so that the operator can return to the original program in use. There are techniques that can be used to improve performance (such as preopening the files in a "shell" program), but it may be difficult to provide all of the performance enhancements.
To some extent, the PC Support WSF function, with its five sessions, is a response to the need for an operator to have multiple programs available at the same time. Most operators are willing to put up with the initial overhead of establishing a multiple session environment, so that once they settle in to work, the sessions are quickly available. Group jobs are an extension of the multiple session capability and are useful for the same reasons.
If you ask your operators to list the programs that they use during their work day, you'll probably find that the list includes more than five programs. For example, a data entry operator may use a data entry display, another display to review table files, a display to run the edit and posting programs, a display of their spooled files, and so on. You can set up a group job program that includes all of those options, and provide a very simple menu that your operators can use to switch between the various programs. Also, your operators will undoubtedly be pleased that their response time is improved.
Another use for group jobs is controlling a network. For example, you may have several AS/400s connected (to other AS/400s or even other systems), and you may be using Display Station Pass Through (DSPT) to sign on to those systems. You can use the different jobs available with group jobs to start the different DSPT sessions. This article will show you techniques to use the Attn key to quickly go from one group job to another.
What is a Group Job?
A group job is simply another job to the system. You establish a group job environment with the Change Group Attributes (CHGGRPA) command. The CHGGRPA command, which must be run in an interactive job, establishes the job in which it is run as the base group job. To start the group job environment, you simply supply a name for the group job in the GRPJOB parameter of the command. You can also supply a qualified message queue name to be used for the group jobs and a 50-character text description that can be used to identify the purpose of the group job.
After you have established the current job as a group job, you use the Transfer to Group Job (TFRGRP-JOB) command to start another job as a group job. The TFRGRPJOB command has three parameters. The GRPJOB parameter is used to name the group job. The name is used to select from a list of group jobs or to return to a previous group job. The Initial Group Program (INLGRPPGM) parameter is used on the first transfer to a new group job; it specifies the program that is to be run in the new group job. The TEXT parameter is used to supply a 50-character text description to describe the group job. (By the way, if you have been lax about supplying text descriptions in the past, you will certainly want to supply them for the group jobs. You will see examples of this later in this article.)
Now that we've learned some of the concepts of group jobs, we'll start using them. You will need to be at a terminal to try these commands. I suggest that you run these commands from the Command Entry display. You can get to that by entering CALL QCMD. To start the group job environment, enter:
CHGGRPA GRPJOB(QCMD) +
TEXT('QCMD-group job 1')
Nothing happens! Nothing that you can see, that is. However, you can now type:
TFRGRPJOB GRPJOB(QPGMR) +
INLGRPPGM(QPGMMENU) +
TEXT('QPGMR-group job 2')
After a brief pause, you will see the Programmer Menu. You are now in another job, even though you did not have to sign on again to start the other job. You are operating under the same user profile, but the second job is as distinct as if it were started from another terminal. Your two group jobs have separate QTEMP libraries, separate job environments (overrides, output queues, switch settings and whatever else you care to change), and they are treated by the system as separate jobs.
Once you have entered these commands, press F10 and use the Work with User Jobs (WRKUSRJOB) command to see that you have two jobs. On the WRKUSRJOB display, you can see your jobs. One of the jobs will have status "Group," the other will have status "Active." You will also see that under the "Function" column there is another indication of the group job. After you have verified that you are using two jobs with one sign on, you can run the TFRGRP-JOB command again:
TFRGRPJOB GRPJOB(*SELECT)
This time, the command uses the *SELECT option. (1a and 1b show the commands used for starting and transferring between group jobs. These figures can be used for easy reference during the rest of the article.) When you enter the TFRGRPJOB command, the Transfer to Group Job display shown in 2 appears at your terminal. The "active group job" is shown at the top of the display; the group job name and text values that you specified with the TFRGRP-
This time, the command uses the *SELECT option. (Figures 1a and 1b show the commands used for starting and transferring between group jobs. These figures can be used for easy reference during the rest of the article.) When you enter the TFRGRPJOB command, the Transfer to Group Job display shown in Figure 2 appears at your terminal. The "active group job" is shown at the top of the display; the group job name and text values that you specified with the TFRGRP-
JOB command in 1a are shown. The middle portion of the display is a subfile display showing the suspended group jobs that you can transfer to. In this case, you can transfer back to the base group job (QCMD) simply by typing a "1" in the "Opt" column and pressing Enter. You are immediately back at the original display, where you entered the two commands shown in 1a.
JOB command in Figure 1a are shown. The middle portion of the display is a subfile display showing the suspended group jobs that you can transfer to. In this case, you can transfer back to the base group job (QCMD) simply by typing a "1" in the "Opt" column and pressing Enter. You are immediately back at the original display, where you entered the two commands shown in Figure 1a.
At this point, what is the status of the group jobs? You can use the WRKUSRJOB command again to see that the status of the two jobs is now switched. Both group jobs are still available to you. Run the TFRGRP-JOB command with *SELECT again and you will see that the Transfer to Group Job display has also switched the two jobs. Selecting the suspended job immediately takes you back into that group job. Notice that when you select the suspended job and press Enter, you are taken to the suspended job much more quickly than when you first used the TFRGRP-
JOB command. That is because the system already knows about the job you are going to and has created the job environment. Transferring back into that job is now a simple swap for the system, rather than the creation of a new job.
Additional Jobs
The novelty has probably faded by now. After all, except for not having to sign on again, this is not so different from using the secondary job feature. Also, it is inconvenient to have to type in the TFRGRPJOB command each time to go to the selection display. However, using the techniques that Ernie Malaga describes in his article in this issue ("At Ease With the Attention Key," page 29), you can add a "hot key" capability that will make group jobs more interesting.
In order to use this technique, enter the CL program shown in 3 and compile it. As you can see, it is simply the same command that you have been typing to switch between group jobs. But we need it in a compiled program so that we can attach it to the Attn key (as Ernie points out, the Attn key handling program cannot be just a command). Once you have compiled the program, you can immediately make use of it with your group jobs.
In order to use this technique, enter the CL program shown in Figure 3 and compile it. As you can see, it is simply the same command that you have been typing to switch between group jobs. But we need it in a compiled program so that we can attach it to the Attn key (as Ernie points out, the Attn key handling program cannot be just a command). Once you have compiled the program, you can immediately make use of it with your group jobs.
To keep things simple, sign off first, then sign back on. Again, you may find it easiest to work from the Command Entry display. Run the command shown in 4; that establishes the short CL program as the Attn key handling program. Then run the commands shown in 1 again to set up the group job environment and to transfer to a group job. Once you are in the group job, press the Attn key and...nothing happens! There is no cause for alarm; the SETATNPGM command that you just ran a minute ago only applies to the job in which it was run. Even if your user profile specifies an attention program it will not be active. When your interactive job becomes a group job, you must use SETATNPGM to activate the Attn key. We are now in another job, so in order to enable the Attn key, simply press F10 and run the SETATNPGM command again. Now try the Attn key. You should be immediately taken to the Transfer to Group Job panel (2). Select the suspended job and press Enter. As soon as you are in that job, press Attn again. As you can see, it's starting to become more convenient.
To keep things simple, sign off first, then sign back on. Again, you may find it easiest to work from the Command Entry display. Run the command shown in Figure 4; that establishes the short CL program as the Attn key handling program. Then run the commands shown in Figure 1 again to set up the group job environment and to transfer to a group job. Once you are in the group job, press the Attn key and...nothing happens! There is no cause for alarm; the SETATNPGM command that you just ran a minute ago only applies to the job in which it was run. Even if your user profile specifies an attention program it will not be active. When your interactive job becomes a group job, you must use SETATNPGM to activate the Attn key. We are now in another job, so in order to enable the Attn key, simply press F10 and run the SETATNPGM command again. Now try the Attn key. You should be immediately taken to the Transfer to Group Job panel (Figure 2). Select the suspended job and press Enter. As soon as you are in that job, press Attn again. As you can see, it's starting to become more convenient.
On the Transfer to Group Job display, you will see that the F6 key is used to "start a new group job." Go to that display if you are not on it, and press F6 now. This prompts you for the TFRGRPJOB command. You can enter another group job name, program and description at this point, then press Enter. For the GRPJOB, you supply a name that you have not used if you want to start a new group job (for example, CMDLINE). If you type in the name of a group job that is already active, then you will be taken to that group job. As always, you should type in some text to describe the new group job. If you enter a GRPJOB name that is already active, then the INLGRPPGM and TEXT values are ignored; the values used are those that were specified the first time you transferred to the group job of that name.
If you try to start a new group job but you have not supplied an INLGRPPGM, you are taken back to the previous display. Message CPF1310 is issued, indicating that the "request to transfer to group job failed," followed by one of 15 reason codes. In this case, where you try to start a new group job but fail to supply a program, the reason code is 40 ("The specified group job is not active and initial group program...was not specified"). You can use the DSPMSGD or WRKMSGD commands to look at message CPF1310 and examine the possible error conditions.
When you do start a new group job, remember that the Attn key is nonfunctional until you run the SETATNPGM command for the new job. Once you run that command, specifying the name of the CL program, you can use the Attn key to go to the Transfer to Group Job display. As you start additional group jobs, you will see the list of jobs growing. You can use the F6 key to start up to 15 group jobs, in addition to the base group job. At this point, you might want to try adding some of your own programs as group jobs. The programs that you add must be programs that do not require parameters.
Programming for Group Jobs
We will now look at a sample of a group job handling program. You will probably not want your operators to use the techniques that were described earlier, of using the CHGGRPA, TFRGRPJOB and SETATN-PGM commands. Those commands are convenient for knowledgeable data processing people to use, but are somewhat daunting for ordinary users. Also, you may want to limit your users, so that they don't have access to the Transfer to Group Job display that we have been using. The problem with this display is that the F6 key is always enabled to start a new group job. Unknowledgable or unscrupulous users may cause problems if they are allowed to use the F6 key. Because the F6 key prompts for the TFRGRPJOB command, you cannot simply revoke the authority to the command in an attempt to secure the F6 key. If you do, users will lose the ability to transfer between their group jobs because they are unable to use the TFRGRPJOB command. Instead of using the Transfer to Group Job display, you can create programs that incorporate the group job commands to provide group job functions for your users.
The programs shown in 5 are used as an example, which consists of a display format that is used as a menu in 5a, the main program shown in 5b, the Attn key handling program in 5c, and several sample programs shown in5d through 5g. You should key in these source members and create the objects in order to run the sample group job program. Be sure that you compile the code in the order presented in the figures. These examples are meant to simulate a typical environment where CL programs are called from fixed format menus. The example is not meant to be particu-larly useful in actual practice.
The programs shown in Figure 5 are used as an example, which consists of a display format that is used as a menu in Figure 5a, the main program shown in Figure 5b, the Attn key handling program in Figure 5c, and several sample programs shown in Figures 5d through 5g. You should key in these source members and create the objects in order to run the sample group job program. Be sure that you compile the code in the order presented in the figures. These examples are meant to simulate a typical environment where CL programs are called from fixed format menus. The example is not meant to be particu-larly useful in actual practice.
When you have created all of the ob-jects, you can start the group job program. Sign off, then sign back on, to create a fresh session. Be sure that the library containing the objects is in your library list. Call the group job program, #CP002CL, from the Command Entry display. That program starts by establishing a base group job (CMDENTRY) and setting the Attn key handling program for the job in which it is run. The RTVGRPA command is used to retrieve the name of the current group job. Indicator 31 is set off; this controls the display of the "Attn Key" literal in the display file. When the SNDRCVF command is run, the menu is displayed. The current group job name is displayed on the menu. The "Attn Key" literal is not displayed, because indicator 31 is off. That means that the display is being shown from the #CP002CL program.
The group job program #CP002CL contains four options. Option 1 is used to call the #CP002CLA program. Because we are within the group job that is using that program, we can simply call the program. The remaining menu options are processed with the TFRGRPJOB command, to create new group jobs and run the associated programs. If you have created the objects and are looking at the menu, you can select any of the four options.
When you select one of the options, the associated program, shown in Figures 5d through 5g, is called. These programs are similar, except for the command that is run. Each program sets the Attn key handling program, executes the command, then loops back
to the command. When you select any of the menu options for the first time, there is a delay while the new group job is started and the command is run for the first time. For example, if you select the WRK-OUTQ option, you see the WRKOUTQ display. From that display, you can press the Attn key to get back to the group jobs menu.
Each of the programs include the loop so that the group job is not ended. You can change one of the programs and see the effect. For example, change the #CP002CLB program (5e) by commenting out the GOTO line. Then recompile that program and restart the group job program. When you select the WRKOUTQ menu option, you can end the program by pressing Enter, F3 or F12; pressing the Attn key does not end the program. If you end the program, you are taken back to the previous group job. When you select the WRKOUTQ option, you again have the overhead required to start a new group job and run the command. It can be tricky to get the processing correct with group jobs; you have to know when a group job is active and when it is not. Using the Command Entry display option, you can use the TFRGRPJOB command with the *SELECT option to review the list of currently active group jobs.
Each of the programs include the loop so that the group job is not ended. You can change one of the programs and see the effect. For example, change the #CP002CLB program (Figure 5e) by commenting out the GOTO line. Then recompile that program and restart the group job program. When you select the WRKOUTQ menu option, you can end the program by pressing Enter, F3 or F12; pressing the Attn key does not end the program. If you end the program, you are taken back to the previous group job. When you select the WRKOUTQ option, you again have the overhead required to start a new group job and run the command. It can be tricky to get the processing correct with group jobs; you have to know when a group job is active and when it is not. Using the Command Entry display option, you can use the TFRGRPJOB command with the *SELECT option to review the list of currently active group jobs.
When you set up a group job menu for your users, you may have to spend some time with them to show them how to use the new functions. They may be conditioned to ending a program to go to another one. With group jobs, it is not necessary to end the program; they can simply use the Attn key from within a display to select the next program to go to. When they are done with the other program, they can use the Attn key to select the program to return to.
Ending a Group Job
You have just seen one way to end a group job: simply let the program that is within a group job end. You can also use the ENDGRPJOB command to end a group job. That command includes three parameters. The first, GRPJOB, is used to specify the group job that is to be ended. You can enter the name of a specific group job or use an asterisk (*) to end the current group job.
The second parameter is Resume Group Job (RSMGRPJOB). This is used to specify which group job is to be resumed when the named group job ends. You can supply the name of another currently active group job or use the default of *PRV to return to the previous group job.
The last parameter, LOG, is used to list or not list the job log. Its usage is the same as the LOG parameter on the SIGNOFF command.
If you end the last group job (the current job that you are in), the effect is the same as the SIGNOFF command. You can also use the SIGN-OFF command to end all of the active group jobs started from a session, no matter how many are currently active. The Work Management Guide (SC41-8078) includes an example of a program that you can use to end group jobs. That program uses the Retrieve Group Attributes (RTV-GRPA) command to process the list of currently active group jobs, ending each in succession.
Other Issues
There are some other things that you will want to consider when designing a group job processor. You may have to increase the count of some of the system values. The system values to check are the initial number of active jobs (QACTJOB), additional number of active jobs (QADLACTJ), initial total number of jobs (QTOTJOB) and additional number of total jobs (QADLTOTJ).
The Work Management Guide indicates that each group job uses about 1K of dedicated main storage in the mach-ine pool. This may be important, but not as much of a factor as in the past. The possible commitment of additional storage to the group job function is offset by the increased efficiency of the group job environment.
This is another of the performance trade-off issues; but if you are in a heavily interactive environment and are not pleased with response time, you may be able to use group jobs advantageously. If your investigation reveals that there are frequent changes to different programs (requiring file allocation, opening and program activation), using group jobs may provide enough of an enhancement that you can defer upgrading the CPU or the amount of memory.
Because each group job is a separate job, you cannot directly communicate between them. That is, one job cannot call a program in another job, access the QTEMP library in another job or use the local data area. However, when you establish a group job environment with the CHGGRPA command, a group data area is established for all of the group jobs started by that session. The group data area is 512 bytes long. The group data area can be changed with the CHGDTAARA command and re-trieved with the RTVDTAARA command. Instead of specifying a data area name, you use the special value *GDA with those commands. The RPG reference manuals do not mention the group data area as a data area that can be retrieved, so it looks like you will have to call a small CL program if you need access to the group data area from within an RPG program. The group data area applies to all group jobs started within the context of one session. For example, if you use a "dumb" terminal, with a primary and secondary job, you can start up to 16 group jobs from each session (16 from the primary and 16 from the secondary). Each of those sessions has its own group data area, inaccessible from the other session.
Related Commands
There are two other commands that are used with group jobs. The first, Retrieve Group Attributes (RTV-GRPA), is used to retrieve values pertaining to group jobs into CL program variables. These include the name of the group job in which the command is run, a list of all active group jobs for the session in which the command is run, the count of the number of active group jobs for the session, the message queue name and library associated with the group jobs, the name and number of the previous group job and a control code to indicate why the active job in a group is in control. Finally, the Check Record Locks (CHKRCDLCK) command can be used to determine if there are any record locks in a job. You can use this command in the Attn key handling program as one of the first commands that is run. When the command is run, escape message CPF321F ("Job holds...record locks") is sent if there are any record locks in the currently active group jobs. If there are any record locks, you should display a message to the operator and return to the active group job. That may help prevent a deadlock situation. Re-
member that transferring to another group job is an entirely separate job, as much as if run at a different terminal. The rules for record locking apply to group jobs.
Read More About Them
The primary reference about group jobs is the Work Management Guide (SC41- 8078, book SYSWKMGT on the CD-ROM). This manual contains an entire chapter on group jobs. You will find several examples of group job processing programs and additional discussion of how to control group jobs. You should certainly review the information in that chapter before creating a programmed group job environment.
At one time, group jobs were seen as the answer to the problem of not being able to go rapidly from one application to another. The popularity of this technique may be diminished now that multiple session PCs are widely available, and especially since some of the PC environments (Windows, OS/2) now provide multi-session capabilities. However, if you have a population of nonprogrammable workstations to support, you may want to investigate group jobs to see if the technique is useful in your installation.
Juggling Jobs
Figure 1A Setting up a simple Group Job environment
Figure 1a: Setting Up a Simple Group Job Environment
CHGGRPA GRPJOB(QCMD) TEXT('QCMD - group job 1')
TFRGRPJOB GRPJOB(QPGMR) INLGRPPGM(QPGMMENU) +
TEXT('QPGMR - group job 2')
Juggling Jobs
Figure 1B Transferring between Group Jobs
Figure 1b: Transferring Between Group Jobs
TFRGRPJOB GRPJOB(*SELECT)
Juggling Jobs
Figure 2 Transfer to Group Job Display
Figure 2: Transfer to Group Job Display
Transfer to Group Job EDTDSP03
System: MC PGMR
Active group job . . . : QPGMR
Text . . . . . . . . . : QPGMR - group job 2
Type option, press Enter.
1=Transfer to group job
-----------Suspended Group Jobs------------
Opt Group Job Text
- QCMD QCMD - group job 1
Bottom
F3=Exit F5=Refresh F6=Start a new group job F12=Cancel
Juggling Jobs
Figure 3 Group Job ATTN key program
#CP001CL: +
PGM
TFRGRPJOB GRPJOB(*SELECT)
ENDPGM
Juggling Jobs
Figure 4 Setting the ATTN key handling program
Figure 4: Setting the Attn Key Handling Program
SETATNPGM PGM(#CP001CL)
Juggling Jobs
Figure 5A Display file #CP002DF
A DSPSIZ(24 80 *DS3)
A PRINT
A CF03(03 'Exit')
A CF12(12 'Cancel')
A INDTXT(31 'Attn key processor')
*
A R GRPJOB
A BLINK
A 1 31'Group Job Selections'
A DSPATR(HI)
A 31 1 73'Attn Key'
A DSPATR(HI)
A 2 26'Current Group Job:'
A CURGRPJOB 10 O 2 46TEXT('Current group job')
A DSPATR(HI)
A 4 2'Select one of the following:'
A COLOR(BLU)
A 6 7'1. Command entry display'
A 7 7'2. WRKOUTQ display'
A 8 7'3. WRKJOBQ display'
A 9 7'4. WRKSBS display'
A 18 2'Your option:'
A 19 2'===>'
A OPTION 1Y 0I 19 7TEXT('Option number')
A VALUES(1 2 3 4)
A 23 2'F3=Exit F12=Cancel'
A COLOR(BLU)
Juggling Jobs
Figure 5B CL program #CP002CL
#CP002CL: +
PGM
DCLF FILE(#CP002DF)
CHGGRPA GRPJOB(CMDENTRY) TEXT('Command entry display')
SETATNPGM PGM(#CP003CL)
RTVGRPA GRPJOB(&CURGRPJOB)
LOOP: +
CHGVAR VAR(&IN31) VALUE('0')
SNDRCVF
IF COND(&IN03 *OR &IN12) THEN(RETURN)
IF COND(&OPTION *EQ 1) THEN(CALL PGM(#CP002CLA))
IF COND(&OPTION *EQ 2) THEN(TFRGRPJOB GRPJOB(WRKOUTQ) +
INLGRPPGM(#CP002CLB) TEXT('WRKOUTQ group job'))
IF COND(&OPTION *EQ 3) THEN(TFRGRPJOB GRPJOB(WRKJOBQ) +
INLGRPPGM(#CP002CLC) TEXT('WRKJOBQ group job'))
IF COND(&OPTION *EQ 4) THEN(TFRGRPJOB GRPJOB(WRKSBS) +
INLGRPPGM(#CP002CLD) TEXT('WRKSBS group job'))
GOTO CMDLBL(LOOP)
ENDPGM
Juggling Jobs
Figure 5C CL program #CP003CL
#CP003CL: +
PGM
DCLF FILE(#CP002DF)
RTVGRPA GRPJOB(&CURGRPJOB)
CHGVAR VAR(&IN31) VALUE('1')
SNDRCVF
IF COND(&IN03 *OR &IN12) THEN(RETURN)
IF COND(&OPTION *EQ 1) THEN(DO)
IF COND(&CURGRPJOB *EQ 'CMDENTRY') THEN(RETURN)
ELSE CMD(TFRGRPJOB GRPJOB(CMDENTRY) INLGRPPGM(#CP002CLA) +
TEXT('Command Entry Display'))
ENDDO
IF COND(&OPTION *EQ 2) THEN(DO)
IF COND(&CURGRPJOB *EQ 'WRKOUTQ') THEN(RETURN)
ELSE CMD(TFRGRPJOB GRPJOB(WRKOUTQ) INLGRPPGM(#CP002CLB) +
TEXT('WRKOUTQ group job'))
ENDDO
IF COND(&OPTION *EQ 3) THEN(DO)
IF COND(&CURGRPJOB *EQ 'WRKJOBQ') THEN(RETURN)
ELSE CMD(TFRGRPJOB GRPJOB(WRKJOBQ) INLGRPPGM(#CP002CLC) +
TEXT('WRKJOBQ group job'))
ENDDO
IF COND(&OPTION *EQ 4) THEN(DO)
IF COND(&CURGRPJOB *EQ 'WRKSBS') THEN(RETURN)
ELSE CMD(TFRGRPJOB GRPJOB(WRKSBS) INLGRPPGM(#CP002CLD) +
TEXT('WRKSBS group job'))
ENDDO
ENDPGM
Juggling Jobs
Figure 5D CL program #CP002CLA
#CP002CLA: +
PGM
SETATNPGM PGM(#CP003CL)
A: +
CALL PGM(QCMD)
GOTO CMDLBL(A)
ENDPGM
Juggling Jobs
Figure 5E CL program #CP002CLB
#CP002CLB: +
PGM
SETATNPGM PGM(#CP003CL)
A: +
WRKOUTQ
GOTO CMDLBL(A)
ENDPGM
Juggling Jobs
Figure 5F CL program #CP002CLC
#CP002CLC: +
PGM
SETATNPGM PGM(#CP003CL)
A: +
WRKJOBQ
GOTO CMDLBL(A)
ENDPGM
Juggling Jobs
Figure 5G CL program #CP002CLD
#CP002CLD: +
PGM
SETATNPGM PGM(#CP003CL)
A: +
WRKSBS
GOTO CMDLBL(A)
ENDPGM
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online