Cobol Stored Procedures in DB2 on Windows

[Scott Sauyet]

If this is not the appropriate forum, could someone please let me know?
Thanks.

I'm part of a very heterogeneous distributed development team, and a
clash of cultures is causing some very significant problems. It's
taking us far too long to get the people with the proper permissions to
compile and bind COBOL stored procedures on our MVS DB2 test and
deployment environments. The bureaucratic hurdles to getting these
permissions ourselves have for months been insurmountable, and I
recently had what I hope is a brainstorm. (Maybe it's just a
brain-tropical depression, though. :-) )

I would like to duplicate our database on a local Windows version of
DB2, and compile and bind the COBOL to this instance. Then the
bureacrats can take as long as they like about the deployment
environment, and we can still do our development.

I've found some DB2 documentation [1] that explains how to connect Micro
Focus COBOL and IBM COBOL to DB2. We have an older, unsupported,
version of Micro Focus, but it might do in a pinch. My concern is that
using this involves invoking "nmake", a tool I know nothing about. And
spending the time chasing down and learning a build tool in order to
speed up our development process seems... well, counterproducti ve.

So I was wondering if anyone knew of relatively straightforward ways of
connecting COBOL stored procedures to DB2 inside Windows; any free or
inexpensive COBOL compiler is okay, but I'd love to use an open-source
one if possible. We are running DB2 UDB v7.

Thanks for any help you can offer.

-- Scott Sauyet, sc***@sauyet.co m

[1] http://tinyurl.com/2hy6u
https://aurora.vcu.edu/db2help/db2ax/frame3.htm#embed
and many similar pages

[Larry Menard]

You don't need "nmake". Look in "\sqllib\sample s\cobol_mf", and you will
see two batch files: "bldapp.bat " and "bldrtn.bat ". In there you will find
the commands used to build the application and SP respectively). You could
just lift the compile & link commands right out of these scripts.

As for whether or not your current version of MF COBOL is sufficient, or
if another COBOL compiler will work, I'm afraid I don't know. Ya pays yer
dollar and ya takes yer chances...

--
Larry Menard
IBM Workstation Database (DB2) Information Development, Samples Coordinator
Defender of Geese and of All Things Natural
"Scott Sauyet" <sc***@sauyet.c om> wrote in message
news:e5******** *************** ***@posting.goo gle.com...

If this is not the appropriate forum, could someone please let me know?
Thanks.

I'm part of a very heterogeneous distributed development team, and a
clash of cultures is causing some very significant problems. It's
taking us far too long to get the people with the proper permissions to
compile and bind COBOL stored procedures on our MVS DB2 test and
deployment environments. The bureaucratic hurdles to getting these
permissions ourselves have for months been insurmountable, and I
recently had what I hope is a brainstorm. (Maybe it's just a
brain-tropical depression, though. :-) )

I would like to duplicate our database on a local Windows version of
DB2, and compile and bind the COBOL to this instance. Then the
bureacrats can take as long as they like about the deployment
environment, and we can still do our development.

I've found some DB2 documentation [1] that explains how to connect Micro
Focus COBOL and IBM COBOL to DB2. We have an older, unsupported,
version of Micro Focus, but it might do in a pinch. My concern is that
using this involves invoking "nmake", a tool I know nothing about. And
spending the time chasing down and learning a build tool in order to
speed up our development process seems... well, counterproducti ve.

So I was wondering if anyone knew of relatively straightforward ways of
connecting COBOL stored procedures to DB2 inside Windows; any free or
inexpensive COBOL compiler is okay, but I'd love to use an open-source
one if possible. We are running DB2 UDB v7.

Thanks for any help you can offer.

-- Scott Sauyet, sc***@sauyet.co m

[1] http://tinyurl.com/2hy6u
https://aurora.vcu.edu/db2help/db2ax/frame3.htm#embed
and many similar pages

[Scott Sauyet]

"Larry Menard" <lm*****@GoSpam Yourself.com> wrote in message news:<bu******* ***@hanover.tor olab.ibm.com>.. .

You don't need "nmake". Look in "\sqllib\sample s\cobol_mf", and you will
see two batch files: "bldapp.bat " and "bldrtn.bat ". In there you will find
the commands used to build the application and SP respectively). You could
just lift the compile & link commands right out of these scripts.
Thanks for the response. I've been sidetracked on other productions
issues since I wrote that, but will get back to it next week. That
certainly looks straightforward though.
As for whether or not your current version of MF COBOL is sufficient, or
if another COBOL compiler will work, I'm afraid I don't know. Ya pays yer
dollar and ya takes yer chances...

Yeah, but I'm hoping not to pay any additional dollars. :-)

Thanks again,

-- Scott

[Gert van der Kooij]

In article <e5************ **************@ posting.google. com>, Scott
Sauyet (sc***@sauyet.c om) says...

"Larry Menard" <lm*****@GoSpam Yourself.com> wrote in message news:<bu******* ***@hanover.tor olab.ibm.com>.. .

You don't need "nmake". Look in "\sqllib\sample s\cobol_mf", and you will
see two batch files: "bldapp.bat " and "bldrtn.bat ". In there you will find
the commands used to build the application and SP respectively). You could
just lift the compile & link commands right out of these scripts.

Thanks for the response. I've been sidetracked on other productions
issues since I wrote that, but will get back to it next week. That
certainly looks straightforward though.

As for whether or not your current version of MF COBOL is sufficient, or
if another COBOL compiler will work, I'm afraid I don't know. Ya pays yer
dollar and ya takes yer chances...

Yeah, but I'm hoping not to pay any additional dollars. :-)

Thanks again,

-- Scott

What DB2 version and MF Cobol version do you have?
We are running with DB2 V7.2.4 and MFCobol 4.... on NT 4.0.
You need an updated utils.lbr from MF if you want to specify the
user/password during compile. The MF helpdesk should now about it.

[Scott Sauyet]

> == Gert van der Kooij <ge**@invalid.n l>
in news:<MP******* *************** **@news.xs4all. nl>

What DB2 version and MF Cobol version do you have?
We are running with DB2 V7.2.4 and MFCobol 4.... on NT 4.0.
You need an updated utils.lbr from MF if you want to specify the
user/password during compile. The MF helpdesk should now about it.

We are using DB2 7.2.something and MFCobol 4.0.32. Several members
of my team have started trying this, and though we haven't worked
out the kinks, it looks like we'll be able to do it. I will look
at the MF helpdesk.

Thank you very much for your help,

-- Scott Sauyet, sc***@sauyet.co m

[Doug]

sc***@sauyet.co m (Scott Sauyet) wrote in message news:<e5******* *************** ****@posting.go ogle.com>...

== Gert van der Kooij <ge**@invalid.n l>

in news:<MP******* *************** **@news.xs4all. nl>

What DB2 version and MF Cobol version do you have?
We are running with DB2 V7.2.4 and MFCobol 4.... on NT 4.0.
You need an updated utils.lbr from MF if you want to specify the
user/password during compile. The MF helpdesk should now about it.

We are using DB2 7.2.something and MFCobol 4.0.32. Several members
of my team have started trying this, and though we haven't worked
out the kinks, it looks like we'll be able to do it. I will look
at the MF helpdesk.

Thank you very much for your help,

-- Scott Sauyet, sc***@sauyet.co m

Scott
We have it working very well. If you need help please email me.