IBM's CCCA and customized LCPs for Enterprise COBOL migration

I am working on a z/OS Enterprise COBOL migration project and will be using 
IBM's CCCA product to automate the code conversion.  I'm interested in 
hearing from anyone who has experience customizing the LCPs for this 
product.

I have two near-term goals:

1. Remove any CBL (PROCESS) statements.
2. Convert calls to ILBOABN0 to CEE3ABD.

You can reach me here or off-list.

Thanks!

Larry Kahm
Heliotropic Systems, Inc.


0
lkahm (13)
9/26/2007 10:49:40 AM
comp.lang.cobol 4261 articles. 0 followers. Post Follow

11 Replies
395 Views

Similar Articles

[PageSpeed] 20

Larry,
  I would really be surprised if you find many (hear or anywhere) that have done 
this.  "Back in the day" when CCCA was in more demand/use than it is today, 
there were several presentations at GUIDE on it.  I had some of my own ideas 
about doing some CPs for "odd situations" - but never found ANYONE else using 
that facility.

You *might* find more takers in IBM-MAIN or the CICS list than on 
comp.lang.cobol (but even there, I sort-of doubt it)

   ***

P.S. For my own information, any reason that you are removing CBL statements? 
(Are these just CICS ones with things like RES,LIB - where the "RES" is now 
ignored)?

P.P.S.  If you are looking for ILBOABN0, you might also want to look for 
ILBOWAT0 - although that was pretty rare in its use.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Larry Kahm" <lkahm@nospam_heliotropicsystems.com> wrote in message 
news:8PqKi.3071$kA4.1224@trnddc07...
>I am working on a z/OS Enterprise COBOL migration project and will be using 
>IBM's CCCA product to automate the code conversion.  I'm interested in hearing 
>from anyone who has experience customizing the LCPs for this product.
>
> I have two near-term goals:
>
> 1. Remove any CBL (PROCESS) statements.
> 2. Convert calls to ILBOABN0 to CEE3ABD.
>
> You can reach me here or off-list.
>
> Thanks!
>
> Larry Kahm
> Heliotropic Systems, Inc.
>
> 


0
wmklein (2605)
9/26/2007 12:45:04 PM
Bill,

I'll try cross-posting in a day or so.

As for removing CBL statements - I'd like to make sure that all of the 
compile options are standardized in the change management product.  If 
options exist in the source, as opposed to on an ISPF panel, no one's going 
to know what they are.

One goal I have, as a side-effect of migration, is to ensure that all of the 
compile options - for both batch and online - support the use of Fault 
Analyzer and Debug Tool.

Larry Kahm
Heliotropic Systems, Inc.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message 
news:kvsKi.568704$Bo7.411763@fe07.news.easynews.com...
> Larry,
>  I would really be surprised if you find many (hear or anywhere) that have 
> done this.  "Back in the day" when CCCA was in more demand/use than it is 
> today, there were several presentations at GUIDE on it.  I had some of my 
> own ideas about doing some CPs for "odd situations" - but never found 
> ANYONE else using that facility.
>
> You *might* find more takers in IBM-MAIN or the CICS list than on 
> comp.lang.cobol (but even there, I sort-of doubt it)
>
>   ***
>
> P.S. For my own information, any reason that you are removing CBL 
> statements? (Are these just CICS ones with things like RES,LIB - where the 
> "RES" is now ignored)?
>
> P.P.S.  If you are looking for ILBOABN0, you might also want to look for 
> ILBOWAT0 - although that was pretty rare in its use.
>
> -- 
> Bill Klein
> wmklein <at> ix.netcom.com
> "Larry Kahm" <lkahm@nospam_heliotropicsystems.com> wrote in message 
> news:8PqKi.3071$kA4.1224@trnddc07...
>>I am working on a z/OS Enterprise COBOL migration project and will be 
>>using IBM's CCCA product to automate the code conversion.  I'm interested 
>>in hearing from anyone who has experience customizing the LCPs for this 
>>product.
>>
>> I have two near-term goals:
>>
>> 1. Remove any CBL (PROCESS) statements.
>> 2. Convert calls to ILBOABN0 to CEE3ABD.
>>
>> You can reach me here or off-list.
>>
>> Thanks!
>>
>> Larry Kahm
>> Heliotropic Systems, Inc.
>>
>>
>
> 


0
lkahm (13)
9/27/2007 1:20:41 PM
>>> On 9/27/2007 at 7:20 AM, in message <J6OKi.1319$kk4.688@trnddc08>,
Larry
Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
> Bill,
> 
> I'll try cross-posting in a day or so.
> 
> As for removing CBL statements - I'd like to make sure that all of the 
> compile options are standardized in the change management product.  If 
> options exist in the source, as opposed to on an ISPF panel, no one's 
> going 
> to know what they are.
> 
> One goal I have, as a side-effect of migration, is to ensure that all of 
> the 
> compile options - for both batch and online - support the use of Fault 
> Analyzer and Debug Tool.

Hmm, that's an interesting point of view.  I would think it would be
*easier* to know what the compile options are if they were included in the
source code.

When recompiling a particular source code how does one know that they need
to apply a particular compile option override?

As an example, our default compile option is ADV (versus NOADV).  However we
have some programs that we converted from old COBOL where we decided not to
remove the 'control character' field on the report file, and thus we need to
compile these with the NOADV option.  So we simply put "PROCESS NOADV" as
the first line in the program.  (PROCESS and CBL are synonyms.)

Perhaps I am misunderstanding the issue...

Frank

0
9/27/2007 4:33:30 PM
Frank,

No misunderstanding, just a different point of view....

I've always been a proponent of keeping the control of the compile process 
in the change management system.  In your case, since it was a known issue, 
I'd have you simply enter the appropriate override on the ChangeMan or 
Endevor panel.  It remains associated with your program from then on.

In the assignment I'm still bidding on, the original developers are 
undoubtedly long gone and the offshore talent may or may not know what to do 
about certain options.  If I can find something that's "hidden" and expose 
it during conversion, I've placed the decision point closer to the 
programmer - and the project office.  Once it is known, they can document 
the choice in the change management product when they compile the program.

Larry Kahm
Heliotropic Systems Inc.


"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message 
news:46FB86FA.6F0F.0085.0@efirstbank.com...
>>>> On 9/27/2007 at 7:20 AM, in message <J6OKi.1319$kk4.688@trnddc08>,
> Larry
> Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
>> Bill,
>>
>> I'll try cross-posting in a day or so.
>>
>> As for removing CBL statements - I'd like to make sure that all of the
>> compile options are standardized in the change management product.  If
>> options exist in the source, as opposed to on an ISPF panel, no one's
>> going
>> to know what they are.
>>
>> One goal I have, as a side-effect of migration, is to ensure that all of
>> the
>> compile options - for both batch and online - support the use of Fault
>> Analyzer and Debug Tool.
>
> Hmm, that's an interesting point of view.  I would think it would be
> *easier* to know what the compile options are if they were included in the
> source code.
>
> When recompiling a particular source code how does one know that they need
> to apply a particular compile option override?
>
> As an example, our default compile option is ADV (versus NOADV).  However 
> we
> have some programs that we converted from old COBOL where we decided not 
> to
> remove the 'control character' field on the report file, and thus we need 
> to
> compile these with the NOADV option.  So we simply put "PROCESS NOADV" as
> the first line in the program.  (PROCESS and CBL are synonyms.)
>
> Perhaps I am misunderstanding the issue...
>
> Frank
> 


0
lkahm (13)
9/27/2007 11:54:42 PM
>>> On 9/27/2007 at 5:54 PM, in message <6pXKi.4058$Wo4.771@trnddc03>,
Larry
Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
> Frank,
> 
> No misunderstanding, just a different point of view....
> 
> I've always been a proponent of keeping the control of the compile 
> process 
> in the change management system.  In your case, since it was a known 
> issue, 
> I'd have you simply enter the appropriate override on the ChangeMan or 
> Endevor panel.  It remains associated with your program from then on.
> 
> In the assignment I'm still bidding on, the original developers are 
> undoubtedly long gone and the offshore talent may or may not know what 
> to do 
> about certain options.  If I can find something that's "hidden" and 
> expose 
> it during conversion, I've placed the decision point closer to the 
> programmer - and the project office.  Once it is known, they can document

> 
> the choice in the change management product when they compile the 
> program.

Sounds like our change management software is simply lacking when it comes
to those capabilities.  With those capabilities in place your usage of them
sounds quite reasonable.

When compiling for testing are you still able to access change management in
order to make sure that your test compiles have the same compile options as
your production compiles?

Frank



0
9/28/2007 12:34:14 AM
In various sites, I've seen differences in compile options at different 
stages.  Sometimes this was deliberate, other times it was based on history. 
I believe the options should be set once for all levels - and overrides used 
if at all necessary.

With ChangeMan, you compile once for the lowest level of the promotion path, 
and the source and load module are copied (in tandem) through each level of 
the path.  With Endevor, you compile at each level of the promotion path - 
and with that comes the risk that the options >may< not be the same.  I 
believe SCLM handles things the same way that ChangeMan does.  I can't speak 
for other products.

One of the aspects of this Enterprise COBOL migration that I want to ensure 
is that the options are a) reviewed, b) understood in context, and c) 
standardized across promotion levels.  Because I'm still idealistic, I'd 
like them to be consistent across applications (but I know better)....

Larry Kahm
Heliotropic Systems, Inc.

In most cases, I believe application programmers start with their own 
"home-grown" JCL.  Once they get through a couple of desk checks, they have 
to load it into Endevor for unit testing.  At that point, the change 
management system's load libraries are used
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message 
news:46FBF7A6.6F0F.0085.0@efirstbank.com...
>>>> On 9/27/2007 at 5:54 PM, in message <6pXKi.4058$Wo4.771@trnddc03>,
> Larry
> Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
>> Frank,
>>
>> No misunderstanding, just a different point of view....
>>
>> I've always been a proponent of keeping the control of the compile
>> process
>> in the change management system.  In your case, since it was a known
>> issue,
>> I'd have you simply enter the appropriate override on the ChangeMan or
>> Endevor panel.  It remains associated with your program from then on.
>>
>> In the assignment I'm still bidding on, the original developers are
>> undoubtedly long gone and the offshore talent may or may not know what
>> to do
>> about certain options.  If I can find something that's "hidden" and
>> expose
>> it during conversion, I've placed the decision point closer to the
>> programmer - and the project office.  Once it is known, they can document
>
>>
>> the choice in the change management product when they compile the
>> program.
>
> Sounds like our change management software is simply lacking when it comes
> to those capabilities.  With those capabilities in place your usage of 
> them
> sounds quite reasonable.
>
> When compiling for testing are you still able to access change management 
> in
> order to make sure that your test compiles have the same compile options 
> as
> your production compiles?
>
> Frank
>
>
> 


0
lkahm (13)
9/28/2007 1:51:54 PM
Larry,
   What interactive debugging tool do you recommend?  I certainly am a believer 
in TEST and sometimes SSRANGE at unit testing levels.  By system test, I would 
expect OPT and possibly NOSSRANGE.  The question of whether or not to create a 
"sym" dataset for production - depends on what you are using - and I know you 
mentioned Fault Analyzer.

P.S.  Larry - as you don't "visit" this site all that often, you may not know 
that Frank works under VSE, not z/OS - so I don't remember which change 
management systems are available there.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Larry Kahm" <lkahm@nospam_heliotropicsystems.com> wrote in message 
news:_F7Li.1691$jC5.166@trnddc04...
> In various sites, I've seen differences in compile options at different 
> stages.  Sometimes this was deliberate, other times it was based on history. I 
> believe the options should be set once for all levels - and overrides used if 
> at all necessary.
>
> With ChangeMan, you compile once for the lowest level of the promotion path, 
> and the source and load module are copied (in tandem) through each level of 
> the path.  With Endevor, you compile at each level of the promotion path - and 
> with that comes the risk that the options >may< not be the same.  I believe 
> SCLM handles things the same way that ChangeMan does.  I can't speak for other 
> products.
>
> One of the aspects of this Enterprise COBOL migration that I want to ensure is 
> that the options are a) reviewed, b) understood in context, and c) 
> standardized across promotion levels.  Because I'm still idealistic, I'd like 
> them to be consistent across applications (but I know better)....
>
> Larry Kahm
> Heliotropic Systems, Inc.
>
> In most cases, I believe application programmers start with their own 
> "home-grown" JCL.  Once they get through a couple of desk checks, they have to 
> load it into Endevor for unit testing.  At that point, the change management 
> system's load libraries are used
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message 
> news:46FBF7A6.6F0F.0085.0@efirstbank.com...
>>>>> On 9/27/2007 at 5:54 PM, in message <6pXKi.4058$Wo4.771@trnddc03>,
>> Larry
>> Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
>>> Frank,
>>>
>>> No misunderstanding, just a different point of view....
>>>
>>> I've always been a proponent of keeping the control of the compile
>>> process
>>> in the change management system.  In your case, since it was a known
>>> issue,
>>> I'd have you simply enter the appropriate override on the ChangeMan or
>>> Endevor panel.  It remains associated with your program from then on.
>>>
>>> In the assignment I'm still bidding on, the original developers are
>>> undoubtedly long gone and the offshore talent may or may not know what
>>> to do
>>> about certain options.  If I can find something that's "hidden" and
>>> expose
>>> it during conversion, I've placed the decision point closer to the
>>> programmer - and the project office.  Once it is known, they can document
>>
>>>
>>> the choice in the change management product when they compile the
>>> program.
>>
>> Sounds like our change management software is simply lacking when it comes
>> to those capabilities.  With those capabilities in place your usage of them
>> sounds quite reasonable.
>>
>> When compiling for testing are you still able to access change management in
>> order to make sure that your test compiles have the same compile options as
>> your production compiles?
>>
>> Frank
>>
>>
>>
>
> 


0
wmklein (2605)
9/28/2007 2:18:36 PM
On Thu, 27 Sep 2007 23:54:42 GMT, "Larry Kahm"
<lkahm@nospam_heliotropicsystems.com> wrote:

>I've always been a proponent of keeping the control of the compile process 
>in the change management system.  In your case, since it was a known issue, 
>I'd have you simply enter the appropriate override on the ChangeMan or 
>Endevor panel.  It remains associated with your program from then on.

I agree.   I created a program that I could call to return IDMS
db-keys which are stored in numbers bigger than standard CoBOL could
read.   In my tests, I could stick the compile parm on top of the
code, but Endevor's compile ignored those.   We had to create a new
Compile type for this program.
0
howard (6282)
9/28/2007 2:32:21 PM
Larry Kahm wrote:
> In various sites, I've seen differences in compile options at different 
> stages.  Sometimes this was deliberate, other times it was based on history. 
> I believe the options should be set once for all levels - and overrides used 
> if at all necessary.
> 
> With ChangeMan, you compile once for the lowest level of the promotion path, 
> and the source and load module are copied (in tandem) through each level of 
> the path.  With Endevor, you compile at each level of the promotion path - 
> and with that comes the risk that the options >may< not be the same.  I 
> believe SCLM handles things the same way that ChangeMan does.  I can't speak 
> for other products.
> 
> One of the aspects of this Enterprise COBOL migration that I want to ensure 
> is that the options are a) reviewed, b) understood in context, and c) 
> standardized across promotion levels.  Because I'm still idealistic, I'd 
> like them to be consistent across applications (but I know better)....
> 
> Larry Kahm
> Heliotropic Systems, Inc.

Just a minor correction.  I work in a shop that uses CA-Endevor to 
manage source code and object code, and Endevor can be configured 
either to recompile every time a program is promoted to a new 
environment/stage, or to be compiled only once when it is first added. 
  Our sysprogs chose to compile once and promote source and executable 
without recompiling.  This guarantees that the code installed is the 
code that was actually tested.

It's also possible to configure Endevor to either allow or prohibit 
PROCESS/CBL compile time options.  It is also normal with Endevor to 
create multiple compile templates, for example to support plain batch 
COBOL compiles, batch COBOL with DB2 compiles, COBOL CICS compiles, 
COBOL CICS with DB2 compiles, et cetera.  So even if PROCESS/CBL is 
prohibited, you can create a unique compile processor that enforces a 
different set of compile time options for special cases (compile with 
only production copybooks instead of development copybooks).  We also 
use it to manage assembler, JCL, proc, easytrieve, and runtime 
documentation.

Endevor is a large and flexible tool.  Our biggest problem with it is 
managing concurrent or parallel development.  If a production program 
needs an emergency fix we can do it, jumping over in-flight 
development, but the code change must then be manually retrofitted to 
multiple in-flight versions for various product releases.  Much of 
that problem is bureaucratic red tape.

And no, I do not work for CA.  Naturally, Endevor was written by 
someone else before CA acquired it.

With kindest regards,


-- 
http://arnold.trembley.home.att.net/
0
9/28/2007 6:07:04 PM
On Fri, 28 Sep 2007 18:07:04 GMT, Arnold Trembley <arnold.trembley@worldnet.att.net>
wrote:


>Endevor is a large and flexible tool.  Our biggest problem with it is 
>managing concurrent or parallel development. 

CVS and Subversion (both open source) are excellent for concurrent development. In normal
mode, checked out files are not locked. On checkin, the file is not replaced, changes are
merged into it. 

Most major VCSs offer merging as an option, but corporate users almost always turn it off
under the mistaken belief that software can't possibly be smart enough to merge code
without error. The genius of CVS is that you CANNOT turn it off (there actually is a way,
but the admin won't tell you about it). Subversion (SVN) does permit locks because it
supports a wider variety of file types, with MIME links to merge and compare programs. 

> If a production program 
>needs an emergency fix we can do it, jumping over in-flight 
>development, but the code change must then be manually retrofitted to 
>multiple in-flight versions for various product releases.  Much of 
>that problem is bureaucratic red tape.

Moving changes upstream is one of the more difficult problems in change management. It is
very common for production and QA  fixes to be overwritten by the next release. 

When the mentality is merging rather than replacing, it's EASY to mechanically merge
changes into upstream releases. It is best overseen by a change management administrator
because none of the other players have an incentive. Waterfall methodologies don't deal
with it because they hate to admit there are errors in production code. 




0
Robert
9/29/2007 1:35:37 AM
In article <oo8rf35kntemgvluc6jrcvjeuu34n4gg4m@4ax.com>,
Robert  <no@e.mail> wrote:

[snip]

>Waterfall methodologies don't deal
>with it because they hate to admit there are errors in production code. 

I've seen human beings admit to, deny, hate and love things (or at least 
say that they do)... but never a methodology.  Our experiences must be 
different; I have never worked on a system where someone, somewhere does 
not claim that code in Prod is error-free; the best is usually 'It's been 
running smoothly since we corrected for the last unexpected set of 
conditions.'

DD

0
docdwarf (6044)
9/29/2007 1:09:15 PM
Reply: