Re: gnubol: Re: Cobol Compiler Suggested Tasks

[Matthew Vanecek <linuxguy@directlink.net>]

Tim Josling wrote:
> 
> I have defined nothing about the interface to the file IO. Come
> up with a rought first cut and we will go
> from there.

I should have a working idea, if not some code, in his time frame. 
There will be a lot of similarities in the different types of I/O--I
think the main differences lay in the way in which the data is
physically accessed (i.e., just get the next record, or fseek to a
certain position, or whatever), so we should be able to reuse a lot of
code.

> 
> I guess you would be passed some kind of file handle, an
> operation code (read write etc) and any data you need. I think
> with read there is a complexity...
> 
> If you say "read file-01" then the record read from the file is
> in effect available to all the 01 records in the FD for that
> file, regardless of length. There is no space filling or
> truncation. If you say read file-01 into rec-01 then it also gets
> copied into rec-01 and truncated or space filled as needed.
> 
> I think probably the code generated by the compiler should do the
> move truncate etc, so your interface for a read may look like
> this
> 
> cobr_read(file_handle, char** record_ptr_address, int * length,
> int * status_info)
> 
> (or it may not, that it completely off the top of my head. I have
> not even read the standard on file IO - defintiely worth doign
> before coding). Probably also need some more diagnostic
> infomation for when things go wrong.
> 
> As you see I like to keep it simple.

Simple is good. :)  The standard isn't much help, with regard to
mechanics. It's pretty good at describing the expected behavior, but I
think the implementation is up to us.  As long as the code generates the
correct behavior...
The MF System Reference has a pretty decent section on file handling.

> Rich Sahlender wrote:
> >
> > Thanks Tim, this is great. What are your schedule expectations
> > for this? I will be busy moving out of a rental house and into
> > a motel by the end of this month, and then out of the motel
> > and into our new house in mid to late June. I will have some
> > time to work on this, but I will be limited by the moves for the
> > next 6 weeks or so. After we're in the new house later in June
> > I'll be able to work more seriously on this. Is this okay? I
> > sure hope so...
> >
> > I have just a few quick questions for you which may be answered
> > in the detail on your web pages, but I've not yet had a chance
> > to read them. I will do so over the next couple days.
> >
> > On Sun, May 07, 2000 at 04:58:31PM +1000, Tim Josling wrote:
> > >
> > > Rich Sahlender: runtime routine for FILE IO for Random file.
> > > Probably also needs a utility to create such a file.
> > >
> > > 6.Native Packed decimal support (very hard). Contribute patches
> > > to GCC to provide native support for packed decimal arithmetic on
> > > platforms that support it like S/390. Skills required: excellent
> > > knowledge of GCC internals and the target machine codes involved,
> > > excellent C coding skills. Should also be willing to provide
> > > builtin routines for platforms without useful packed decimal
> > > supprort. This is a hard task because the GCC internal structure
> > > assumes oprtations are done with reigsters, which is usually not
> > > the case for packed decimal instructions. An alternative approach
> > > to this problem could be to provide builtin routines for packed
> > > decimal which just happen to include some 'asm' assembler inline
> > > code on certain platforms (you can check for the platform using
> > > #ifdef type contructs)
> > >
> >
> > I would like to help with this but lack some of the skills required
> > to take it fully. I am not familiar with gcc internals, but I am an
> > expert at S/390 assembler and packed decimal operations on the
> > mainframe platform. Has anyone offered to take this yet?
> >

mmmm, S/390 assemblerrrrr.... Always seemed much easier to me than does
x86 assembler, for what little I know, anyhow.  You know how it's
implemetned on the mainframe--it might not be too difficult to port that
to other platforms.  Still, it's too bad we can't get PD builtin to our
assembler. I mean, AP, SAP, SRP, et al...those might be kinda hard to
duplicate without some fancy coding.  How do others do it (like Cobol2c,
Tiny cobol, etc)?

Tim,
I was kindof wondering, how many passes over the code does the parser
do?  Considering some of what you can do in COBOL, we'll need at least 2
passes, or some way to parsing the Data Division first, so that we can
look out data names up in a lookup table.  Have you thought about that
yet or done anything with it?  For instance, in the SELECT ... ASSIGN
clause, it'd be good to be able to lookup the file handle to make sure
it's defined, or to lookup the FILE STATUS data item to make sure it
exists and is of the proper type, etc, etc....

Just something to think about
-- 
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.