Home > Archive > Cobol > September 2007 > IBM's CCCA and customized LCPs for Enterprise COBOL migration
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IBM's CCCA and customized LCPs for Enterprise COBOL migration
|
|
| Larry Kahm 2007-09-26, 7:55 am |
| 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.
| |
| William M. Klein 2007-09-26, 7:55 am |
| 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.
>
>
| |
| Larry Kahm 2007-09-27, 6:55 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...
>
>
| |
| Frank Swarbrick 2007-09-27, 6:55 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
| |
| Larry Kahm 2007-09-27, 6:55 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...
> Larry
> Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
>
> 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
>
| |
| Frank Swarbrick 2007-09-27, 9:55 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
| |
| Larry Kahm 2007-09-28, 6:55 pm |
| 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...
> Larry
> Kahm<lkahm@nospam_heliotropicsystems.com> wrote:
>
>
> 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
>
>
>
| |
| Howard Brazee 2007-09-28, 6:55 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.
| |
| Arnold Trembley 2007-09-28, 6:55 pm |
| In-Reply-To: <_F7Li.1691$jC5.166@trnddc04>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 55
Message-ID: <cpbLi.148622$ax1.125221@bgtnsc05-news.ops.worldnet.att.net>
NNTP-Posting-Host: ed27456996218d88faccdf257efa384e
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 1191002824 ed27456996218d88faccdf257efa384e (Fri, 28 Sep 2007 18:07:04 GMT)
NNTP-Posting-Date: Fri, 28 Sep 2007 18:07:04 GMT
Organization: AT&T Worldnet
Date: Fri, 28 Sep 2007 18:07:04 GMT
Bytes: 4009
X-Original-Bytes: 3966
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:168810
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/
| |
| Robert 2007-09-28, 9:55 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.
| |
|
| 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
|
|
|
|
|