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, counterproductive.

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, scott@sauyet.com

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

You don't need "nmake". Look in "\sqllib\samples\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" <scott@sauyet.com> wrote in message
news:e50fabb5.0401190720.3752c3c9@posting.google.c om...
> 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, counterproductive.
>
> 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, scott@sauyet.com
>
> [1] http://tinyurl.com/2hy6u
> https://aurora.vcu.edu/db2help/db2ax/frame3.htm#embed
> and many similar pages

"Larry Menard" <lmenard@GoSpamYourself.com> wrote in message news:<buhkti$n6a$1@hanover.torolab.ibm.com>...
> You don't need "nmake". Look in "\sqllib\samples\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

In article <e50fabb5.0401241853.4c5d4392@posting.google.com >, Scott
Sauyet (scott@sauyet.com) says...
> "Larry Menard" <lmenard@GoSpamYourself.com> wrote in message news:<buhkti$n6a$1@hanover.torolab.ibm.com>...
> > You don't need "nmake". Look in "\sqllib\samples\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.

> == Gert van der Kooij <gert@invalid.nl>
in news:<MPG.1a7de1f62afc756d9896d5@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, scott@sauyet.com

scott@sauyet.com (Scott Sauyet) wrote in message news:<e50fabb5.0401271206.57dd41e6@posting.google. com>...
> > == Gert van der Kooij <gert@invalid.nl>
> in news:<MPG.1a7de1f62afc756d9896d5@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, scott@sauyet.com


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