Endevor

Before I invent a wheel, I want to make sure there isn't one out there already....

I have a situation where a developer is calling Java routines from COBOL. Not that the technical details are important, but there is a statically linked routine within a routine that is dynamically called. In order to create the statically linked routine, the link deck looks something like this:

INCLUDE SYSLIB(AAAAAAAA)

INCLUDE '/usr/lpp/java/J7.0/bin/j9vm/libjvm.x'

INCLUDE '/usr/lpp/cobol/lib/igzcjava.x'

INCLUDE SYSLIB(BBBBBBBB)

ENTRY BBBBBBBB

ALIAS BBBBBBBB

NAME AAAAAAAA(R)

A linkedit with this input and the LIST parm results in an explosion of information in the linkedit list. It looks like Binder pretty much expands on the entire contents of libjvm.x and jgzcjava.x.

Now my observations:

1) I do NOT like having the path name in the link deck! That gives the ability to compromise everything-Endevor by allowing a developer to pretty much put whatever the path they want; audited, tracked, or otherwise. And Endevor cannot "MONITOR=COMPONENTS" on path names AND I cannot specify a pathname in the concatenation of SYSLIB.

2) Later in the linkedit listing, it gives me a module map that identifies which Java objects are REALLY being used (sort of... if the Java object is longer than 16 characters, the linked listing chops out the middle 2 and substitutes a "-".... but the real name is available earlier in the listing.

Has anyone else out there dealt with this yet and developed a good impact analysis track? I want a way of isolating paths and identifying what's really being used and from what library it came from. I am comfortable using CONSCAN and CONRELE.... although I may have to do a "double pass" since the module map occurs after the point where binder explodes with what it brought in from those Java libraries.

An update:

I figured out how I can secure the datasets. All I need to do is specify the pathname in the processor and change the INCLUDE statement to the DDNAME assigned to the path for the objects needing to be picked up. So that problem is "solved".

Eg. in processor

//USSJAVA DD PATH='/usr/path/etc/etc',PATHDISP=SHR

//USSCOB  DD PATH='usr/secondpath/etc',PATHDISP=SHR

or better will be a site variable.

Eg. in link deck

:

INCLUDE USSJAVA

INCLUDE USSCOB

:

Still curious about ideas on tracking components though....

This describes how I got around two input component monitoring problems. I do not like what I am sometimes doing to track the input components, maybe there is a better way, and this may not have relevance to your situation. For the C\CPP compiler I add a compiler step with SYSLIN DUMMY, set NOSEARCH, with a SYSLIB for vendor libraries and a USERLIB for the coded header files, avoiding the SEARCH() which appears to not work with component monitoring but are needed for the following expanded source compile step, which is followed by the actual compile step. So we are executing the compiler three times.  This is not a complete solution since there is no monitoring for the UNIX paths.  For COBOL I am doing something similar, except this time for the binder step prior to the pre-linkedit step (EDCPRLK) when the pre-linkedit step appears to be needed, because the input component monitoring fails for the pre-linkedit step and when the pre-linkedit step is executed the subsequent binder step is not retrieving the input components.