Greetings, all.

I'm presently looking at getting rid of some obsolete copies of code from the client's production environment - the presence of obsolete copies of some modules has had its usual unpleasant effect. And I wondered...

While I understand that it's impossible to track (say)

CALL +VARIABLE-NAME+

external CALLs, is it possible to track

CALL +literal+

activity at all? Obviously when a module is statically linked to, the it will should be present in the ensuing load module. But what happens when a program is compiled with the DYN option and CALL literal. Are (e.g.) external references generated in the load module? How does the generated code really work? Is it even remotely possible to detect such calls given only a load module, as I have a fairly good load module analyzer already?

Answers/help greatly appreciated!

Cheers,

Pete.

you may want to look at IBM utility AMBLIST
which manages to tell you what is CALLed and how.

as a side note:

since the operating system only has the load module
(and no additional execution scripts)
and the operating system knows what to CALL, when to CALL it,
and where to look for the CALLed-module in order to check if it is already loaded, or load it if not,
all this info is in the link-edited rununit.

though a lot of IBM datasets are proprietary
(and therefore not described)
i think the load module structure is pretty well documented.

sounds as if your load-module analyzer is not so hot.

Hi Pete,

Whether doing dynamic calls by compiling with DYNAM, or NODYNAM and CALL variable, ultimately the call involves invoking a library routine (IGZCFCC in the current Cobol compiler) with the name of the called module as the first parameter in the parameter list, and the rest of the parameters as they would be passed in a static call.

You can figure out what's called by a program in this fashion by doing a careful analysis of the module's code to discover calls to IGZCFCC (there's no external reference for this, it's obtained from a library vector set up during initialization of the LE Cobol support) and working your way back to where the first parameter's pointer is set in the parameter list and dereferencing that pointer to find the module name. Of course if the module constructs the module name, you'd need to do some really sophisticated analysis.

Another approach is to write a machine code interpreter to interpret each of the paths through the code and watch for things of interest...

In short, it's all there in the executable, but it's probably easier to use source code scans.

Mr Rataj,

Many thanks for that, it's very informative. Spotting the L/BASR sequences involving the IGZCFCC address seems tolerably straightforward, in fact. So, to continue, is there a way of spotting, firstly, the start of the literal pool, and secondly, the length of the executable part of the program? I realize that this is not a "recognized" programming interface and all of that ... but the result might be useful as well as being seriously interesting in its own right.

Once again, thanks for the reply.

Cheers,

Pete.

Hi Pete,

It's not officially documented, and unfortunately varies subtly by Cobol version and perhaps RENT/NORENT as well, so one is left using the LIST option and compiling examples to discover how things hang together.

Bernie

You are correct that dynamic calls presents a problem. This is especially true when the caller constructs the target name at execution time. (I have actually seen cases where multiple string segments are concatenated, based on the transaction/data content.)

OTOH, I can offer a very straight forward solution for static calls and at least a start in the process of identifying where in your executable code there is a dynamic call.

Both of the above are standard output from the Edge Portfolio Analyzer (a.k.a., 'EPA'). I won't provide all the marketing details here, but you can check our Web site at www.edge-information.com or look in the IBM Ent. COBOL Migration Guide for a short reference to the 'EPA' tool.

In the case of static calls, there are two standard reports. One provides a simple 'Where Used' report for every CSECT in every load module in the load library being analyzed. A 'global' version of the report allows collecting information for as many libraries as you like into a single report. In the global case, the caller is identified by the load module and a pointer to the library where that module exists.

A companion report, looks for CSECT/Program names that exist more than once in a library or in a collection of libraries. Then it checks the compile date and the CSECT size. From this, the report contains those CSECTs that exist in your inventory with other than a single combination of compile date and size. A variation in either compile date or size is a clear clue that the two (or more) CSECTs have been changed and are the same only in their name. These should be your first target for investigation. And, in this case, the information is independent of static versus dynamic calls.

To investigate the dynamic calls, the EPA reports the information a bit different. The information is reported to indicate:
Dynamic CALLs for a given program/CSECT:
No dynamic calls found
CALL LITERAL FORCED (DYNAM)
CALL DATANAME
BOTH of the above

Because some older applications performed dynamic calls by using an Assembler 'helper' routine that has the combination of LOAD/CALL or by LINK, the information to key on is provided by a line that states:
xxxxxx HAS POTENTIAL SVC LOAD INSTRUCTION
-- EXAMINE THE SOURCE NEAR LOCATION X'000086'
Or, in the case of a LINK, the word LOAD in the above is replaced by 'LINK'. LINKs have other migration implications and issues that should investigated because they create new enclaves.

For more information, feel free to contact me off-list.

So, most of the information that you are seeking is available without having to resort to writing any code.

Good luck with your project.

Thanks for the replies, Carl and Bernie.

I'm very sorry to have to say that the module analyzer I've written already does pretty much all of that already, Carl (I feel bad about saying that). Bernie, without wanting to press excessively, I can get as far as the TGT, PGT and FCBs already, so there's not that far to go (I hope). But I need to expand the conversation a little. The TGT map from the 4.2 release of the compiler appears to have a mistake in it. Here's part of the map for a program of mine:

TGTLOC   000000  RESERVED - 72 BYTES 000048  TGT IDENTIFIER 00004C  RESERVED - 4 BYTES 000050  TGT LEVEL INDICATOR 000051  RESERVED - 3 BYTES 000054  32 BIT SWITCH 000058  POINTER TO RUNCOM 00005C  POINTER TO COBVEC 000060  POINTER TO PROGRAM DYNAMIC BLOCK TABLE 000064  NUMBER OF FCB'S 000068  WORKING-STORAGE LENGTH 00006C  RESERVED - 4 BYTES 000070  ADDRESS OF IGZESMG WORK AREA 000074  ADDRESS OF 1ST GETMAIN BLOCK (SPACE MGR) 000078  RESERVED - 2 BYTES 00007A  RESERVED - 2 BYTES 00007C  RESERVED - 2 BYTES 00007E  MERGE FILE NUMBER 000080  ADDRESS OF CEL COMMON ANCHOR AREA 000084  LENGTH OF TGT 000088  RESERVED - 1 SINGLE BYTE FIELD 000089  PROGRAM MASK USED BY THIS PROGRAM 00008A  RESERVED - 2 SINGLE BYTE FIELDS 00008C  NUMBER OF SECONDARY FCB CELLS 000090  LENGTH OF THE ALTER VN(VNI) VECTOR 000094  COUNT OF NESTED PROGRAMS IN COMPILE UNIT 000098  DDNAME FOR DISPLAY OUTPUT 0000A0  RESERVED - 8 BYTES 0000A8  POINTER TO COM-REG SPECIAL REGISTER 0000AC  RESERVED - 52 BYTES 0000E0  ALTERNATE COLLATING SEQUENCE TABLE PTR. 0000E4  ADDRESS OF SORT G.N. ADDRESS BLOCK 0000E8  ADDRESS OF PGT 0000EC  RESERVED - 4 BYTES

Here's a dump of the TGT in the loaded (but not executed!) module. The PGT pointer is 4 bytes out of position, per the map (the 3TGT
eyecatcher is correct) - the PGT address from the compile listing is X'000000FC'. I am confused. Any light you're allowed to cast on this
would be welcomed with open arms. Or does anyone else have anything to add?

4502/10 TGT (Relative). 00000000  00000000 00000000 00000000 00000000   *................* 00000010  00000000 00000000 00000000 00000000   *................* 00000020  00000000 00000000 00000000 00000000   *................* 00000030  00000000 00000000 00000000 00000000   *................* 00000040  00000000 00000000 F3E3C7E3 00000000   *........3TGT....* 00000050  06000000 04002020 00000000 00000000   *................* 00000060  00000000 00000004 0159D5E6 00000000   *.........ßNW....* 00000070  00000000 00000000 00000000 00000000   *................* 00000080  00000000 00005A40 00000000 00000000   *......! ........* 00000090  00000000 00000001 E2E8E2D6 E4E34040   *........SYSOUT  * 000000A0  C9C7E9E2 D9E3C3C4 00000000 00000000   *IGZSRTCD........* 000000B0  00000000 00000000 00000000 00000000   *................* 000000C0  00000000 00000000 00000000 00000000   *................* 000000D0  00000000 00000000 00000000 00000000   *................* 000000E0  00000000 000000FC 00000000 5A2C0000   *.......Ü....!...* 000000F0  00000000 2A180000 00000000 00000000   *................*

Cheers all,

Pete.

I'm having a good time with this; it's very instructive (difficult enough to be interesting,anyway).

But one thing has me a bit confused. Can anyone tell me if there's a way to find out what the offset of the BLW cells from the start of the TGT is (without running the program, of course)? It would be a huge help - I can get around not knowing, but it seems so basic a thing. Anyone know? I can see what might be an offset in the CGT that looks promising, but how to get to it reliably? Help!

I should point out that this is for VS COBOL II (most of tthe inventory was compiled with it, alas) and is thus a splendid exercise in software archaeology...

As always, any help/pointers/hints very gratefully received.

Cheers,

Pete.

Pete,

Out of interest, are you doing this in Cobol or something else?

You have raised a number of questions. Can you do an update to know what you have outstanding as "unknown as yet but would be interesting to know"?

The "ADDRESS OF PGT" when I look at a load is in the correct place, and when I look at an "executed"* program it is also in the correct place (unless my fingers have become unreliable for counting purposes). That seems to match re documentation vs what is actually there. Are you saying that you can show after a "load" that it is in a different place?

Cheers,

Bill

• (a word I've just coined for a program which has been subject to an EXEC and which has then abended (died), but which use will not catch on due to being too confusing).

>But one thing has me a bit confused. Can anyone tell me if there's a way >to find out what the offset of the BLW cells from the start of the TGT is >(without running the program, of course)? It would be a huge help - I can >get around not knowing, but it seems so basic a thing. Anyone know? I can >see what might be an offset in the CGT that looks promising, but how to >get to it reliably? Help!

>I should point out that this is for VS COBOL II (most of tthe inventory >was compiled with it, alas) and is thus a splendid exercise in software >archaeology...

You can look at the compiler listing you get with the LIST compiler option, it has all sorts of things mapped out for the TGT. And then you can start migrating to a COBOL compiler that is still in service :-)

COBOL is the Language of the Future!
Tom

Sorry for bumping this ancient thread, but I've got a related question.

 

We've currently got a legacy solution running that relies on finding the address of IGZCFCC at offset 256 in COBVEC which works fine when calling pre V5 COBOL programs.

It's my understanding that calling COBOL V5+ programs is done via IGZXFCA1. Where can I find this address? In LIBVEC?

I'd say that it is likely to be in LIBVEC, from this:

 

The Process Control Block section of the dump, shown in Figure 1, displays COBOL process-level control blocks THDCOM, COBCOM, COBVEC, and ITBLK. For Enterprise COBOL V5.1 and later releases, the process-level control blocks are COBPCB (corresponds to THDCOM), COBRCB (corresponds to COBCOM) and LIBVEC (corresponds to COBVEC). The control blocks are dumped for IBM® service personnel use.

But that little kicker at the end implies that "we" are not supposed to have specific knowledge of content, and that even if we work something out, it is subject to change without us being informed.

 

Probably you need a formal request to IBM, attempting to make a case, and see what they say.

Is it that all that you need is a reliable address of the module?

Why do you want the address?

 

Brian, 

 

The most volatile part of the compiler output is always the linkage stuff. But the offsets should be readily apparent in the LIST output. Why not write a 2-statement program (CALL, STOP RUN) and post the compiler listing, making sure you have NOOPT,LIST in the options? Soon sort it out. 

 

Pete. 

Hi Pete,

Good to see you back.

Brian, unless I've misunderstood, is after the address of the run-time routine which deals with dynamic loading of programs CALLed by a COBOL program. I don't think the compile listing is going to help.

As an aside, I think I've got more of an answer for a question you asked a while ago here, which, from memory, was "why doesn't this test for a particular binary value use a CLC?", and which then moved on to pondering the mountain of code generated for the use of COMP-5 PIC 9(9) fields.

Unfortunately the site has had two software changes since then, which both garbled postings and even lost the "owners" of posts.

If you are still interested, you could dig it out and see where we can get...

Cheers,

Bill

Bill, 

 

It's good to *be* back. Don't ever set out to restore an early-Victorian house :-0

 

i think it's perfectly sensible to look at the compile assembler listing. Unless things have changed really, really radically then there will be a pointer to LIBVEC (formerly COBVEC) in the TGT, and the offsets will be readily apparent; if they are not apparent then we need to know, if we're to fix this stuff. What interests / concerns me more is that Brian implies that his external-vendor code looks only for IGZCFCC; what about (say) IGZCLNK? He might not need the intercept at all!

 

Best regards,

 

Pete.

i think it's perfectly sensible to look at the compile assembler listing. Unless things have changed really, really radically then there will be a pointer to LIBVEC (formerly COBVEC) in the TGT, and the offsets will be readily apparent;

 

While I agree it's VERY obvious when looking at a V4 listing, it isn't obvious for me in V5+. It apparently just snatches an address from the constant area and calls it.

 

 

 what about (say) IGZCLNK? He might not need the intercept at all!

 

Would you care to elaborate?

Brian, unless I've misunderstood, is after the address of the run-time routine which deals with dynamic loading of programs CALLed by a COBOL program.

More precisely where the address is stored.

Why where the address is stored, rather than the address?

Bill: Because the address can vary from IPL to IPL. Or possibly from enclave to enclave. But where it lives (very likely within LIBVEC) won't. 

Brian: I need to check something to answer that properly - expect a post either late today or over the weekend. Could you post that compile listing (as a text file or the line breaks will drive us all mad) if you have time? 

cheers both,

Pete.

But, you can get the address without having to know where it is stored. You don't need to know where LE happened to have stored it today (before an IPL, before an LE PTF, before a new z/OS release, etc).

If the knowledge is only for a reliable source of the address, there's a better way to do it.

If the knowledge is for something else, actually requiring the address of the address (in COBVEC/LIBVEC depending on COBOL version), rather than the address, then there may be a better way to do that. Or not. We wait with anticipation.

Thanks for responding - here's a listing.

Crikey, you're right, Brian. What a pain that preliminary code is to follow(not least because of the routines it calls). But happily I don't think you need to do a thing (sorry, but the light bulb only went on after a delay). Let's look at the original question again:

 

We've currently got a legacy solution running that relies on finding the address of IGZCFCC at offset 256 in COBVEC which works fine when calling pre V5 COBOL programs.

It's my understanding that calling COBOL V5+ programs is done via IGZXFCA1. Where can I find this address? In LIBVEC?

 

Your module, you say, wants the address of IGZCFCC (which is indeed at offset 256 in COBVEC). Why not just carry on using that? It is bound to work (so long as you use the current LE version of IGZCFCC) because all versions of COBOL are interoperable. I'm happy to grant that  you might have real trouble if your legacy code runs AMODE(24). Chapter 19 of the Migration Guide has all the gory bits. If you have statically-linked modules you might want to carry out CSECT REPLACE operations to get any old versions of the library routines out - always a good move - but otherwise it should work.

 

So you should be fine. Now we ask the interesting question, which (inevitably) is: why do you need this address in the first place? Could we not (collectively) contrive a work-around?

 

 

Well, first of all, thanks for investing some time into this Pete.

 

I might've worded my original question poorly - For hooking purposes I need to know where the address is of the module that LE is using to dynamically call other programs. And that has changed, so once we've recompiled eveything with V5+, it's of no value to know where LE finds IGZCFCC.

 

 

Aha, if you're hooking the call this all makes sense! To find out the offset ... hmmm. TGT --> CDE list gets you to the address for <module> in the LPA. Then follow the pointer to LIBVEC and scan for that address? Messy, but it gets you there in the end. Or this might help as a starter (to do the same thing, saves scanning the CDE entries). Don't know whether this would pick up a module in the LPA, but it's a start anyway. DO please let us know how you get on!  

Cheers,

 

Pete.

 

 Identification                  Division.                       *                                                                 Program-ID. TestFP.                                             /                                                                 Environment                     Division.                       *                                                                 Configuration                   Section.                        *                                                                 Source-Computer. IBM-Zseries with debugging mode.                Object-Computer. IBM-Zseries.                                   /                                                                 Data                            Division.                       *                                                                 Working-Storage                 Section.                        *                                                                 01  WA-Program-Pointer-X.                                            05  WA-Program-Pointer                     Procedure-Pointer./                                                                 Procedure                       Division.                       *                                                                 0000-Mainline                   Section.                        *                                                                *    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *    *                                                         * *    *    This section controls overall flow through the       * *    *    program.                                             * *    *                                                         * *    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *                                                                     Set WA-Program-Pointer      to  Entry 'IGZCFCC'             *                                                                     Display 'TestFP-0000/00 Procedure-Pointer for IGZCFCC is '  -            Quote                                                            WA-Program-Pointer-X                                             Quote                                               *                                                                     Stop Run.                                                  

FYI the address of  IGZXFCA1 can be found at offset x'1FC' in LIBVEC.

We've got our hooking working again.

Only tested it in batch with mixed COBOL V4 and V5+ so far though.