tiny-cobol-users

[Tiny-cobol-users] Re: Tiny Cobol

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

Richard Stallman wrote:

> 
>     Personally I am looking at GPC 2.0(GNU Pascal)(1). They have used GCC
>     2.7.2.1 back end to create a Pascal compiler.
> 
>     Could this be an approach that COBOL could use ?
> 
> In general, that is the right approach.  You should make it work
> with the current version of GCC, of course.
> 
>     Why not an easy fit? Well besides the huge COBOL syntax, which makes
>     scanning/parsing a big job, COBOL has some unique features which in turn
>     require changes to the back end, another big job.
> 
> This may or may not require changes in the back end.
> Depending on the details, there may be an easier solution.
> 
>     Some of these features
>     include, data types which are not available in GCC, build in indexed file
>     support, to name a few.
> 
> Could you tell me about these data types?  If they are essentially
> opaque, and operated on only by library functions, you don't really
> need to teach the back end about them.  You could treat it as a
> structure type, as far as the back end is concerned.

That is a difficult question to answer in detail, since I am not very
familiar with the GCC back end specifics. However I will expand on a few
details, maybe you can shed some light on the matter.

In COBOL variables are defined/declared in a tree type structures. Each
variable has a storage size and a display size which may or may not be
the same size.

In this COBOL example X=alpha, 9=numeric, V=numeric implied decimal
point, COMP=binary storage.

01 V1.
  05 V1a       PIC X(20).
  05 V1b.
    10 V1b1    PIC 9(3)V99.
    10 V1b2    PIC 9(10) COMP.

The equivalent C code would be as follows. Fields of type X(alpha) are
non null terminated strings, like Pascal strings are. Fields of type
9(numeric) are Pascal strings, with only numeric data.

struct branch {
   branch *next_branch;
   leaf   *next_leaf;
   unsigned int len;
};

struct leaf {
   unsigned int display_len;
   unsigned int storage_len;
   unsigned int implicit_decimal_pos;
   unsigned char *display_data;
   leaf   *next_leaf;
};

Thus the above COBOL code as the following C code.

struct branch {
   next_branch = V1b;
   next_leaf   = V1a;
   len         = 29;
}V1;

struct branch {
   next_branch = NULL;
   next_leaf   = V1b1;
   len         = 9;
}V1b;

struct leaf {
   display_len = 20;
   storage_len = 20;
   implicit_decimal_pos = 0;
   display_data[20];
   next_leaf = NULL;
}V1a;

struct leaf {
   display_len = 5;
   storage_len = 5;
   implicit_decimal_pos = 2;
   display_data[5];
   next_leaf = V1b2;
}V1b1;

struct leaf {
   display_len = 10;
   storage_len = 4;
   implicit_decimal_pos = 0;
   display_data[10];
   next_leaf = NULL;
}V1b2;


So what are the GCC back end implications in having these type of
variables ?


Another example is the way COBOL controls program flow. It has
functions, which are called sub programs, but it also has procedures,
which in C are a cross between goto labels and functions. The following
example will illustrate what I mean.

PROCEDURE DIVISION.
PERFORM A100.
PERFORM A130.
STOP RUN.

A100.
 ...
A110
 ...
A120.
 ...
A130.
 ...

Control will flow from PERFORM A100, to the A100 procedure, to PERFORM
A130, to the A130 procedure, to STOP RUN, then exit.

Since procedures are neither goto labels nor functions, how is GCC going
to handle this ? Will the back end be effected ?  



>     Besides, how much of the current compiler could be used in GCC? Maybe the
>     scanner, and not much else I suspect.
> 
> I do not entirely understand this question.  But is it really relevant
> to the decision at hand?  I don't think so.
> 
> If you want a portable compiler producing good code, you can either use
> GCC, or do a gigantic amount of work to duplicate GCC.
> 
> Even supporting ONE additional target machine is probably as much
> work as connecting this front-end to GCC.  So why consider doing it
> the hard way?
> 
>     IMHO, the best approach is to complete this tiny project first, then
>     consider integrating this into GCC.
> 
> The sooner you connect it with GCC, the better.
> 
> if you continue on the present path, some of the work you do would
> need changing in order to connect it with GCC later.  That is inefficient.
> It is better to connect the front-end with GCC first, then finish the
> front-end by writing code that won't need to be redone.

There is a lot of work to change, regardless if it done now or later.


I think using GCC is the way to go, in the long run, but that is a large
project. The scope of this project while not small, is smaller, before
we can create a useful compiler. Further lessons learned here may be
applicable in tackling GCC.
  


David

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

[Rolle, T. <Ted...@ug...>]

I KNOW!  I KNOW!

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

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
-----Original Message-----
From: David Essex [mailto:de...@ar...]
Sent: Saturday, December 18, 1999 8:01 PM
To: tin...@so...
Subject: [Tiny-cobol-users] Command line input


Hi,


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 ?  




David

_______________________________________________
Tiny-cobol-users mailing list
Tin...@li...
http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users

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

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

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

 

David

[Tiny-cobol-users] Command line input

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

Hi,


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 ?  




David

[Tiny-cobol-users] Re: Tiny Cobol

[Richard S. <rm...@gn...>]

    Personally I am looking at GPC 2.0(GNU Pascal)(1). They have used GCC
    2.7.2.1 back end to create a Pascal compiler. 

    Could this be an approach that COBOL could use ?

In general, that is the right approach.  You should make it work
with the current version of GCC, of course.

    Why not an easy fit? Well besides the huge COBOL syntax, which makes
    scanning/parsing a big job, COBOL has some unique features which in turn
    require changes to the back end, another big job.

This may or may not require changes in the back end.
Depending on the details, there may be an easier solution.

    Some of these features
    include, data types which are not available in GCC, build in indexed file
    support, to name a few.

Could you tell me about these data types?  If they are essentially
opaque, and operated on only by library functions, you don't really
need to teach the back end about them.  You could treat it as a
structure type, as far as the back end is concerned.

    Besides, how much of the current compiler could be used in GCC? Maybe the
    scanner, and not much else I suspect.

I do not entirely understand this question.  But is it really relevant
to the decision at hand?  I don't think so.

If you want a portable compiler producing good code, you can either use
GCC, or do a gigantic amount of work to duplicate GCC.

Even supporting ONE additional target machine is probably as much
work as connecting this front-end to GCC.  So why consider doing it
the hard way?

    IMHO, the best approach is to complete this tiny project first, then
    consider integrating this into GCC.

The sooner you connect it with GCC, the better.

if you continue on the present path, some of the work you do would
need changing in order to connect it with GCC later.  That is inefficient.
It is better to connect the front-end with GCC first, then finish the
front-end by writing code that won't need to be redone.

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

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

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Richard
> Stallman
> Sent: Friday, December 17, 1999 1:03 PM
> To: an...@an...
> Cc: tin...@so...
> Subject: [Tiny-cobol-users] Re: Tiny Cobol
>
> 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 can't speak for the others, but MY intent was to have this be released as
FSF code, possibly even being distributed with the EGCS distributiion along
with Fortran and C++

Glen

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

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

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Rildo
> Pragana
> Sent: Thursday, December 16, 1999 4:14 PM
> To: tin...@ma...
> Subject: Re: [Tiny-cobol-users] Help with "accept"
>
> On Thu, 16 Dec 1999, Boris Kortiak wrote:
>
> >  As I read it, it is a MOVE to a PIC X(n) USAGE DISPLAY field.  In other
> > words, the ACCEPT puts bytes into the receiving starting at the leftmost
> > byte and progressing to the right until the receiving field is full,
> > everything after that point is ignored.

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.

RE: [Tiny-cobol-users] Some fixes for indexed file...

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

Hi All

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Rildo
> Pragana
> Sent: Wednesday, December 15, 1999 7:27 PM
> To: tin...@ma...
> Subject: RE: [Tiny-cobol-users] Some fixes for indexed file...
> Well, if the "key" clause is needed, then Glen's code is buggy. It tried
> to open the indexed file without it. Please see his test suite.  He will
> only come back saturday.
> If you agree on that, I can enforce this condition in the compilation,
> generating a warning/error.

Sorry for causing this confusion.  The code is buggy (I was testing the
compiler, not the Cobol run-time).  Indexed files should have a key
specificed.  The bug I was reporting was that the compiler crashed ugly,
instead of generating an error message.  Thanks to all for looking at this.

Glen

[Tiny-cobol-users] ACCEPT verb.

[Rolle, T. <Ted...@ug...>]

From what I understand, ACCEPT accepts alphanumeric data.  The target
PICTURE determines the usage. 

RE: [Tiny-cobol-users] BRAVO,BRAVO,BRAVO,BRAVO.... (fwd)

[Rolle, T. <Ted...@ug...>]

From what I understand, ACCEPT accepts alphanumeric data.  The target
PICTURE determines the usage.

-----Original Message-----
From: Rildo Pragana [mailto:rpr...@ac...]
Sent: Friday, December 17, 1999 11:39 AM
To: tin...@so...
Subject: Re: [Tiny-cobol-users] BRAVO,BRAVO,BRAVO,BRAVO.... (fwd)


Hi Ted,

On Fri, 17 Dec 1999, Ted Rolle wrote:

> Rildo:  have you been getting my posts?  I've not heard any replies.

Sorry, I've been with my e-mail off for 2 days. Now it's right.
I have seen your postings in our archive, but really what I wanted was
not the syntax, but the procedures for operating the "accept".

Suppose I do an accept with an numeric field.  What should I see? Just
some character fields to fill the digits (significative or not), or
something formatted on the screen with the (assumed) decimal point
visible, &c.

What is desirable?  I already know the syntax, I want the semantics. (the
operational details)

I don't even know well how to express myself about those details, and
don't have a cobol compiler (except ours, of course) to test and see what
should happen.

Please look at our latest cvs release and see how it work (see
test.code/t16) and tell me what's wrong and how it should be, to be really
useful.

Thank you for your input.

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

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

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

Hi Richard,

On Fri, 17 Dec 1999, Richard Stallman wrote:

> 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 it. When I decided to open the source of the
original compiler that evolved to Tiny Cobol, I was just trying to make
something useful of some code I have already thrown away. It was residing
in my archival of "old crap things" and it got a revival now with the help
of many friends.  I don't answer for the others, but my personal opinion
is that we make it wide open and protected from lack of openess, that's
why I choose to put it under GPL.  The obvious restriction is that the
libraries be LGPL so there could be deployed in business applications.

best wishes,
Rildo
 ----------------------------------------------------------------
 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] Re: Tiny Cobol

[Richard S. <rm...@gn...>]

    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.

Re: [Tiny-cobol-users] BRAVO,BRAVO,BRAVO,BRAVO.... (fwd)

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

Hi Ted,

On Fri, 17 Dec 1999, Ted Rolle wrote:

> Rildo:  have you been getting my posts?  I've not heard any replies.

Sorry, I've been with my e-mail off for 2 days. Now it's right.
I have seen your postings in our archive, but really what I wanted was
not the syntax, but the procedures for operating the "accept".

Suppose I do an accept with an numeric field.  What should I see? Just
some character fields to fill the digits (significative or not), or
something formatted on the screen with the (assumed) decimal point
visible, &c.

What is desirable?  I already know the syntax, I want the semantics. (the
operational details)

I don't even know well how to express myself about those details, and
don't have a cobol compiler (except ours, of course) to test and see what
should happen.

Please look at our latest cvs release and see how it work (see
test.code/t16) and tell me what's wrong and how it should be, to be really
useful.

Thank you for your input.

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] BRAVO,BRAVO,BRAVO,BRAVO.... (fwd)

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

Rildo:  have you been getting my posts?  I've not heard any replies.

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

[Tiny-cobol-users] BRAVO,BRAVO,BRAVO,BRAVO.... (fwd)

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

Hi,

Here is another anxious user for our tool.  Please Glen, coordinate the
documentation writing job so she (or maybe "he"? I'm not sure) can have a
way to help us.  I would not like to be myself the documentation
coordinator, as I don't master so well the english language.

We should not spare any help we can have.

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

---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 17:47:52 -0800
From: BETACO <be...@mp...>
To: rpr...@ac...
Subject: BRAVO,BRAVO,BRAVO,BRAVO....

Well...at last somebody to do the right thing.

Thank you Thank you Thank you....

Bless you for making a COBOL for the free software community.

I need it badly.What can I do to help you?Do you need a beta tester? 

A documentation writer? I don't know how to write the compiler but all the other things that you need-just wistle,I'l be there for you.


Loves you a lot,


Mirce Vladimirov

 

<bold>BeTaCo Inc.

</bold>Str.Nikola Parapunov 3a/26

91000 Skopje

Macedonia


Tel/Fax ++389 91 362428

e-mail be...@ni...

[Tiny-cobol-users] Re: Tiny Cobol

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

Hi Richard,

It is great to have the e-mail server working again. As the saying goes,
you do not know what you have until it is no longer available !

On 12/15/1999 10:19:42, Richard Stallman wrote.

>The current system creates Gnu Assembler which is then assembled and
>linked with the library routines. A later version may output C code.
>
>How do you port it to new machines?
>
>Have you considered making this a front-end for GCC?
>Then it would automatically support all the machines
>that GCC supports, and you would have much less work to do.

Yes, we have/are considering making this a front-end for GCC.

Personally I am looking at GPC 2.0(GNU Pascal)(1). They have used GCC
2.7.2.1 back end to create a Pascal compiler. 

Could this be an approach that COBOL could use ? I personally think that
this is a lot of work but do-able. It is not however an easy fit.

Why not an easy fit? Well besides the huge COBOL syntax, which makes
scanning/parsing a big job, COBOL has some unique features which in turn
require changes to the back end, another big job. Some of these features
include, data types which are not available in GCC, build in indexed file
support, to name a few.

Besides, how much of the current compiler could be used in GCC? Maybe the
scanner, and not much else I suspect.

What about the logistics ? Is it realistic to have a 20+ MB file on a cvs
server, then try to do a checkout over a slow internet link ? 

IMHO, the best approach is to complete this tiny project first, then
consider integrating this into GCC.



David

1) GNU Pascal home page
   http://agnes.dida.physik.uni-essen.de/~gnu-pascal/home.html
   GPC 2.0 can be found at
   http://metalab.unc.edu/pub/Linux/devel/lang

[Tiny-cobol-users] A short reminder.

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

Hi,

Please, notice, although I have have talked about the "screen section" to
control ncurses screen i/o, we don't have yet a screen section
implemented.  I'm taking this job now. You shall not declare variables at
the screen section actually, only use it to get a ncurses screen.  Later,
we will have a full screen with background/foreground color, several video
attributes, and more, as stated in the CD-1.2 cobol standard.

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] A solution for all tastes.

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

Hi,

I have done the following:

If you declare a screen section in your program, even without any item
introduced, will force the compiler to use ncurses for terminal i/o. In
other words, it will have a screen oriented terminal i/o processing.

If you don't have a screen section, it will use the standard input/output
(stdin/stdout) for display/accept statements. With this option, youcan
redirect input from a line sequential file, for instance.

There is an example in test.code/t16.  PLease try it to see how it works.
You have to get the current cvs snapshot to try.

I hope this will make we have the best of both worlds.
What you think?

BTW, when Glen arrive, we can ask him to make a switch at the argument
processing commands, so we can override this automatic selection.

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] How is our "accept" now.

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

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?

All those are only working with the current cvs snapshot.  I have made
small changes in the last few minutes.

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] Help with "accept"

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

Hi,

On Thu, 16 Dec 1999, Boris Kortiak wrote:

>  As I read it, it is a MOVE to a PIC X(n) USAGE DISPLAY field.  In other
> words, the ACCEPT puts bytes into the receiving starting at the leftmost
> byte and progressing to the right until the receiving field is full,
> everything after that point is ignored.

This is much simpler than I have implemented for the original tiny cobol
compiler. (even for the microterminals)
I have included DARK (echoing '*'), WITH NO ECHO, decimal point alignment
in numeric fields, positioning with (LINE, COLUMN), auto-skiping when
filling fields (optional), and more. Well, I'll let you decide. This
standard implementation is much easier to do and I
would be glad to make it into reality :)
  
What the others think? Is any extension desirable, or just follow the
standard. What the commercial implementations do? What do you use to get
input from your user's applications?

> Some extensions I have seen include:
>  	ON SIZE ERROR determines what processing to do in the event that
>the input bytes exceed the size of the receiving field
>  	AT which identifies a position (either YYXX, YYYXXX or YYYYXXXX)
>on the screen at which to echo the ACCEPTED bytes where the X term
>indicates the column and the Y term indicates the row of a character
based display
> 	LINE or ROW which identifies the row of the display
> 	COL(UMN) which identifies the column of the display
>  	[NO] ECHO where ECHO is the default and NO ECHO means that the
>information is not echoed to the display (for things like password
>security and such)

Thank you, Boris for your contribution.

regards, (e um grande abraço)
 ----------------------------------------------------------------
 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] Help with "accept"

[Rolle, T. <Ted...@ug...>]

Rildo:  How's this? <g>

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGYL1101/CCONTENTS -
COBOL language reference
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGYA2101/CCONTENTS -
COBOL programmer's guide

-----Original Message-----
From: Rildo Pragana [mailto:rpr...@ac...]
Sent: Thursday, December 16, 1999 1:49 PM
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

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

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

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

RE: [Tiny-cobol-users] Some fixes for indexed file...

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

Hi,

On Thu, 16 Dec 1999, Andrew Cameron wrote:

> I have tried running some of the test programs and they seem to work ok.
> When running t11 and using 999 as the answer the system seems to auto
> accept before I press <NL>.

Yes. For the microterminals, was convenient to have an auto-skip ever
implemented. I will change this.  Anyway, the "auto" was implemented at
the screen section and we had no screen section.  (the terminal was only
2x16 characters, why a screen section for it?)

> I am not sure but I think that on DG Cobol this does not happen Unless
> that field is defined as AUTO in the SCREEN SECTION.

Yes, I'm sure of it.  Give me some time and I'll fix it.

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] Some fixes for indexed file...

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

Hi,

I will look at your web page later tonight.

I have tried running some of the test programs and they seem to work ok.

When running t11 and using 999 as the answer the system seems to auto
accept before I press <NL>.

I am not sure but I think that on DG Cobol this does not happen Unless
that field is defined as AUTO in the SCREEN SECTION.

See the brief cobol Syntax Document I sent you some time back.

Regards
Andrew

On Thu, 16 Dec 1999, Rildo Pragana wrote:

> Date: Thu, 16 Dec 1999 17:39:51 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> Reply-To: tin...@so...
> To: tin...@so...
> Subject: RE: [Tiny-cobol-users] Some fixes for indexed file...
> 
> Hi Andrew,
> 
> On Thu, 16 Dec 1999, Andrew Cameron wrote:
> 
> > Yes I think that the compiler should generate an error if the key is is
> > missing on the Select statement for an indexed file.
> 
> Ok, now it generates an error if not defined the record key.
> 
> Did you try the ncurses version of accept/display?  
> I want to know how the other compilers do to accept edited fields. If you
> have a short explanation, please send to me.  I remembered simplifying too
> much this thing for the microterminals.
> 
> BTW, did you see the pictures of the microterminal? It's already in my
> home page. (it's somewhat large, though, about 120KB each)  That was the
> target for the original cobol I implemented (not as it is now, of course).
> 
> 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] Some fixes for indexed file...

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

Hi Andrew,

On Thu, 16 Dec 1999, Andrew Cameron wrote:

> Yes I think that the compiler should generate an error if the key is is
> missing on the Select statement for an indexed file.

Ok, now it generates an error if not defined the record key.

Did you try the ncurses version of accept/display?  
I want to know how the other compilers do to accept edited fields. If you
have a short explanation, please send to me.  I remembered simplifying too
much this thing for the microterminals.

BTW, did you see the pictures of the microterminal? It's already in my
home page. (it's somewhat large, though, about 120KB each)  That was the
target for the original cobol I implemented (not as it is now, of course).

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