gnubol: Re: File I/O proposal

[Matthew Vanecek <linuxguy@directlink.net>]

Usually I write *after* the message, but I included everything here,
so...

We should not forget the gnu-cobol list, either.  

Alrighty, then.  So the TC RTS is under the LGPL, which is good.  I
could read the code, makefiles, etc., but if you happen to know off the
top of your head which source code files are under that license, I would
appreciate it.  Would it be everything in the lib/ directory?  Some of
the source code do not contain copyright or license statements, is the
main reason I ask, and I don't want to step on anyone's toes, with
respect to licensing issues.

Also, I am probably going to rape, pillage, and otherwise mutilate what
y'all have done, as far as runtime goes.  And of course it's a two way
street, so when I've actually done something useful myself.... ;)

My first task is to write the parser statements.  That will probably
take a little while, because I'm also trying to get up to speed on Tim's
whole layout and intent, as well, and working, and seeing the occasional
movie, and... oh, well, nevermind.  Anyhow, when I've got the parser
portion merged in, that will give me a foundation for coding, and a
clearer sense of the direction I want to take the library in. I'll
probably end up doing a flow chart of some sort (well, I *am* a cobol
program--umm, analyst, in a corporation, dammit!! ;)/

Anyhow, for stuff that we may have in common, we should try to include
both lists in the discussion--more viewpoints, wider base of experience,
etc.

ciao
MV

Tim Josling wrote:
> 
> David,
> 
> Yes I am able to respond to emails during my assignment.
> 
> You are right that there is little room for wasted resources. So
> we should work together. For the same reason the Extreme
> Programming motto 'you aint gonna need it' applies. Let;s now
> boil the ocean right away. I would put MVS into the 'later'
> basket. Big endian though is real. This is tied in with the whole
> mess of all the dialects and all the comp-x formats. I was not
> planning to support non-native binary right away. My thinking was
> that we will have a set of all the formats we will support,
> called comp-701, 702 etc. Then we map these into comp, comp-1 etc
> based on the dialect we are supporting.
> 
> What I am working on is a DBaseIII+ to Java converter. So I need
> some distractions.
> 
> I agree with just about all you are saying. We should look into a
> detailed design and go forward.
> 
> I took the liberty of sending this to the TC mailing list.
> 
> I think I will take you up on the offer of assistance with
> sourceforge setup. I will email you directly.
> 
> Tim Josling
> 
> David Essex wrote:
> >
> > Hi All,
> >
> > Tim Josling wrote:
> > >
> > > Compiler
> > > ********
> > >
> > > On the core compiler the two approaches are indeed different
> > >
> > > - X86 vs cross platform
> > > - RYO code generation vs GCC back end
> > > - no use of cobol in the compiler vs intended use of cobol in the
> > >   compiler
> > > - less vs more pedantic approach to standards compliance and
> > >   related issues
> > >
> > > Ultimately the market/users will decide which is the better
> > > approach. You are right there is little scope for sharing of code
> > > on this part.
> >
> > Well, I think there is no question, GCC is the better approach for a
> > multitude of reasons. Rildo and I have discussed the future of TC, in
> > light of your progress with GNU COBOL. For the time being we would like
> > to pursue the TC project and try to get the project to the alpha stage.
> > Of course we would like share our code when ever possible.
> >
> > > But... IMO we should though try to make our binary interfaces
> > > (ABI)s compatible, and I would like to discuss this further. My
> > > objectives in the ABI are:
> > >
> > > - legality - for example they should be able to use any valid
> > > cobol name, such as 'fprintf' as a program.
> > > - compatibility with C - ability to call and be called by C
> > > programs. Due to the naming issue this probably means mapping
> > > Cobol names to upper case, and giving the programmer an option
> > > like
> > >
> > > program-id. fprintf as "gumby". ==> "gumby"
> > >
> > > Whereas
> > >
> > > program-id. fprintf. ==> "FPRINTF". or *maybe* cob_FPRINTF to
> > > avoid namespace clashes if there are any libraries that have
> > > upper case external names in them (agree, it is ugly).
> > >
> > > All the runtime would be prefixed by cobr_ to avoid namespace
> > > clashes (common sense IMO).
> >
> > I agree, to avoid namespace clashes, the runtime should be prefixed by
> > 'cobr_' or what ever.
> >
> >
> >
> > > In cobol 2002 they allow "-" and "_" both, so maybe it woudl be
> > > better to map "-" to "$" and then "_" can stay as "_".
> >
> > I do not think there is any clear way to resolve this issue. Ultimately
> > we are limited to what GNU assembler and C naming conventions are
> > allowed. The character "$" is allowed by AS, but not by C. The character
> > "-" but not allowed by neither.
> >
> > To complicate matters, some platforms add prefixes to function calls.
> > For example GCC for win32, a call to 'printf' will generate an assembler
> > call '_printf'.
> >
> > Anyway, the above solution would resolve the issue within COBOL.
> > Assuming of course that on all platforms, supported by GCC, the
> > character "$" is allowed by AS. As for COBOL to C and C to COBOL calls,
> > the C naming convention would have to be used.
> >
> > > Runtime
> > > *******
> > >
> > > On the runtime, of which I have so far written 0 LOC, I see great
> > > scope for cooperation and I full intended to use/steal TC code. I
> > > fully support cooperation in this regard.
> > >
> > > The main issue is the licencing. As I understand the TC runtime
> > > is GPL which prohibits its use in non-GPL projects. I was
> > > intending to have the Cobol for GCC as LGPL. This is consistent
> > > with how GCC is set up. Even the bison output licence now allows
> > > the output to be used with any licence. Can I suggest tiny Cobol
> > > consider changing the runtime licence to LGPL?
> >
> > The licensing changed to the GPL/Library GPL, the same as GCC, a while
> > back.
> >
> >
> >
> > > Competition
> > > ***********
> > >
> > > Some general thoughts on cooperation and competition...
> > >
> > > In free software, competition has fewer downsides than in the
> > > commercial world due to the ability to reuse code written by
> > > competitors, as long as the licences are compatible. Competition
> > > has some advantages, too, for example it drives people to do
> > > better in order to 'win'.
> > >
> > > Cooperating with people who don't know what they are doing, who
> > > do not actually deliver anything, or who are disruptive can be
> > > counter-productive. No-one in the list for this email would be in
> > > those categories. But sometimes it is necessary to do a code fork
> > > or split efforts.
> > >
> > > So the the extent we can cooperate productively, go for it.
> >
> > Yes, competition can advantageous. However it is been our experience
> > that in a COBOL compiler project, the number of volunteers which are
> > willing and able to do the task are very limited. And since the task at
> > hand is rather large, cooperation, in my view, is the best approach.
> >
> > I agree, cooperating with people is not always easy. In my experience,
> > every programmer has is/her way of doing things, with a wide diversity
> > of results. So my approach has been to let the programmer do his/her
> > thing, and not to be critical of their work.
> >
> > Of course there will always be problems, people lose interest, or do
> > not deliver desired results. But then again what programming project,
> > free or commercial, as not had the same problems.
> >
> > Anyway, I suspect the main limiting factor in our ability to 'cooperate
> > productively', will be technical issues.
> >
> > > One minor technical issue. When the user wants to do static
> > > linking, then the structure of the runtime greatly affects the
> > > executable size. So if you have a routine called "file" that then
> > > calls the IO routines for the type of IO going on, you would drag
> > > in all the code for every file type. So I would suggest you look
> > > at having routines like 'open_indexed', 'read_line_sequential'
> > > etc.
> >
> > Yes, we could use different calls for different type of files. In TC,our
> > current approach is to have one call, along with a file description
> > pointer. Your approach would eliminate the need to  determine the file
> > type in the RTS.
> >
> > Yes static linking of the COBOL RTS library, will have some overhead, IO
> > structures specifically. However linkage will not require other
> > libraries if not used. For example in TC, if is no file IO is used in
> > the COBOL program, then libdb is not  required by the linker.
> >
> > Using dynamic linking for the COBOL RTS library on the other hand
> > produces a smaller binary, but the linkage requires that all libraries,
> > whether used in the COBOL program or not. Not a optimal situation.
> >
> >
> > > I do not have a good solution for how this works with the
> > > abstraction layer concept, which is a concept I like. When do you
> > > make the decision which type of indexed IO you want to do. It
> > > could be compile, link, or run time. Do you want to mix ISAM and
> > > Btrieve in one program, or in one executable. How would you say
> > > which one you wanted? If it is at compile time then you could
> > > have different but compatible interfaces from the generated code
> > > to every different indexed type. Where there is common code for
> > > the different types they could be subroutines that both variants
> > > call.
> >
> > The basic idea of an abstraction layer is something like SQL's ODBC.
> >
> > Ideally, for indexed file IO, the file type would be determined at run
> > time, and the appropriate libraries would be dynamically loaded. Since
> > COBOL does not support this kind of functionality, perhaps enviromental
> > variable could be used. The RTS library would manage the
> > allocation and deletion of all resources.
> >
> > Also indexed file IO could be placed in a different RTS library, thus
> > avoiding some of the problems with static/dynamic linkage.
> >
> > Anyway, I do not have all the details in place yet.
> >
> >
> > > Even with sequential there are variants also eg line sequential
> > > vs record oriented - and I do not know if Merant and FJ use the
> > > same formats or if their formats have annoying limitations like
> > > 64k record size limits.
> >
> > I think the 64k record size limit you are referring to applies to the
> > mainframe variable length file format (EBCDIC). In this format, no
> > record delimiter is used. A 2 byte field (64k) is used to indicate the
> > length of current record. The start position of the next record can be
> > determined by adding current record position and the current record
> > length + 2. The actual data in the record start at current record
> > position + 2.
> >
> > According the M*rant web page (1), the following file organizations are
> > supported.
> > - Line sequential (Carriage Return/Line Feed delimited)
> > - Sequential - Fixed and variable length
> > - Indexed Sequential - Fixed and variable length
> > - Relative - Fixed and variable length
> > - VRECGEN - Mainframe variable length file format
> > - ANSI Mainframe Report (mainframe print control in col. 1)
> > - PC report format (print control in PC format)
> >
> > These commercial vendors support a multitude of platforms, which in
> > turn require a multitude of formats. For example M*rant supports EBCDIC
> > on a Win32 and U*IX platform.
> >
> > With multi platforms, there are endian issues (i.e. an integer is
> > defined as COMP or COMP-5) to be dealt with. And since one of the GCC
> > target platforms is S390/S370, this will be an issue for GNU COBOL.
> >
> > TC does not currently deal with these issues, since it's only target is
> > Linux i386, and the only file formats supported are as follows.
> > - Line sequential (Fixed Line Feed delimited)
> > - Sequential - Fixed length
> > - Indexed Sequential - Fixed length (variable ?)
> > - Relative - Fixed length (variable ?)
> >
> > So I think the issue here is will GNU COBOL support both ASCII and
> > EBCDIC ? If so, then this should be dealt with in the planning stages.
> >
> > Sorry Matthew, for opening this can of worms. I had forgotten that GCC
> > supported S390.
> >
> >
> >
> > > I think we should go ahead with a common effort, and perhaps
> > > continue the discussion on the technical details in the TC
> > > mailing list, including the details so far. This is a very
> > > positive step IMO.
> >
> > OK. Future e-mails, after this one, will be posted on the TC mailing
> > list.
> >
> > I think we should get something out of this which is mutually
> > beneficial.
> >
> > > BTW I am not going to be writing any code for 6-10 weeks due to
> > > $work$ commitments; also I think I need to take a step back for a
> > > while after one year and think before I write a lot more code. In
> > > the meantime I am working on putting the code up in sourceforge.
> >
> > OK. Will you be able to respond to e-mails ?
> >
> > If you have any questions regarding the setup at sourceforge, Rildo or
> > myself will be glad to help.
> >
> > David
> >
> > 1) Micro Focus COBOL Workbench 3.4
> >    - Detailed Product Information
> >    (sorry lost web link)

-- 
Matthew Vanecek
Visit my Website at http://mysite.directlink.net/linuxguy
For answers type: perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
*****************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.