steve-myers wrote:You really should be using the Binder programs, not the old OS/360 based programs.
Not sure if I understand what you mean by the Binder programs. I had checked the IEWBIND description, but it appeared to me as it could not do the same for me as HEWLD - i.e. to load a given load module into virtual storage without identifying it. Am I wrong?
The Binder appeared in the 1990s as a greatly improved - especially in performance - Linkage Editor.
The "batch loader" - a linking loader - originally appeared in the late 1960s. In this context, a "linking loader" is a program that combines the basic linkage editor functions and prepares an executable program in storage.
JCL like this appeared in several places and was frequently executed.
//LKED EXEC PGM=IEWL,...
//SYSPRINT DD SYSOUT=*//SYSUT1 DD ...
//SYSLIB DD ...//SYSLMOD DD DISP=(NEW,PASS),..,DSN=&&GOSET(GO)
//SYSLIN DD ...
//GO EXEC PGM=*.LKED.SYSLMOD
The statements in red were particularly wasteful, especially since OS/360 JCL processing was very slow. The temporary data set allocated by the SYSLMOD DD statement was especially wasteful since it was usually used once and subsequently discarded.
All this JCL was in cataloged procedures, and there were frequently problems overriding the SYSLMOD DD statement. This caused many reruns, and sometimes programmers managed to delete their load library data set!
The batch loader replaced the preceding JCL with
//GO EXEC PGM=LOADER,...
//SYSLOUT DD SYSOUT=*
//SYSLIB DD ...
//SYSLIN DD ...
In other words, it replaced two job steps with one job step, and did not allocate the SYSUT1 temporary data set or the SYSLMOD data set.
Unfortunately, the batch loader did not work out well, for at least three reasons
- Then, as now, programmers were reluctant to change JCL, which they often did not understand very well, with new JCL to use the batch loader.
- Combining execution JCL with the JCL to run the batch loader was confusing for many programmers.
- Analysis of program ABENDs, especially in the MVT environment was different. The dumps were different, and were all too often useless.
The Binder appeared in the 1990s as a replacement for the Linkage Editor. The 1960s "batch loader" program disappeared as a completely separate program and product; it was now part of the Binder. The SYSLIN data set could have Binder control statements in addition to the "object module" data accepted by the "batch loader," which caused other issues with the intended users of the "batch loader."
Well, enough history lesson, which you're probably not interested in anyway.
Another question you seemed to have concerned DD lists. I went back to the manual, and I think I understand why you're confused. I think, between my previous discussion and the contents of the manual, that you should understand them well enough for your purposes.
Now, why use the linking loader function of the Binder in place of the "batch loader?" The old "batch loader" cannot analyze program objects prepared by the Binder.
Finally, you have not told us what you intend to do with the loaded program prepared by the linking loader.
If you intend to execute the program, you should use the load with "identify" function of the linking loader, and use the LINK or ATTACH macros to run the loaded program by name rather than use the CALL macro. LINK or ATTACH will handle address mode switching which a simple CALL macro will not.
Now, you ask, what's the "identify" stuff? A very good question, if you have gotten this far. IDENTIFY is a macro a programmer can use to add a module name to the job pack area. The linking loader uses an undocumented feature of the IDENTIFY macro to add the entire loaded module to the job pack area. If you are not going to execute the loaded module there is no good reason to bother, but if you are going to execute the program, then use it.