I asked Joe's permission to respond to his email to the list as well. I
think his perspectives will benefit all.
Hi Joe
Thanks for answering my post.
So maybe I shouldn't have framed this as mainframe vs desktop. There are
many Unixes. A better way perhaps should have been Desktop vs other
hardware.
About the standards thing... I have heard others say this too, so adding
non standard stuff to the core would like spark a holy war.
My main concern with GNUcobol is that there are hardly any libraries and
what's worse is that there are very limited mechanisms to even build a
library. How likely is it that someone would be able to generate a new
codebase that is deployed as a TUI and still charge decent money for
it? My
main focus is not supporting old code so that a company can limp along
with
it for a few more years, I love Cobol and I want to write new code.
As-is,
it is not presentable in my industry and is not financially viable for
commercial work.
If anything that needs to be added, needs to be in the standard first
then
the project is going to be severely stunted, that is, "IF", the main
mechanism that code sharing takes place is contributions to the core
language itself.
Library code on the other hand can be used or not used and there is
nothing to war over.
I have all sorts of half-baked ideas and I am throwing most of them in
the
garbage myself as I learn more but some may have value and I will post
them
in separate threads to keep this one tidy though.
I would also like to mention that I can't even prototype a half-baked
idea with the current codebase, it's overwhelming for me.
There are lots of features in the standard that are not implemented and
we
have also moved outside the standard before with the level 66 constant
and
we haven't yet talked about expanding test harnesses or debugging
existing
code.
If the codebase was easier to manage, more people could contribute and
the
project would be more a viable alternative to microfocus. The actual
number
of lines of code is not that much but it's scary to touch it when it's
so
cross architecture.
Finally, if no one is posting to the list, that doesn't mean that no one
is gaining benefit from the project but if more people could
contribute, we
might have more posts and more ideas would emerge.
-Patrick
On 24/02/14 12:35 PM, Ron Norman wrote:
Hi Patrick,
I have done a small bit of work on OpenCOBOL (ISAM file support and
recently REPORT WRITER) but due to my work I have access to half a dozen
different versions of Unix systems so I can verify the code changes
work on
at least some different platforms. But I have no access to any mainframe
systems.
I have training in compiler construction and worked on a commercial
COBOL
compiler in the past.
COBOL is very standards based so if/when adding feature FOO you need to
make sure that FOO is part of the ANSI/CODASYL standard for COBOL.
If feature FOO is not a missing feature that is documented then I would
think that it should not be added to OpenCOBOL/GNUcobol.
The very nice feature of COBOL is that it is standards based and as
people move their COBOL applications from system to system they will
continue to work.
Just my view of things...
On Mon, Feb 24, 2014 at 6:51 AM, Patrick
<address@hidden>wrote:
Hi Everyone
Day and night, my time is not my own(awake 4.5 hours last night). I
can't promise to contribute anything to the project but I can say that
I
really want to and I have been trying.
I have read/am reading, books on Ncurses, Bison/Flex, Autotools and now
DB. Little by little I am starting to understand how things work but I
may still have as much as a year more to go at this pace.
I thought I would post a proposal and check if some facts I am
operating
on are correct.
My facts:
1)Open Cobol goes back to 2001 and tinycobol precedes this.
2)Brian Understands the codebase
3)Sergey is making commits now
4)Joe has a fileio commit waiting for approval
5)There is a person(s) in Japan working on the code now but they are
not
putting their name on it
6)> 99% of the code has been written by Keisuke and Roger
Is it fair to say that everyone that has committed code to the project
has access to a mainframe?
Is it fair to say that in the 13+ years of development < 10 people have
contributed code?
I repair circuit boards for a living and service spectrometers. If I am
intimidated with a codebase, it could easily be because I don't have
enough programming experience but it seems to me that this codebase is
very difficult for people to contribute to. It seems to me that there
is
a lot of platform correction code and most of us don't have access to
many of the platforms.
If I want to add feature FOO how do I ensure it will work on an
architecture I will never have access to?
What if we created a branch and simplified the codebase? I would be
willing to try this, although I may never get the time to finish.
The main codebase could continue, the mainframe guys could take code as
they see fit and the desktop people could work away. Sure the two could
get out of sequence but at the pace things are moving at right now,
would that really be such a big deal?
-Patrick
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
--
Cheers
Ron Norman