IBM Mainframe Forum

I had tried the same, just without the IEBGENER step. But with or without it, I keep getting



Remember: I cannot use the LOAD macro because I want the load module to be loaded, but not identified, as explained earlier. If you have a better idea how to achieve this (instead of using the batch loader), I'd be really happy if you could share it!

AntonioS wrote:... Remember: I cannot use the LOAD macro because I want the load module to be loaded, but not identified, as explained earlier. If you have a better idea how to achieve this (instead of using the batch loader), I'd be really happy if you could share it!

The only alternative I can see is almost certainly beyond your abilities, which is to "load" the load module yourself. You obtain the directory entry for the load module using the BLDL macro. There are four fields in the directory entry you'll need: the TTR (record address) of the first text record, the number of storage bytes for the load module, the size of the first text record, and the entry point. If you are unlucky enough to "load" a load module prepared by the OS/360 Linkage Editor you will need a fifth field: the storage address of the first text record. The first text record in load modules prepared of an OS/VS Linkage Editor always start at relative address 0.

I used to have an example, but it has disappeared. It would take me a week or more to recreate it, if I were interested, which I'm not.

Are you sure you're trying to "load" a load module in a PDS? The old linking loader cannot process a program object in a PDSE.

These users thanked the author steve-myers for the post:

AntonioS (Fri Oct 03, 2014 11:00 pm)

steve-myers wrote:

AntonioS wrote:Are you sure you're trying to "load" a load module in a PDS? The old linking loader cannot process a program object in a PDSE.

You're indeed a genius! That was exactly the problem! Thank you!

Regarding the LOAD macro, I would actually prefer to use it to load the module, but I do not want the module to be identified because I want my own module to be called first. Do you know of any way to "unidentify" a loaded module? Or maybe I could update the entry point address after the load? However, I guess that goes a bit deeper into internal structures than I would want, similar to your idea to do the loading on my own. (Btw, if I loaded the module into storage, wouldn't there still be the problem to link-edit addresses in the module?)

AntonioS wrote:... You're indeed a genius! That was exactly the problem! Thank you!

No, I'm not a genius. I've just been in this trade a lot longer than you.

Regarding the LOAD macro, I would actually prefer to use it to load the module, but I do not want the module to be identified because I want my own module to be called first. Do you know of any way to "unidentify" a loaded module?

No, I don't.

Or maybe I could update the entry point address after the load?

Ah, now I think I see what you want to do, though I'm not sure why you would want to do it.

However, I guess that goes a bit deeper into internal structures than I would want, similar to your idea to do the loading on my own. (Btw, if I loaded the module into storage, wouldn't there still be the problem to link-edit addresses in the module?)

To use more jargon than I think you want, but ... you want to process the CESD data in the load module. The CESD data defines the external symbols in the module; its formats are documented reasonably well in the two Program Management manuals. If you can figure out how to load the module yourself analyzing the CESD data is not all that difficult.

This reminds me of something that happened in 1972. It had to be 1972 because it was before the data center moved out to the 'burbs later that year. One of my colleagues brought me a load module - a 1460 simulator, if my memory is correct. Its vendor maintained it using SUPERZAP. As it happened the SUPERZAP IDR area was full. The appropriate response, then as now, would be to link edit the module to create more IDR space, but the idiots that created the module arranged it so you couldn't relink the module; its entry point was at an address that was not an external symbol. I don't know if SUPERZAP of that era had an option to ignore an IDR full problem, which would be another way to resolve the problem. In any event the problem was similar to what I think is your problem; you want some sort of alternate entry point. Now, if your entry point is at an external symbol, you can specify it in the old linking loader with PARM='EP=symbol' or the equivalent in your program. If you are using the Binder's version of the linking loader, you can use the ENTRY statement in the SYSLIN data set.

steve-myers wrote:No, I'm not a genius. I've just been in this trade a lot longer than you.

Yes, I believe so. But anyway, that was an impressive remote diagnosis.

steve-myers wrote:Ah, now I think I see what you want to do, though I'm not sure why you would want to do it.

This is why: Let's assume we have a module PROGA which contains a call to PROGB. I want to find a way to intercept the call in order to count the number of calls and collect some data passed from PROGA to PROGB and back. I cannot modify neither PROGA nor PROGB which would of course be the simplest way to solve it.

OK. You have to manually load the load module, then use data from the CESD and RLD data in the load module, identify the calls, and insert your intercepts.

It's actually more difficult than that.

A CALL (in Assembler, anyway) is usually something like

L 15,=V(PROGB)
BALR 14,15

Now this is static linkage; dynamic linkage is different. Between the CESD data and RLD data the only part you can identify is the address of PROGB. Your counter code would alter the address pointer to PROGB to go to your counter routine which does its counting, restores registers 0 to 14, loads the address of PROGB into register 15, and branches to it. This is pretty heavy stuff. Good luck!

Another approach. You would have to use the Binder's linking loader; the old linking loader does not have an XREF map. After you have done the load, you would have to use the SYSLOUT output. For example -
andOffset 1018 in the module has a V-type address constant that points to external symbol MINIFMT. Though it is not obvious from this listing, the calls, from at least two locations, are in SMFCOPY. Anyway, to intercept calls to MINIFMT, you update the address constant at 1018 in the module. Clear?

Thank you very much for your input. I am currently experimenting with the different ways to solve it. Not sure which way to do it yet. Maybe the CHANGE or REPLACE statement can help me. If I have understood it right, that way I might INCLUDE an own little entry code program and tell the binder to use it as the original entry point name.

I'll be back.

AntonioS wrote:... I am currently experimenting with the different ways to solve it. Not sure which way to do it yet. Maybe the CHANGE or REPLACE statement can help me. If I have understood it right, that way I might INCLUDE an own little entry code program and tell the binder to use it as the original entry point name. ...

I thought about that, too, but I hadn't gotten far enough to come up with something I was sure would actually work.

If I understand what you want to do, inserting your routine as the primary entry point for the load module probably won't do you much good. It might be easier than inserting an intercept routine, but that's about all.