Topic
10 replies Latest Post - ‏2012-10-12T20:35:17Z by SystemAdmin
PeteInOxford
PeteInOxford
25 Posts
ACCEPTED ANSWER

Pinned topic Information about CALLed programs...

‏2012-08-08T07:12:09Z |
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.
Updated on 2012-10-12T20:35:17Z at 2012-10-12T20:35:17Z by SystemAdmin
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts
    ACCEPTED ANSWER

    Re: Information about CALLed programs...

    ‏2012-08-08T16:00:49Z  in response to PeteInOxford
    you may want to look at IBM utility AMBLIST
    which manages to tell you what is CALLed and how.
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts
    ACCEPTED ANSWER

    Re: Information about CALLed programs...

    ‏2012-08-08T16:08:05Z  in response to PeteInOxford
    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.
  • brataj
    brataj
    38 Posts
    ACCEPTED ANSWER

    Re: Information about CALLed programs...

    ‏2012-08-08T18:31:18Z  in response to PeteInOxford
    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.
    • PeteInOxford
      PeteInOxford
      25 Posts
      ACCEPTED ANSWER

      Re: Information about CALLed programs...

      ‏2012-08-09T13:49:59Z  in response to brataj
      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.
      • brataj
        brataj
        38 Posts
        ACCEPTED ANSWER

        Re: Information about CALLed programs...

        ‏2012-08-10T22:10:47Z  in response to PeteInOxford
        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
  • SystemAdmin
    SystemAdmin
    403 Posts
    ACCEPTED ANSWER

    Re: Information about CALLed programs...

    ‏2012-08-11T17:31:29Z  in response to PeteInOxford
    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.
    • PeteInOxford
      PeteInOxford
      25 Posts
      ACCEPTED ANSWER

      Re: Information about CALLed programs...

      ‏2012-08-13T14:32:29Z  in response to SystemAdmin
      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.
      • PeteInOxford
        PeteInOxford
        25 Posts
        ACCEPTED ANSWER

        Re: Information about CALLed programs...

        ‏2012-09-05T11:14:52Z  in response to PeteInOxford
        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.
        • BillWoodger
          BillWoodger
          75 Posts
          ACCEPTED ANSWER

          Re: Information about CALLed programs...

          ‏2012-09-27T06:54:06Z  in response to PeteInOxford
          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).
        • SystemAdmin
          SystemAdmin
          403 Posts
          ACCEPTED ANSWER

          Re: Information about CALLed programs...

          ‏2012-10-12T20:35:17Z  in response to PeteInOxford
          >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