Patrick,
It
does seem that there are no posts from me about OpenCOBOL and CGI to
speak of.
More
particularly, we use OpenCOBOL to write web applications both on linux
and windows boxes. We use Apache. We ended up porting our own handler
from the HP3000 to allow us to use OpenCOBOL. The handler replaces the
tedium of parsing the data flow into and out of the web server. It
requires some learning but has made writing web pages a lot faster for
us. The HTML is separated from the program code, thus making the
programming easier.
We
also have a version of the CGI programs that handle statefull work on
linux boxes since the nature of the web is normally stateless.
If
you get to the point where you understand OpenCOBOL and want to proceed
with enabling web applications with it, I will be happy to show you
what we have. It will take some work, so while I don't mind walking
you through it I don't want to spend the time unless you are
committed. I don't mean to sound grumpy, but I have dealt with too
many people on the forum that want the solution to be totally
automatic. As you know, programming takes work.
Let
me know if I can help. I plan to be in the mountains this weekend and
may not be prompt with my replies.
jimc
-----Original Message-----
From: Patrick <address@hidden>
To: open-cobol-list <address@hidden>
Sent: Fri, Mar 8, 2013 10:39 am
Subject: Re: [open-cobol-list] Web server resources etc?
Hi Brian, Hi Jim, Hello Fred and Hello Robert :)
I have received great help on and off list with this, thanks!
I read through the forums for a couple hours last night trying to piece
things together. It looks like Jim has been super generous in the past
with providing a kick ass server to support development.
I found some code related to interfacing with mysql.
However I am still mixed up though about what a other peoples Cobol "web
stacks" look like.
For instance has anyone written a Mod Cobol module for Apache?
Or Is Cobol being used as another layer on top of a framework like Rails?
My problem domain is very strange and would take too much time to read
in detail about but in a nutshell:
I have been servicing scientific instruments for 14 years. I can figure
out what command the instruments will respond to without the help of the
original manufacturer. I have been trying to come up with many
strategies to provide software to labs to control their instruments and
process data but there are many problems in coming up with the right
model to do this and I have been struggling on and off for years.
I am now thinking about proving a pay-per-command code
generating/emitting website that will emit code(probably a dynamic
language) the labs can use to control their instruments locally. The
price would vary depending on how much of the instruments "command set"
was needed. They would input their scientific method into the website in
order to come up with this information for the program and billing system.
Everything can be open source this way but I will also me able to retain
some of the unused commands from the "command sets" the customers didn't
need to pay for, slowing down potential competitors who won't have
complete sets.
So I can do this is a variety of ways and I am open to working in ways
that will help the community. I am pretty poor right now but I can also
throw everything I have at this, there is a huge market and I have been
struggling to capitalize on it.
What sort of stack is being used and what would work best for everyone?
It looks like Hitachi uses Cobol with Java. I don't know any Java but I
could learn. Would "piggy-backing" on a Java framework be good what
about something more dynamics like Python or Ruby?
If Mod Cobol is needed, could I write this cased on Mod C ?
Any feedback or guidance is appreciated.
I am in some trouble and have to focus on adverting an audit and have
bunch of orders to ship, I might be slow responding but I am very
excited about this-Patrick
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list