Re: [open-cobol-list] newbie alert : cobol : 85 : data management, : question

[Mayuresh Kathe]

On Wed, Nov 05, 2014 at 09:26:19PM +0100, Simon Sobisch wrote:
> > Date: Sat, 01 Nov 2014 09:44:35 -0400
> > From: Patrick <address@hidden>
> > Subject: Re: [open-cobol-list] open-cobol : full 85 support : bounty
> >     ...
> > To: address@hidden, address@hidden
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=windows-1252; format=flowed
> >
> > On 14-10-31 12:43 PM, Mayuresh Kathe wrote:
> >> hello,
> >>
> >> i am initiating a personal project to improve conditions in rural india
> >> by effecting social change via technology.
> >> for the same, i have chosen to go ahead with cobol-85 due to it's
> >> impressive record-oriented data manipulation abilities.
> >>
> >> it being a self-funded effort, i can't afford to go for big iron stuff
> >> from ibm, etc.
> >> hence, i would prefer to go with open-cobol running under a highly
> >> modified linux system.
> >>
> >> i have come to realize that open-cobol does not yet have full support
> >> for the cobol-85 standard.
> >> who be the right person to communicate with regarding raising a bounty
> >> to bring in full cobol-85 support to open-cobol?
> >>
> >> do write back at the earliest.
> >>
> >> i am travelling and hence have intermittent network access, please do
> >> not feel let down if i don't respond immediately, will do so as soon as
> >> i get back to my operating base in bombay.
> >>
> >> best regards,
> >>
> >> ~mayuresh
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> open-cobol-list mailing list
> >> address@hidden
> >> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
> >>
> > Hi Mayuresh
> >
> > I think this is going to be tough. Brian Tiffin is our team leader and 
> > Simon Sobisch is is our lead developer but I don't think either really 
> > gets involved with money much. Perhaps you could explain what 85 
> > features are missing and why they need to be implemented? If you were 
> > able to fund the addition of these that would be great but maybe if you 
> > could make a case for them they could be included without cost.
> >
> > Life is absolutely crushing me right now and I can't get this done but I 
> > have been planning on driving down the street to IBM to ask if there was 
> > a way for them to back our project. It looks like they try to get people 
> > interested in microfocus which comes with about a $5K + price tag. Our 
> > project could get people trained in Cobol much faster and if we agreed 
> > to default to the IBM dialect maybe they would fund us.
> >
> > -Patrick
> >
> > P.S my wife is from the Philippines, I am curious how Cobol could be 
> > used to improves lives in rural underdeveloped places
> >
> > P.P.S We have had a recent name change and now we are GnuCOBOL
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 5 Nov 2014 09:19:45 +0530
> > From: Mayuresh Kathe <address@hidden>
> > Subject: [open-cobol-list] newbie alert : cobol : 85 : data management
> >     :       question
> > To: address@hidden
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=us-ascii
> >
> > hello,
> >
> > how does cobol, and by virtue of it's standards adherence,
> > open-cobol, manage data?
> >
> > as i'd mentioned in a previous email, i am working on a
> > self-funded project to use modern computing systems for
> > initiating and sustaining social change in rural india.
> >
> > i had been to one of the regions i intend to adopt for the
> > pilot, and have found the following needs;
> > 1. land record management,
> > 2. population record management,
> > 3. medical history management,
> > 4. criminal record management,
> > 5. produce transaction management.
> >
> > how would i be able to apply cobol-85 to bring this to
> > fruition?
> > i definitely do not wish to use an 'rdbms', and certainly
> > cannot afford a mainframe.
> > is there any mechanism within open-cobol which would
> > facilitate record management using in-memory datasets,
> > which i believe are more efficient than approaching the
> > disk for every request.
> >
> > hope my questions are on target per the agenda of this list.
> > else, i apologize for the deviation.
> >
> > best regards,
> >
> > ~mayuresh
> 
> Hi Mayuresh,
> 
> I think the first question would be what you need - GnuCOBOL implements
> enough of COBOL 85 for most older sources and if you going to (re-)write
> COBOL sources the newer elements from 2002 and 2014 would only do good.
> GnuCOBOL supports ISAM file access (ORGANIZATION IS INDEXED) which is
> quite fast, even with lots of data (GnuCOBOL 2.1 / 2.2 may get a new
> ISAM: backend Lightning DB which likely makes it even faster) if you
> give it the right key definitions (and use them).
> If you want fast access and the data is not too big you could use OCCURS
> and with 2002 features you can use SORT table and afterwards SEARCH ALL
> - you can't access data much faster.
> 
> I'd suggest to just give GnuCOBOL a try as I'm sure there is no free
> COBOL implementation with that big user base and that much support for
> the different standards and dialects.
> Try to use the discussion boards, too (if you don't need the mailing
> list because of mail-only-access).
> 
> If you realize there's something missing you can always tweak
> cobc/libcob and support patches that will likely be accepted (maybe with
> some modification but you'll get what you need). If you cannot do this
> on your own ask at the discussion boards / mailing list or get a
> programmer doing this work.
> 
> *Someone* may be available to tweak cobc/libcob for hire from May 2015
> on :-)
> But as said before, you don't have to wait, just start and ask where
> you're stuck.
> 
> Simon

hello simon,

thanks for responding with the details.

i am not going to use any old(er) sources for anything in my project.
it's going to be a from scratch implementation of the entire system.

why i got so intrigued by cobol? because of what i read about it's
record-oriented data handling capabilities.

why gnucobol? because i simply cannot afford anything else.

why my naive questions to the list?
because, while i have close to 23 years of programming experience, i
know next to nothing about cobol.
for the same, i'll be self-training using a book by mr. coughlan which
relies on cobol-85 heavily, hence my need to have full cobol-85 support
in gnucobol to prevent any disruption during the training and while 
implmenting my system.

i have been informed about the full cobol-85 compliance in the upcoming
2.x release, so will look forward to the same being made available under
my prefered platform, i.e. ubuntu desktop. :)

thanks again for the information.

~mayuresh