Expressions of interest in a Remote COBOL server, please?
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 30 Sep 2007 17:13:06 +1300
A little while back, I asked here if anybody had any scripts for running
batch COBOL on client/server. There were some very good responses, but most
of them were using DOS batch files and I really want to move away from that.
Richard pointed out that using MAKE would be a better solution, and I
agree.
As time has moved on, this problem has percolated up my list of priorities
and it is now fairly high. I have therefore been applying myself to getting
a good solution.
As I investigated it, it occurred to me that I have one machine (PetesP4) on
my WLAN that has Fujitsu COBOL installed on it. Because of their stupid
Licensing (one of the nails in their coffin as far as I am concerned) I
can't simply buy the software and install it on a couple of machines. It has
to go through a whole rigmarole of notifying their server that the license
is being transferred to another machine, transferring it out to a floppy
(!... do they even exist any more? I tried it with a memory stick and I
think it worked; so long ago I can't remember...), killing it on the old
machine and transferring it in from the floppy to the new machine. Yes, I
can understand sane people getting a bit annoyed about paying several
thousand dollars to be put through hoops. As a result of all this nonsense,
I resolved NOT to install COBOL on the Vaio machine (Bigblack) (It is a C#
VS 2005 platform with occasional VB and Java). All of my current development
is on Bigblack, but part of that development is generating COBOL code,
which, of course, must be compiled (there can be a number of programs
generated, so it needs to do a batch compile).
So, the problem comes down to: "How can I get my source programs on Bigblack
across to the COBOL machine, PetesP4, batch compile them, and get the
executables back to Bigblack so they can be run?"
There are a number of scripting options available under Windows (Scripting
serves a similar purpose to JCL in mainframe environments) and my favourite
is Windows Script Hosting. The customer is running in a Windows environment
so the necessary support for WSH scripting is already installed.
I transferred the COBOL sources from Bigblack to PetesP4 and knocked up a
quick batch compile script (WSH) and ran it locally on PetesP4. It worked
fine and used NMAKE to build and run the COBOL programs. The good thing
about this is that if you rerun it, it does no harm. Because it is using
NMAKE, it detects the build state of each program and only compiles them if
the COBOL source or options have changed. Good stuff. There is no
requirement to set up a project for each (or any) of the COBOL Programs. All
you need is the COBOL source and a couple of ancilliary files which I
generate from C# at the time I generate the COBOL program, (one of which
contains the compiler options and the other has path and build information
in it. They are standard templates and I just run a C# RegEx to replace the
program name at various places in them. )
The next step is to be able to remotely invoke this Script from BigBlack,
after having generated the sources directly to PetesP4. (easy... map to a
shared drive on PetesP4 before generating)... it turns out that WSH 5.6
DOES include remote scripting, so I got stuck into it.
It was a nightmare :-). Instantiating remote objects that actually monitor
what is really going on and provide status etc. And it uses COM+ as the
transport layer. (Fortunately, I've had a number of years experience writing
COM components; without it, it would just be a jungle for newbies...) After
two days fiddling with COM permissions, impersonations, authentications, and
still getting "Access denied" every time I tried to run it, I was ready to
look for "another way".
Then a light came on and I thought "Why not write a server that can run on
PetesP4 and accept COBOL compile requests from any machine on the network?"
It would be like having COBOL on every machine... It could run over sockets
without needing COM or scripting, and could use TCP/IP as a transport. Any
machine that wanted to compile COBOL would simply pass the details to a
small client program that would connect to the remote COBOL server, do the
biz, and get the executable returned to it. The COBOL server could be
asynchronous and able to service multiple requests.
In the meantime, I solved the problems with the scripting solution (it
involved a couple of Registry hacks; how often have we heard that before
with Windows? :-)) and my WSH solution is now working perfectly.
I estimate the work on writing the remote COBOL server to be a couple of
days.
Although I'm quite keen to do it (it is an interesting C# exercise), I can't
really justify doing it, as I already have a working scripting solution
(which I'll gladly share publicly here with anyone interested, as I promised
at the time).
However, if other people could use such a COBOL Server solution, I'd have
another look at it.
Comments?
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Prev by Date: Re: [OT] Iraq
- Next by Date: How proprietary is the "COBOL file system"
- Previous by thread: [OT] Do you have a Knowledge Officer?
- Next by thread: How proprietary is the "COBOL file system"
- Index(es):
Relevant Pages
|
