IBM Mainframe Forum

I got the idea to experiment with program fetch performance. To do this I defined 3 environments.

• Link List
• A PDS that is a copy of SYS1.LINKLIB
• A PDSE that is a copy of SYS1.LINKLIB

For my test I loaded the largest module in SYS1.LINKLIB; in the system I used for my test this turned out to be AOPICDMN. The test program performed the load 100 times; the reported time is the elapsed time to perform the LOAD/DELETE macro pair divided by 100. I got these results:

• LINKLST - 0.34
• PDS - 0.29
• PDSE - 0.03

The difference between fetch from LINKLIST and the identical module in a PDS is a surprise; I would have expected the LINKLIST fetch to be faster since there should not be a BLDL. On the other hand, by chance, the directory entry for AOPICDMN is fairly close to the beginning of the directory, which should reduce the time required to locate the directory entry.

To me, the real surprise was the PDSE performance relative to PDS performance. Long time readers of this forum probably know I am not an enthusiastic supporter of PDSE. In my experience PDSE requires more CPU and elapsed time than PDS; this was the first time I actually tried to measure PDSE fetch performance. At another level, this is not a big surprise. The structure of load modules dictates poor I/O performance, particularly for large load modules. The order of magnitude performance improvement, though was a surprise to me.

Interesting.

How "deep" in the linklist concatenation was the pds with the test module? I suppose the test loadlib was the only lib in the STEPLIB statement?

Is it possible that the pdse load only actually read dasd once and then used the previously read module?

d

dick scherrer wrote:Interesting.

How "deep" in the linklist concatenation was the pds with the test module? I suppose the test loadlib was the only lib in the STEPLIB statement?

Actually, I don't know. Since LINKLIST is supposed to have its directory in storage, it shouldn't matter. Or maybe my understanding is wrong.

Is it possible that the pdse load only actually read dasd once and then used the previously read module?

d

Perhaps. It was built in a temporary data set by IEBCOPY copying SYS1.LINKLIB to the temporary data set several steps before the test step.

The ICOPY program in the first step does a track image copy. The directory in the JCL was overlayed by the directory in the input data set. I wrote this program 3 years ago and it has performed flawlessly since then.

The TIMELOAD program was custom written for the test. The sole purpose of executing it using *.ddname was to not require it to be in a STEPLIB, which might have had an adverse effect on timing.

Additional research revealed the BLKSIZE for SYS1.LINKLIB in my system is 6144. This is less than optimal for a large load module. I wrote up this JCL to relink the load module into data sets with better DCB attributes.I got these results

• PDS - 0.14
• PDSE - 0.03

The PDS result was much better than before, though some of it was a faster BLDL time since the test library has just the one module. Still, the PDSE program object was 5X faster than the PDS load module.

Would not the dfference between the times (PDS/PDSE) be explained by the fact that from a PDS the system would use
Program Fetch and the whole module would be loaded. Whereas from a PDSE the system would use the Program Management Loader and would select only the objects required (possibly only a small subset of those contained in the load module).

nevilh wrote:Would not the dfference between the times (PDS/PDSE) be explained by the fact that from a PDS the system would use
Program Fetch and the whole module would be loaded. Whereas from a PDSE the system would use the Program Management Loader and would select only the objects required (possibly only a small subset of those contained in the load module).

I'm not sure what you mean by "Program Management Loader." In the context of my previous posts when I referred to Program Fetch I mean the z/OS service that loads load modules or program objects into storage. In all the test runs the program object was prepared by the Binder either directly in JCL, or by IEBCOPY to "copy" a load module to a program object. As you can see there was no defined method for the Binder to prepare the program object for a partial load, though something could be going on in the background I'm not aware of. The program was prepared as a "simple" structure that is loaded in one operation as defined in the "Simple Structure" chapter in MVS Assembler Services Guide.

When I think of "Program Management Loader" I think of using the Binder as a Linking Loader, as described in "The batch loader" chapter in MVS Program Management: User's Guide and Reference, not as some special function in program fetch. "The batch loader" chapter clearly states this is faster than linking and then loading the just linked program for execution as is typically done in xxxCLG type procedures. From a performance perspective, using the Binder as a linking loader is better, though this interface sometimes interferes with debugging. Most of the time, at least for me, the performance advantage is immaterial as I do almost 100% of my debugging in TSO, and I want access to symbols, which is often denied by loading the program via the linking loader piece of the Binder.

Most of my programs are "simple" programs statically linked with just one or two small functions, like the TIMELOAD program used in my test.

I was forced to read redbook Partitioned Data Set Extended Usage Guide about 5 years ago and if I remember correctly (not a given) the binder stored modules in a PDS and in a PDSE in different formats, and when the modules were invoked the system recognised from where the module came and handled it differently. But as I said this is based on a quick read of a manual a long time ago.

nevilh wrote:I was forced to read redbook Partitioned Data Set Extended Usage Guide about 5 years ago and if I remember correctly (not a given) the binder stored modules in a PDS and in a PDSE in different formats, and when the modules were invoked the system recognised from where the module came and handled it differently. But as I said this is based on a quick read of a manual a long time ago.

Wel, obviously program fetch must know if the module is a load module or program object - which it can do from the directory entry - and use the appropriate loader.

I know of the Redbook, but I don't think I've ever read it in detail.

I located the Partitioned Data Set Extended Usage Guide Redbook and browsed the interesting looking sections. Ultimately, it wasn't all that useful to me. It seemed, to me, to be 90% marketing.

I then went to the "FETCHOPT: Fetching mode option" section in MVS Program Management: User's Guide and Reference. This raised the "a ha" points I was looking for.

The default is FETCHOPT=(NOPACK,NOPRIME). I think the important option is NOPRIME.

PRIME | NOPRIME
Allows you to specify if the program object should be completely read into virtual storage before execution. When PRIME is coded, all of the program pages are read before program execution begins. When NOPRIME is coded, program pages are not read until they are needed during execution.

I then updated my test JCL to perform a third link edit, specifying FETCHOPT=(NOPACK,PRIME), and ran all three tests,

• PDS- 0.12
• PDSE with FETCHOPT=(NOPACK,NOPRIME) - 0.02
• PDSE with FETCHOPT=(NOPACK,PRIME) - 0.15

PDSE looked real good when it did not actually read anything! Who knows what would happen when the module executed, which was not part of the test. It didn't look all that good with FETCHOPT=(NOPACK,PRIME), though it wasn't quite so bad as PDSE usually is, though that may be a reflection of the PDS load module format more than a big endorsement of PDSE.

A big thank you to Mr. Scherrer and Nevilh for making me rethink the test and do more research and analysis. Dick, if I screwed up your surname in the last sentence, I apologize.