RE: gnubol: Re: Cobol Compiler Suggested Tasks

["William M. Klein" <wmklein@ix.netcom.com>]

I think - but won't swear to it - that the Micro Focus (aka MERANT) "EXTFH"
file handler is either provided in "open source code" - or that there is
"interface documentation" on what you would need to do if you provide your
own file-handler.

If anyone working on this project (for ANY type of I/O - sequential,
relative, or indexed) could get a hold of either the source or the "interface
definition" - I think that this would probably give you a WONDERFUL "external
definition" of what you will need to provide - to support COBOL I/O.

> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of Tim Josling
> Sent: Thursday, May 11, 2000 4:30 AM
> To: Rich Sahlender
> Cc: gnu-cobol@lusars.net
> Subject: gnubol: Re: Cobol Compiler Suggested Tasks
>
>
> Rich,
>
> On the timing six weeks to start should not be an issue. Anyway
> there is sure to be plenty left to do in six weeks!
>
> The XP apprach to timing is that you normally timebox things. If
> something is not done after the timebox it gets reassigned. At
> some point with lack of progress tasks will get reassigned but
> there will be plenty of warning. Months not weeks anyway at this
> stage.
>
> 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 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.
>
> Feedback on the doco is welcome also,
>
> Don't wreck your back moving!
>
> Tim Josling
>
> 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.
> >
> > I'll assume by Random you mean both Relative and Indexed files.
> >
> > >
> > > For programming tasks, it is a good idea to define the interface
> > > to the program you are writing first. Once we have that agreed,
> > > write the code.
> >
> > Okay... is there enough detail in your web pages for me to know
> > what is available to be passed at the time of open/close
> > read/write etc or do we need to define that as well? As an
> > example, for a "read into" or "write from" will the length and
> > address of the working-storage structure be already available
> > somewhere?
> >
> > >
> > > 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?
> >
> > Thanks and regards,
> > Rich
>
> --
> 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.


--
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.