Sofar,we’ve discussed how to execute programs stored in a library. These programs were not always located in this library. At one time they could have been on punched cards in one of the programming languages, such as COBOL or RPG II.
These programs are compiled or assembled using a language translator, which converts the program instructions into a form understandable to the computer (an object module). Each language translator has a JPROC call you can use to generate the job control statement needed to direct the operation of the language translator; in other words, you get an object module from source input. The JPROC call for each language translator can be found in the appropriate assembler, COBOL, FORTRAN, and RPG II publications.
In this guide, we’ll explain the JPROC call for the linkage editor. But, before we do, a word or two about the linkage editor.
5-16 70044623.000
Doing It the Easy Way
-with Procedure Calls
The linkage editor converts an object module into an executable load module. Only load modules can be executed, and the only method of converting object modules to load modules is by using the linkage editor. The function of the linkage editor is fully covered in the System Service Programs (SSP) Operating Guide, UP-8841.
The format of the linkage editor JPROC call is:
JLINK
rscRl= fvo( ser foil rsTD= [YES11 rALTL0D= (vol ser no Label)
1NO
j U
(RES,label)Doing It the Easy Way
-with Procedure Calls
There are two choices in the operation field: LINK and LINKG. By specifying LINK, you execute the linkage editor. By specifying LINKG, you execute the linkage editor andthe load module you just created (without using an EXEC job control statement).
As youcansee, all the parameters are optional. But this JPROC call has default values, which generate the job and linkage editor control statements sufficient to accomplish a link edit, and assumes the following:
Allthe object code you specifically want included in the load module is in the job’s
$Y$RUN file.
• Anyobject code that may have to be automatically included in the load module (such as error processing routines) is in $Y$OBJ.
• The load module produced is given the name LNKLOD, and it’s stored in the job’s
$Y$RUN file.
You can alter these default conditions using the optional parameters. There are also parameters that allow you to choose special options (such as a specific printer, a certain scratch work file, etc.).
Let’s see what job and linkage editor control statements are generated when you omit all the parameters. We’ll use both the LINK and the LINKG operations. For these examples, assume that the program was just compiled (or assembled) by a language translator,andthe object code was placed in the job’s $Y$RUN file. This occurred in the last job step, but it is still the same job. The job’s $Y$RUN file is only a temporary file, lasting for the length of the job. So, if you placed the object code in the job’s
$Y$RUN file in one job and tried to locate it in another job, you wouldn’t find it.
/* (this is the end of the language translator job step) /1 LINK
1/ FIN
Here’s what job control statements are generated:
/* (this is the end of the language translator job step) 1 /1 DVC 20 II LFD PRNTR
Doing It the Easy Way-with Procedure Calls
1. This is the device assignment set that’s generated for the printer. Notice that we’ve used multistatement coding, showing the DVC and LFD job control statements on the same line.
2. The linkage editor always uses one scratch work area. The JPROC call assigns it to the SYSRES device,andmakes it ajob step temporary file.
(The file identifier begins with$.)This work area is scratched at the end of the job step.
3. This calls the linkage editor from $Y$LODandinitiates its execution.
4. The generated load module must be assigned a name. The default is
LNKLOD. This is on the LOADM linkage editor control statement, which is treated as data by job control, thus the1$and/*job control statements.
5. As always, this indicates the end of the job.
This example is fine if you don’t want to execute the program, since default conditions assign the load module to the job’s $Y$RUN file, which is only a temporary file. This load module is not available to another job (but it is to another job step inthejob).
This application is useful if you only want to see the output of the linkage editor; but it isn’t much help if you want to execute. This does not mean that youcannever access a load module in ajob other than the one in which it was link edited. You can, but you have to assign it to a library other than the job’s $Y$RUN file. You’ll see how later on, when we discuss the optional parameters. But first, let’s see how to execute the load module that was placed, by default, in the job’s $Y$RUN file.
There are two ways you can execute a load module placed in the job’s $Y$RUN file:
first, you can execute it in a subsequentjob step after link editing, using the default LNKLOD load module name on the EXEC job control statement; or, second, you can use the LINKG operation, which automatically executes the load module.
Here’s method 1 (LINK):
/* (end of Language translator job step) II LINK
1/ EXEC LNKLOD,$Y$RUN I&
II FIN
70044623.000 5-19
Doing It the Easy Way-
with
Procedure CallsThe job control statements generated are:
/* (end of language translator job step) II DVC 20 /1 LFD PRNTR
/1 DVC RES
II EXT.ST,C,1,BLK,(256,10) If LBL $SCR1 II LFD $SCR1 If EXEC LNKEDT
The load module name on the LOADM linkage editor control statement and the program name on the EXEC job control statement is the same: LNKLOD. Since we know the linkage editor always assigns this as the default load module name, we use it as the program name. Also note that $Y$RUN is the second parameter on the EXEC job control statement. Remember, in “Specifring Qualifiers for File Identifiers”
in Section 4, we said this parameter indicates the name of the library containing the load module. If omitted, $Y$LOD is searched and then the job’s $Y$RUN file. Since the job’s $Y$RUN file is searched eventually, why specify it? Time. We know, it’s in the job’s $Y$RUN file, so why search $Y$LOD needlessly? Go directly to the job’s
$Y$RUN file.
Now, here’s method 2 (LINKG):
/* (end of language translator job step) II LINKG
I&
I/FIN
And here are the generated job control statements:
/* (end of Language translator job step-) 1.1 ..T[QN. GQ
1/ DVC 20 1/ LFD PRNTR II DVC RES
If EXT ST,C,1,BLK,(256,10) II LBL $SCR1 If LFD $SCR1 II EXEC LNKEDT
Doing It the Easy Way-with Procedure Calls
The only difference between this LINKG operation and the LINK operation is the generated OPTION job control statement. The GOmeans the load module should be automatically executed when linkage editing is completed. You don’t need an EXEC job control statement.
The LINKG operation generates a load module name of LNKLOD and is loaded, by default, in the job’s $Y$RUN file. This means it is not available after the job is completed. The LINKG operation is useful when you’re testing programs or running programs that are infrequently used.
So far, we’ve covered only the basic use of the linkage editor JPROC call. Now, let’s add some optional parameters and make it do exactly what we want.