tiny-cobol-users

Re: [Tiny-cobol-users] Command line input

[Ted R. <te...@ac...>]

> So there is no ANSI standard for accessing the command line.

Interesting thought!  I'll look it up when I get to work.  That is, if
it's in the IBM manual ;->

People:  don't take the following seriously.
Though it sounds authoritative, there are too many errors of fact to give
it any credence.
I'll answer it after I get to work and have the manuals to clear the air.

> I have worked with MVS, DOS/VSE, VM/CMS and I have never seen a LINKAGE
> SECTION in a main program. In MVS, EXEC parms can be read by a COBOL
> program using the ACCEPT statement. 
> 
> As for the concept that any program is a "subroutine" of the OS, while it
> makes some sense, I don't think that is really true. The main and any
> functions(subroutines) are executed in the same process workspace. In UN*X,
> unlike some other OS's, the kernel and user processes don't use the same
> workspace. 
> 
> IMHO, the ability to process the command line, along with environmental
> variables, is a must have in an UN*X environment. Since there is no
> standard, then some extension should be provided in the compiler.  
> 
> Using a LINKAGE SECTION in a main, would create a problem on how to
> distinguish between a main and a sub program. I would be inclined to use a
> CALL or ACCEPT statement. 
> 
> I don't think there is a clean solution to this problem.
> 
> David

Re: [Tiny-cobol-users] Smarter loading of libraries.

[David E. <de...@ar...>]

Hi,

At 01:21 AM 20/12/99 -0200, Rildo Pragana wrote:
>
>I have made some small changes to load libraries only when needed.  There
>is a twofold advantage of this: (1) libraries are not pre-loaded, only when
>explicitly called from a COBOL library function; (2) there is no need to
>add "-llibname" at the makefile (easier to  beginner builders :)  Well,
>I'm just kidding.
> ...
>I hope you agree with me that this is a Good Thing (TM) to have in our
>compiler :)
>
>Comments, please!

I am not sure dynamic loading is a good thing for code generated by a
compiler. Other COBOL compilers I have looked at don't use it. They break
out the run time library onto a main and several smaller libraries. 

Perhaps we should leave it in one main library for the time being.


>BTW, if most of you don't want readline (please read about it first to see
>if it is not interesting to have), it's easy to take it out.  Or a switch
>(Glen?! this is your part) can be inserted to select with/without it.

Do other GNU compilers use readline ? If so keep it, if not remove it.



David

RE: [Tiny-cobol-users] readline

[David E. <de...@ar...>]

At 04:40 PM 19/12/99 -0700, Glen Colbert wrote:

>I found libraries, but no header files.  Even worse, I can't find the
>correct version of header files for the libraries that are loaded.  I'll
>have to build a 2.2 readline library, and hope it can coexist with the 3.0
>libraries which are loaded.
>
>This is probably going to be a worse problem on the Solaris box...

I have the rpm source for 2.0(readline-2.0-10.src.rpm) if any one would
like a copy.


David

Re: [Tiny-cobol-users] Command line input

[David E. <de...@ar...>]

At 08:34 PM 19/12/99 -0800, Ted Rolle wrote:

> David Essex wrote:
>> This does not look right. The above would represent only one of the av[]
>> arguments. And where is the ac argument ?
>
>There is no concept of argc/argv in COBOL.  argc = 2; argv[1] = the
>command line string.

So there is no ANSI standard for accessing the command line.


>> Also a linkage section in a main program ? No, this does not look right at
>> all.
>
>Did it all the time in MVS COBOL.  Going to try it soon in DOS/VSE COBOL.
>
>FWIW, in MVS any program (main included) is a "subroutine" of the
>operating system.  As such it receives a parameter list.  In the case of a
>program called from the operating system, it receives the EXEC parm --
>exactly as I stated it.  I don't know about other COBOL’s.  We can
>implement it any way we want to...that's the beauty of Open Source.

I have worked with MVS, DOS/VSE, VM/CMS and I have never seen a LINKAGE
SECTION in a main program. In MVS, EXEC parms can be read by a COBOL
program using the ACCEPT statement. 

As for the concept that any program is a "subroutine" of the OS, while it
makes some sense, I don't think that is really true. The main and any
functions(subroutines) are executed in the same process workspace. In UN*X,
unlike some other OS's, the kernel and user processes don't use the same
workspace. 

IMHO, the ability to process the command line, along with environmental
variables, is a must have in an UN*X environment. Since there is no
standard, then some extension should be provided in the compiler.  

Using a LINKAGE SECTION in a main, would create a problem on how to
distinguish between a main and a sub program. I would be inclined to use a
CALL or ACCEPT statement. 

I don't think there is a clean solution to this problem.

David

Re: [Tiny-cobol-users] How is our "accept" now.

[Rildo P. <rpr...@ac...>]

Hi Fred,

On Mon, 20 Dec 1999, Fred Mobach wrote:

> It will take some time to prepare this move, but I'll do that. And all submissions
> of my are of course under GPL.

Very good, bravo!
 
>  It's a pleasure to cooperate with you all. It gives a better feeling
> than working for money, although that also has to be done in order to
> feed my wive and 9 children :-).

9 children ???  I have only 2 and almost can't keep feeding them :)
My wife also work (she's a doctor) but we have a modest life.

> I don't know if this compiler will be the real GNU COBOL compiler and I don't
> think that it's interesting to know. If the free software movement can manage to
> produce two COBOL compilers then it's also fine. Just an extra choise, isn't it ?

Well, I don't care too. I do this for pleasure, as I like to write
software tools. I'm a physicist and even after 25 years far from
scientific research, I really have a creative thinking, accepting
challenges and daring to meet the unknown.

regards,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

Re: [Tiny-cobol-users] How is our "accept" now.

[Fred M. <fr...@mo...>]

Rildo Pragana wrote:

> Hi Fred,
>
> On Sun, 19 Dec 1999, Fred Mobach wrote:
>
> > If you're interested in the way we handled this problem just tell me. In that
> > case I will give you a source with the copy members to test. Of course these
> > sources are free, so you can place them in the test suite under the GPL.
>
> That would be a very interesting add-on to our project. Please send it and
> I'll make it included in our releases. (of course if there is no
> restriction to it's distribution under GPL)

It will take some time to prepare this move, but I'll do that. And all submissions
of my are of course under GPL.


> I'm glad to see contributions from many members of our team :)
> Let's make this cobol the real GNU Cobol, as Richard Stallman asked us to.

It's a pleasure to cooperate with you all. It gives a better feeling than working
for money, although that also has to be done in order to feed my wive and 9
children :-).

I don't know if this compiler will be the real GNU COBOL compiler and I don't
think that it's interesting to know. If the free software movement can manage to
produce two COBOL compilers then it's also fine. Just an extra choise, isn't it ?

Regards,

Fred Mobach

Re: [Tiny-cobol-users] Command line input

[Ted R. <te...@ac...>]

> This does not look right. The above would represent only one of the av[]
> arguments. And where is the ac argument ?

There is no concept of argc/argv in COBOL.  argc = 2; argv[1] = the
command line string.

> Also a linkage section in a main program ? No, this does not look right at
> all.

Did it all the time in MVS COBOL.  Going to try it soon in DOS/VSE COBOL.

FWIW, in MVS any program (main included) is a "subroutine" of the
operating system.  As such it receives a parameter list.  In the case of a
program called from the operating system, it receives the EXEC parm --
exactly as I stated it.  I don't know about other COBOLs.  We can
implement it any way we want to...that's the beauty of Open Source.

Re: [Tiny-cobol-users] Command line input

[Boris <bpk...@er...>]

"Rolle, Ted" wrote:

<snip>

> PROCEDURE DIVISION USING PARM-LIST.
>
> In the LINKAGE SECTION:
>
> 01  PARM-LIST.
>     05 PARM-LENGTH       PIC S9(04) COMP SYNC.
>     05 PARM-VALUE        PIC  X(100).
>
> Then in the body of the code:
>
> IF PARM-LENGTH IS GREATER THAN ZERO
>         DISPLAY PARM-VALUE
>         BLAH, BLAH, BLAH, ...
> ELSE
>         DISPLAY 'NO PARMS'
> END-IF

I would think this is actually implementor defined (sorry no manual
here, will check at work).

One of the COBOL's I used didn't have a provision for this at all, it
required a CALL to an API.  Although it was pretty cool.  The os was
called BTOS and all programs and scripts were executed through a user
friendly command line.  If you were to execute program XYZ and had
defined the execution command to the OS as requiring 4 parameters.
Additionally, each parameter could have an unlimited number of sub
parameters (well it was limited by total memory.)  That the first
parameter allowed wild cards and the rest didn't, the OS would set aside
an array in memory that was accessible to the program.  From memory the
area was a variable length array defined something like:

cParams (where the c prefix means count of)
cbRunFileName (or cbParam0) (where the cbPrefix means count of bytes of)

RunFileName
cParams1
cbParam1SubParam1
Param1subParam1
...
cbParam1SubParamN
Param1SubParamN
cParams2
cbParam2SubParam1
Param2SubParam1
...
cbParam2SubParamN
Param2SubParamN

And so forth.  I suppose something like this could be implemented in the
run-time.

Oh, and the CI would look like this:

XYZ
Parameter 1 Description
Parameter 2 Description
Parameter 3 Description
Parameter 4 Description

Where each of the descriptions is something you have notified the OS to
display in a command file.  So the description would prompt the user for
what to enter, similar to using DISPLAYs and ACCEPTs to prompt the user
for what data to enter next.

--
Linux- the choice of a GNU generation. - http://www.linux.org/
and so is COBOL - http://www.gnu.org/software/cobol/index.html
See my web page at http://users.erols.com/bpkprsnl/ last updated
Tuesday, June 1, 1999

Re: [Tiny-cobol-users] Help with "accept"

[Boris <bpk...@er...>]

Glen Colbert wrote:
<snip>

> Just a minor point here.  I think it is starting at the leftmost, and
> progressing to the right until the receiving field is full or the source
> length is matched: then any remaining positions are padded with spaces (just
> like a regular alpha move.

Thanks Glen, I had skipped over the case of what to do when sending is less than
receiving in my synopsis to Rildo.
--
Linux- the choice of a GNU generation. - http://www.linux.org/
and so is COBOL - http://www.gnu.org/software/cobol/index.html
See my web page at http://users.erols.com/bpkprsnl/ last updated Tuesday, June
1, 1999

RE: [Tiny-cobol-users] readline

[Rildo P. <rpr...@ac...>]

Hi Glen,

On Sun, 19 Dec 1999, Glen Colbert wrote:

>   I found libraries, but no header files.  Even worse, I can't find the
> correct version of header files for the libraries that are loaded.  I'll
> have to build a 2.2 readline library, and hope it can co-exhist with the 3.0
> libraries which are loaded.
> 
> This is probably going to be a worse problem on the Solaris box...

Create the switch I've talked about in the previous mail, so you can
select if you want libreadline at compile time.  Anyway, you don't need to
link with it anymore.

regards,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

[Tiny-cobol-users] Smarter loading of libraries.

[Rildo P. <rpr...@ac...>]

Hi,

I have made some small changes to load libraries only when needed.  There
is a twofold advantage of this: (1) libraries are not preloaded, only when
explicitly called from a cobol library function; (2) there is no need to
add "-llibname" at the makefile (easier to  beginner builders :)  Well,
I'm just kidding.

Even the db library is under thisi kind of control now.  The drawback is
that we have to change the name of the "starter function" to run our stub.
In the case of libdb, the function is "db_open", a replacement to "dbopen"
(the original).  I hope this change at the name doesn't cause confusion.

To link, don't use -ldb anymore.  But, of course, we must have -ldl
(dynamic loader library) and libdb can even don't exist if we don't do
file i/o.  The same apply to other libraries (ncurses, when the screen
section is ready), and to libreadline.
BTW, if most of you don't want readline (please read about it first to see
if it is not interesting to have), it's easy to take it out.  Or a switch
(Glen?! this is your part) can be inserted to select with/without it.

I hope you agree with me that this is a Good Thing (TM) to have in our
compiler :)

Comments, please!

regards,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

RE: [Tiny-cobol-users] readline

[Glen C. <gco...@US...>]

Rildo,
  I found libraries, but no header files.  Even worse, I can't find the
correct version of header files for the libraries that are loaded.  I'll
have to build a 2.2 readline library, and hope it can co-exhist with the 3.0
libraries which are loaded.

This is probably going to be a worse problem on the Solaris box...

Glen

>
> You must already have it, because both bash and gdb and many other
> programs use it. Anyway, you may find it at www.gnu.org, or any of it
> mirror sites.  Read the docs and see by yourself if it's interesting
> having it included as a replacement for gets() from the terminal.

Re: [Tiny-cobol-users] readline

[Rildo P. <rpr...@ac...>]

Hi Glen,

On Sun, 19 Dec 1999, Glen Colbert wrote:

> The curses library caught me off guard.  OK, I spent the day building a
> curses library that would run in my environment.  Now I'm having trouble
> with a readline library??
> 
> What is it and where do I find it??

You must already have it, because both bash and gdb and many other
programs use it. Anyway, you may find it at www.gnu.org, or any of it
mirror sites.  Read the docs and see by yourself if it's interesting
having it included as a replacement for gets() from the terminal.

regards,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

[Tiny-cobol-users] readline

[Glen C. <gco...@US...>]

The curses library caught me off guard.  OK, I spent the day building a
curses library that would run in my environment.  Now I'm having trouble
with a readline library??

What is it and where do I find it??

Glen

Re: [Tiny-cobol-users] Command line input

[Fred M. <fr...@mo...>]

David Essex wrote:

> At 12:01 PM 19/12/99 +0100, Fred Mobach wrote:
>
> >>David Essex wrote:
> >>>What is the COBOL equivalent to this C code ?
> >>>main( int ac, char** av )
>
> >"Rolle, Ted" wrote:
> >
> >>COBOL would say something like:
> >>
> >>PROCEDURE DIVISION USING PARM-LIST.
> >>
> >>In the LINKAGE SECTION:
> >>
> >> 01 PARM-LIST.
> >>   05 PARM-LENGTH   PIC S9(04) COMP SYNC.
> >>   05 PARM-VALUE    X(100).
>
> >You're assuming in this particular case that the command line arguments are
> >in total not longer than 100 bytes. Will that be the next class of buffer
> >attacks ? Might it be possible to declare it like :
> >
> >01  PARM-LIST.
> >    05 PARM-LENGTH   PIC S9(04) COMP SYNC.
> >    05 PARM-VALUE.
> >       07 PARM-BYTE  PIC X OCCURS 4096 DEPENDING ON PARM-LENGTH.
>
> This does not look right. The above would represent only one of the av[]
> arguments. And where is the ac argument ?

Sorry David, but this is just an example of code I have used, although not in
the (at least for me) usuall mainframe environment.


> Also a linkage section in a main program ? No, this does not look right at
> all.

As I've stated before, yes, it's ugly but not unusuall. That's at least the way
I saw this problem solved in some compilers.


> >Scanning the arguments will be a nice job, though. But I like that kind of
> >jobs.
>
> Are volunteering to write the code, Fred ?

If (big if) I could write the code in C I would like to do it. But as you can
read in my introduction I'm not a C programmer. I'm used (in the mainframe
environment) to solve problems by writing programs and modules in COBOL and
Assembler. In the Unix environment I've written some _very_ small C programs,
but those are _not_ comparable with this project. What I intended to say is
that the COBOL programmer has to scan an argument, which is just the character
representation of the complete command line. That's not the most simple task
for most of the COBOL programmers. But if you want to get an example of my code
I would like to give it to you. Note however, it's just an example of the code
which has to be written for every COBOL programm.

Regards,

Fred Mobach

Re: [Tiny-cobol-users] How is our "accept" now.

[Rildo P. <rpr...@ac...>]

Hi Fred,

On Sun, 19 Dec 1999, Fred Mobach wrote:

> Some time ago (around 1982) we builded with a partner a 4GL system in order
> to develop in a stable and fast way interactive COBOL applications, which
> were maintainable in the long term. The proof for our success in the
> technical aspects is that on of our customers is still using this system
> since 1984. Commercially our product isn't a success because we're no
> marketing druids ;-).

It must be very successful, for there are people using it until now :)
Don't worry about marketing. If we were marketing geniuses, we were fight
M$ now and not giving away our work. 

> Our goal was to assist in developing business applications and that means a
> lot of COBOL. Because each COBOL compiler treated screen I/O in a different
> way we learned our 4GL to use only alphanumeric fields in the screens. The
> handling of the fields was dependent on the specs of that field. For this
> purpose we used some standard routines in COBOL, which were inserted in the
> source by a copy statement.

I see. You replace the "screen sections" around with a very portable
library, coded in cobol itself. 

> If you're interested in the way we handled this problem just tell me. In that
> case I will give you a source with the copy members to test. Of course these
> sources are free, so you can place them in the test suite under the GPL.

That would be a very interesting add-on to our project. Please send it and
I'll make it included in our releases. (of course if there is no
restriction to it's distribution under GPL)

I'm glad to see contributions from many members of our team :)
Let's make this cobol the real GNU Cobol, as Richard Stallman asked us to.

best regards,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

Re: [Tiny-cobol-users] Command line input

[David E. <de...@ar...>]

At 12:01 PM 19/12/99 +0100, Fred Mobach wrote:

>>David Essex wrote:
>>>What is the COBOL equivalent to this C code ? 
>>>main( int ac, char** av )

>"Rolle, Ted" wrote: 
>
>>COBOL would say something like: 
>>
>>PROCEDURE DIVISION USING PARM-LIST. 
>>
>>In the LINKAGE SECTION:   
>>
>> 01 PARM-LIST. 
>>   05 PARM-LENGTH   PIC S9(04) COMP SYNC. 
>>   05 PARM-VALUE    X(100).


>You're assuming in this particular case that the command line arguments are
>in total not longer than 100 bytes. Will that be the next class of buffer
>attacks ? Might it be possible to declare it like :   
>
>01  PARM-LIST. 
>    05 PARM-LENGTH   PIC S9(04) COMP SYNC. 
>    05 PARM-VALUE. 
>       07 PARM-BYTE  PIC X OCCURS 4096 DEPENDING ON PARM-LENGTH. 

This does not look right. The above would represent only one of the av[]
arguments. And where is the ac argument ?

Also a linkage section in a main program ? No, this does not look right at
all.


>Scanning the arguments will be a nice job, though. But I like that kind of
>jobs. 

Are volunteering to write the code, Fred ?



David  

Re: [Tiny-cobol-users] How is our "accept" now.

[Fred M. <fr...@mo...>]

Rildo Pragana wrote:

> You can enter alphanumeric as the standard.
>
> You can enter numbers with the decimal-point (locale, depending on
> "decima-point is comma clause") for delimiting the integer part from the
> fractional.  Please notice that a number like "pic V999" will only be
> entered if you first press the '.' or ',' (the decimal point) and then the
> digits.
>
> You can't input edited fields.
>
> What's desirable?

Rildo,

Some time ago (around 1982) we builded with a partner a 4GL system in order
to develop in a stable and fast way interactive COBOL applications, which
were maintainable in the long term. The proof for our success in the
technical aspects is that on of our customers is still using this system
since 1984. Commercially our product isn't a success because we're no
marketing druids ;-).

Our goal was to assist in developing business applications and that means a
lot of COBOL. Because each COBOL compiler treated screen I/O in a different
way we learned our 4GL to use only alphanumeric fields in the screens. The
handling of the fields was dependent on the specs of that field. For this
purpose we used some standard routines in COBOL, which were inserted in the
source by a copy statement.

If you're interested in the way we handled this problem just tell me. In that
case I will give you a source with the copy members to test. Of course these
sources are free, so you can place them in the test suite under the GPL.

Regards,

Fred Mobach

Re: [Tiny-cobol-users] Help with "accept"

[Ted R. <te...@ac...>]

Is this Interactive COBOL manual available?
> 
> If you still have a copy of the Interactive Cobol manual I e-mail to you

Re: [Tiny-cobol-users] Command line input

[Ted R. <te...@ac...>]

Good catch.  I keep forgetting; we're writing the compiler -- we can get
it to do it the way we think it should be done.  IBM COBOL has a built-in
limit, I think.

First-time surrealists are often confused by the similarities between fish and telephones.

On Sun, 19 Dec 1999, Fred Mobach wrote:

> "Rolle, Ted" wrote:
> 
> > COBOL would say something like:
> >
> > PROCEDURE DIVISION USING PARM-LIST.
> >
> > In the LINKAGE SECTION:
> >
> > 01  PARM-LIST.
> >     05 PARM-LENGTH       PIC S9(04) COMP SYNC.
> >     05 PARM-VALUE        PIC  X(100).
> 
> You're assuming in this particular case that the command line arguments
> are in total not longer than 100 bytes. Will that be the next class of
> buffer attacks ?
> 
> Might it be possible to declare it like :
> 
> 01  PARM-LIST.
>     05 PARM-LENGTH    PIC S9(04) COMP SYNC.
>     05 PARM-VALUE.
>        07 PARM-BYTE   PIC X OCCURS 4096 DEPENDING ON PARM-LENGTH.
> 
> 
> > Then in the body of the code:
> >
> > IF PARM-LENGTH IS GREATER THAN ZERO
> >         DISPLAY PARM-VALUE
> >         BLAH, BLAH, BLAH, ...
> > ELSE
> >         DISPLAY 'NO PARMS'
> > END-IF
> 
> Scanning the arguments will be a nice job, though. But I like that kind
> of jobs.
> 
> 
> > -----Original Message-----
> > From: David Essex [mailto:de...@ar...]
> >
> > I was wondering if anyone knows how COBOL reads command line input.
> > What
> > is the COBOL equivalent to this C code ?
> >
> > main( int ac, char** av )
> >
> > Does any one know ?
> 
> Regards,
> 
> Fred Mobach
> 

Re: [Tiny-cobol-users] Re: Tiny Cobol

[Rildo P. <rpr...@ac...>]

Hi,

On Sun, 19 Dec 1999, Andrew Cameron wrote:

> I think Rildo would be the best one to answer this as he is driving the
> project.

We have already discussed this issue. I think we should first finish this
version before forking to another output model. It's not so difficult to
convert it in a gcc front end, but not like it is now. 

For instance, our "perform" implementation require a very particular use
of the stack for storing the limits of the performing range, nothing
similar to be found in any other programming language implementation. I
acknowledge that our code generation is really ugly, but I don't even
think in changing it to accomodate gcc requirements. It's better to
redesign it, and I would like to participate in this redesign too.

In summary, let us finish what we are doing and then fork it in 2
branches, one for maintaining the current code and the other to make our
next version with full gcc support.

> On Fri, 17 Dec 1999, Richard Stallman wrote:
> 
> > I think it should be easier to turn it into a GCC front end than
> > to port to another machine.  So why bother porting it at all?
> > You may as well go straight to the destination, instead of taking
> > a detour.

I agree, in a long term this is very comfortable to work with, but why not
finish what's already working?
 
> > However, the idea of making this a GCC front end raises an issue.
> > Would you like to assign the copyright on this code to the FSF?
> > That is what we normally ask for, for front ends for GCC.

I don't see any problem with this, if we could make all cobol libraries
under LGPL, so it can generate business applications too.  I think our
customers (other programmers) don't want to be required to deliver their
commercial products with source code.

Personally, I enjoy doing this development, but I will not become a cobol
programmer. I like to be a tool programmer :)

best wishes,
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776

Re: [Tiny-cobol-users] Re: Tiny Cobol

[Andrew C. <an...@an...>]

Hi Richard,

I think Rildo would be the best one to answer this as he is driving the
project.

Regards
Andrew Cameron

On Fri, 17 Dec 1999, Richard Stallman wrote:

> Date: Fri, 17 Dec 1999 15:03:13 -0500
> From: Richard Stallman <rm...@gn...>
> Reply-To: tin...@so...
> To: an...@an...
> Cc: tin...@so...
> Subject: [Tiny-cobol-users] Re: Tiny Cobol
> 
>     To Port this current compiler to Sparc etc will not be difficult but as
>     you say it will be much easier once we have converted this compiler to a
>     front end for GCC
> 
> I think it should be easier to turn it into a GCC front end than
> to port to another machine.  So why bother porting it at all?
> You may as well go straight to the destination, instead of taking
> a detour.
> 
> However, the idea of making this a GCC front end raises an issue.
> Would you like to assign the copyright on this code to the FSF?
> That is what we normally ask for, for front ends for GCC.
> 
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users
> 

-----------------------------------------------------------------------------

Andrew Cameron
Internet : an...@an...
X.400    : C=ZA G=Andrew S=Cameron Admd=TELKOM400

----------------------------------------------------------------------------

Re: [Tiny-cobol-users] Help with "accept"

[Andrew C. <an...@an...>]

Hi Rildo,

If you still have a copy of the Interactive Cobol manual I e-mail to you
pages 123 onwards decsribes the screen section and gives some insight on
how it works.

One thing I can remember is that is you accept a screen with multiple
fields you could jump from field to field and go back to a previous field.

Regards
Andrew

On Thu, 16 Dec 1999, Rildo Pragana wrote:

> Date: Thu, 16 Dec 1999 19:49:23 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> Reply-To: tin...@so...
> To: tin...@ma...
> Subject: [Tiny-cobol-users] Help with "accept"
> 
> Hi,
> 
> I need some information on how the accept statement is expected to work.
> Well, it's not the syntax, but a description of the runtime procedures, or
> at least where can a find a detailed description of it.  No, I'm sorry I
> don't have a cobol compiler working here, only ours :(
> 
> For instance, when entering a number, what should happen if I enter the
> decimal point character (variable according the decimal-point clause) ?
> When I enter the first digit, the zeros at left should appear or not ?
> I have no idea of this.
> Please help me define how the accept should work.
> 
> regards,
>  ----------------------------------------------------------------
>  Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
>  P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
>  Brazil 54792-990              +55-81-459-1776
> 
> 
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users
> 

-----------------------------------------------------------------------------

Andrew Cameron
Internet : an...@an...
X.400    : C=ZA G=Andrew S=Cameron Admd=TELKOM400

----------------------------------------------------------------------------

Re: [Tiny-cobol-users] Breaking libcobol into separate libs

[Fred M. <fr...@mo...>]

David Essex wrote:

> I was wondering if it was possible and worth while to break up libcobol
> into separate libs.
>
> The advantage would be that it would remove any lib linkages when not
> used, form the generated binary.
>
> For example if a COBOL program does not use screen I/O, then it would
> not need to be linked with ncurses.
>
> The possible candiates are a basic lib, screen I/O lib(ncurses), indexed
> file I/O lib(db).

Very interesting, but the results will be depending upon the running
system. The next thoughts are based on the use of shared libraries.

If the program is running on a workstation it's quite possible it's the
only COBOL program running and in this case this will help to lower the
memory requirements. Otherwise, if the program is running on a multi-user
system (server ?), chances are more COBOL programs are running on the same
system and the more likely the case all the libs are in use.

So it might be interesting because of performance issues but I question if
that interesting now.

Regards,

Fred Mobach

Re: [Tiny-cobol-users] Command line input

[Fred M. <fr...@mo...>]

"Rolle, Ted" wrote:

> COBOL would say something like:
>
> PROCEDURE DIVISION USING PARM-LIST.
>
> In the LINKAGE SECTION:
>
> 01  PARM-LIST.
>     05 PARM-LENGTH       PIC S9(04) COMP SYNC.
>     05 PARM-VALUE        PIC  X(100).

You're assuming in this particular case that the command line arguments
are in total not longer than 100 bytes. Will that be the next class of
buffer attacks ?

Might it be possible to declare it like :

01  PARM-LIST.
    05 PARM-LENGTH    PIC S9(04) COMP SYNC.
    05 PARM-VALUE.
       07 PARM-BYTE   PIC X OCCURS 4096 DEPENDING ON PARM-LENGTH.


> Then in the body of the code:
>
> IF PARM-LENGTH IS GREATER THAN ZERO
>         DISPLAY PARM-VALUE
>         BLAH, BLAH, BLAH, ...
> ELSE
>         DISPLAY 'NO PARMS'
> END-IF

Scanning the arguments will be a nice job, though. But I like that kind
of jobs.


> -----Original Message-----
> From: David Essex [mailto:de...@ar...]
>
> I was wondering if anyone knows how COBOL reads command line input.
> What
> is the COBOL equivalent to this C code ?
>
> main( int ac, char** av )
>
> Does any one know ?

Regards,

Fred Mobach