[Access to Wang masthead]

Easy Routines

Options for linking subroutines
From "VS Workshop",  Access to Wang, June 1991
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

The ease of using subroutines in VS programming languages has always been one of its strongest benefits as a programming environment. The ability to write subroutines in any language and call them from any other language was unique at the time the VS was introduced, and programmers have counted on subroutines to ease program development from the start.

In the early years, the VS operating system only allowed two forms of linking: static linking, where code sections were combined into a single object module; and dynamic linking, which used the LINK supervisor call (SVC) to link modules during execution. Since SVCs are only available to assembly language programs, the LINK subroutine (a USERSUB) was provided to allow access to the SVC's capabilities from high-level programming languages. This subroutine was distributed informally by Wang until becoming part of the VSSUBS library distributed with recent operating systems. Linkage choices grew even larger with the release of 7.10 of the operating system, when the Format 1 object was introduced. Format 1 object files add the ability to use subroutines that have been combined into a single module referred to as a Subroutine Library. Subroutine Libraries can be linked directly into programs or called dynamically during program execution.

The approach you take to the task of linking subroutines is probably like mine: I use what has worked in the past. When the old approach didn't work recently I examined the choices carefully and found some surprises.

Terms

Let's define a few terms. A static link is one in which some or all of the subroutine's object code becomes part of the final object file. A dynamic link contains references to the subroutine file itself and opens it at run-time. Shared Subroutine Libraries (SSLs) and Static Subroutine Libraries are files that contain any number of individual subroutines; the only difference between them is the way that they are used. An alias is a name used to identify a Shared Subroutine Library. A permanently open file is a program recognized by the operating system as always open and in memory - typically through the FASTLINK utility.

Besides its use within the Editor, Wang's LINKER utility is used to create Subroutine Libraries from individual subroutines. A Subroutine Library is actually a single file containing subroutines and addressing information to use them. The process of creating a Subroutine Library is described in detail in the Program Development Tools Reference; use of the SSL utility is covered in the VS System Administrators Reference. The process of creating a Subroutine Library is straightforward: select the files to be included, assign an alias, and specify the output file name.

Once a Subroutine Library is created it can be linked directly to your programs or called dynamically through the SSL (Shared Subroutine Library) facility. SSL tells the operating system where a Subroutine Library is located by creating a list of them and their associated aliases. Once you have identified the Subroutine Library through SSL you can specify its alias in the LINKER for access to all of the subroutines contained within.

Using permanently open files

One way of dramatically increasing the performance of programs is to place them in memory with a status of permanently open. On the VS, this is usually accomplished through use of the Wang FASTLINK utility. FASTLINK places the file's control block information in memory, saving the large amount of overhead required to open the file normally. Many users have discovered the benefit of placing high-usage, short-duration programs like COPY and SORT in this list. Be careful about what you put in this list, though, since it is robbing you of some portion of system memory.

The FASTLINK approach is particularly effective for dynamic linking approaches, since the called subroutine is open and ready to run. These improvements are shown in a recent comparison I ran, where a dynamically linked routine placed in the FASTLINK list ran faster with substantially reduced paging activity.

Besides FASTLINK, you can also set and remove permanent open status in programs through a call to the LINK subroutine. The SPECIAL argument allows control of the FASTLINK list, setting or removing permanently open status. For example, the following procedure would put the COPY utility in this state:


PROCEDURE SETFAST - Sets COPY in FASTLINK
DECLARE &CCODE, &RCODE INTEGER
RUN     LINK IN VSSUBS ON SYSTEM
USING "COPY    ", "S", "        ", "      ",
      "O",                [ Set open status ]
      &CCODE, &RCODE
RETURN

A similar procedure could be used to remove COPY from this list; simply substitute an C in the SPECIAL argument.

Testing link options

In one recent instance I faced the problem of linking a very large subroutine into a small program. The subroutine was provided by a vendor and could not be re-programmed to reduce its size, and performance of the resulting program was adversely affected due to the amount of resources required to load and execute the program. I decided to test several linkage approaches and select the method best suited to the task.

To perform this test several versions of the source file were prepared. A Subroutine Library was created that contained most of the entries in the VSSUBS library plus the large vendor subroutine I needed to link into this program; this Subroutine Library was used for tests of the Static Subroutine Library and Shared Subroutine Library approaches. Object files were created using each approach and repeated runs were made using each. The run-time statistics were captured by the SMF facility (a VSAID), presented by Wang's INQUIRY utility, and summarized in a PC spreadsheet. Figure 1 shows the results of this experiment. The Static option (option 1) represents the traditional program linkage approach, while the Dynamic option (option 2) uses the LINK subroutine. The Static Subroutine library (option 3) allowed a single subroutine file to satisfy all requests within the program and improved performance slightly. Placing the large subroutine in the FASTLINK list and linking dynamically (option 4) improved performance and decreased the amount of paging activity substantially. Finally, the Shared Subroutine Library approach (option 5) delivered the smallest object file but suffered the worst run-time and CPU performance and also increased the amount of system paging.

The verdict

So what are the advantages of the various types of subroutine linking? It depends on your system's performance dynamics and your performance goals. Each linking approach has its own advantages. Some of the issues to consider include:

In this example I compromised and used the dynamic approach (option 2), delivering reasonable running time with some penalties in CPU and paging activity. If the large subroutine was called repeatedly from the program I would have set the subroutine in permanent open status, as shown in option 4.

If you have the opportunity, repeat this experiment with your own applications and let me know the results. If there is interest, I will share this information in a future column.

References

Figure 1: Benchmark - Comparison of Linker Results

Link Type Object
Size 		Elapsed
Time 		CPU
Seconds 		System
Page In 		User
Page In
1. Static 633 4.20 69.33 30 22
2. Dynamic (LINK) 57 3.70 74.43 36 33
3. Static Subroutine Library 728 4.10 70.40 37 25
4. Dynamic with program in FASTLINK list 57 3.20 71.50 6 18
5. Shared Subroutine Library 43 4.70 75.80 49 24

  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Copyright © 1991 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified