Subdividing C1R020W members into "definitely a problem" and "maybe a problem"

[Anon Anon]

I have a large load library which "for historical reasons" has quite a few members which are either entirely un-footprinted or partially un-footprinted - i.e. there are one or more CSECT's which don't have footprints.

 

I've run a CONRPT83 report to identify these and have got a long list of modules (several thousand) that have a C1R020W message - C1R020W NO FOOTPRINT PRESENT, UNABLE TO CORRELATE TO MCF.

 

What I'd like to do is to split this list into two:-

• those members which may have a problem, that is, where there is an element within Endevor with the same name as the offending CSECT; and
• those where there is definitely a problem , that is, where no element exists with the same name as the offending CSECT.

 

Anyone any suggestions for a nifty way of doing this?

 

Thanks

 

Charles

[Craig Fontaine]

Charles:

 

CONRPT83,  FOOTPRINT EXCEPTION REPORT, has an exclude member or csect parameter. If you exclude the IBM runtime csects (CEE* or IGZ* for COBOL) you can eliminate many of the C1R020W messages. That would leave behind the modules that really need to be researched.  You can include multiple 'exclude csect' statements:

   REPORT  83 .        

   ENVIRONMENT ENV1 .  

ANALYZE .             

INCLUDE MEMBERS *  .  

EXCLUDE CSECTS  CEE*  

EXCLUDE CSECTS  IGZ* .

 

Craig

[Anon Anon]

Hi Craig,

 

Thanks - I've already done this, and still have several thousand left to research

 

The situation tends to arise because of one of two reasons:

 

(A) Historically there has been a problem with footprinting, which has meant that the element just does not have a footprint.  It could be, for example a very old module which hasn't been recompiled or assembled for 30 years, predating use of Endevor, but people have done the right thing and stored the source in Endevor that matches the executable.

 

(B) Someone has compiled outside Endevor, copied the load module in manually, lost the source (or maybe the source was deleted later because they thought nobody was using it), so now it's impossible to recreate the module if ever you did need to amend it / recompile it / reassemble it.

 

For reason A, it's a potential exposure (you can't guarantee that the source and executable match), but you're probably okay.  For reason B, it's a definite exposure.

 

What I'd like to do is to have a way of identify those that are a definite exposure (i.e. no footprint and no obvious source in Endevor)

[Craig Fontaine]

The loss of the source-object connection can be a big problem. I hesitate to mention it, but there is the Inventory Analyzer. It was designed to go through a load library, by looking at CSECT names, determine the code type, then associate with a source member. The problem is that the rules it uses to determine the type are out of date. There are no plans to update them. The fact that is has it's own guide also tells you it isn't intuitive to use.

 

Too bad they didn't have the vision to only place Endevor generated modules in Endevor loadlibs. CA Professional Services can deal with these sort of issues.           

[Ollivier-Francois Dorso]

Hi Charles,

 

I agree with Craig about Inventory Analyzer and I would add that it can footprint Loads, ie

 

The Inventory Analyzer creates syntax (SCL) that can be used as input to the Load Utility. The Load Utility lets you directly load software components into CA Endevor SCM and, optionally, to footprint executables.

Our consulting staff can help you to elaborate a solution to answer your 2 points.

 

Regards,

Ollivier

[Josef Thaler]

Hello Charles,

I think it's specific to the particular installation, which loadmodules could be assigned to which element types, systems etc. Therefore, a general solution might be difficult to create.

Just from the top of my head two possible approaches:

(1) You can write the footprint exception report to disk, select the C1R020W-member-lines, and transform them into LIST ELEMENT statements. You can do this for example by a rexx or a SORT-step. You can add "static parts" of the element-key like ENV, STAGE, TYPE, SYS, SUB as SET-commands in front of the "generated" LIST-statements and execute the whole as batchjob against your Endevor-site. LIST-Statements resulting in RC=4 would indicate a missing element-source.

(2) You can transform the member names of the footprint violation report into a flat file (again using rexx, SORT or similar). Then you can extract the relevant *) Element-names from your Endevor-site using CSV-Utility, also creating a flat file. By comparing these two flat files you can identify members without element-names.

*) relevant: I mean, it would make sense, only to extract those element types which could result in a load-module, a copybook and a loadmodule with the same name is definitely an exposure, although an element exists. 

I guess, that in the meantime you have implemented security, that only Endevor (alternate Userid) is allowed to add, modify or delete loadmodules in your Endevor-controlled loadlibs and compiles outside of Endevor result in a separate loadlib.

 

Kind regards,

Josef

[Craig Fontaine]

Charles:

 

It seems there is no 'good' option. If you try to base the connection between load and source be name only, there will always be the possibility that you have the wrong source. Any changes to the 'source' may not create the expected changes in the load. You can regenerate the suspected source and compare those loads to the existing load members. That will be better, but still not perfect. You can still have unexpected results. I assume these orphaned load members do not get updated frequently. Can you just live with them until the application is retired ? The perfect solution would be to regenerate the orphans and retest. I really doubt if anyone would go through that process.

 

regards,

Craig  . 

[Anon Anon]

Hi Craig,

 

I think you're missing the point as to why I want to differentiate between those that may be a problem and those which definitely are a problem.

 

You (it seems) are a pessimist.  Assume that I am an optimist.

 

Un-footprinted load modules which have source with names that match within Endevor may not have a potential problem.  If I'm an optimist, I can say that they're not a problem.  For greater certainty, I could sample a percentage of the source, recompile, test and regression test to see whether the results are the same (i.e. functionally equivalent modules).  Statistics can give me the margin of error.  If the statistics show a likely problem, the application teams can schedule some time to recompile key module from the source they do have, regression testing and re-fixing any bugs that are discovered.

 

Un-footprinted load modules which do not have source with names that match within Endevor definitely do have a potential problem.  These are the ones where application teams need to definitely take action to try and track down the source, or get someone to sign-off on the risk of the module needing amendment (or even just recompilation) in the future.

 

I agree that both are potential problems and in an ideal world you should resolve all potential issues.  However, if the potential problem becomes reality, then the impact is quite different.

 

You are correct in saying that these orphaned load members do not get updated frequently.  Maybe not for decades.  "Can we live with them until the application is retired?"  That's not a question I can answer as an Endevor administrator - that's a question for someone higher up the pecking order than me.  What I do know is that one of the questions they will want answering (quite justifiably) is "how big is the problem?".

 

In order for them to take their decision in a scientific way, I'd like to be able to answer them along the lines of "we have x% of modules which at least potentially do not have matching source in Endevor.  Of these y% of modules possibly/probably do have matching source, (but we can't be 100% certain it matches);  and z% of modules definitely do not have any matching source within Endevor"

 

Cheers

 

Charles

[Craig Fontaine]

Charles:

 

You already know that footprinted members have a high confidence level that the corresponding source is known. Those members which have matching element names but without footprint less certainty. Those without matching names and footprints have low confidence. From a practical point of view, the non-footprinted members should be concatenated after the footprinted library.  Over time, the new footprinted modules get loaded first over time. Those without matching names are stagnant, until someone come up with the source.

 

regards,

Craig