tiny-cobol-users

Re: [Tiny-cobol-users] Tiny Cobol

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

Hi,

Welcome, I am glad to see another programmer who used DG Cobol for
Data General.

Regards
Andrew

On Tue, 7 Dec 1999, DARI UMBERTO wrote:

> Date: Tue, 7 Dec 1999 08:50:10 +0100 
> From: DARI UMBERTO <DA...@LL...>
> Reply-To: tin...@so...
> To: tin...@ma...
> Subject: [Tiny-cobol-users] Tiny Cobol
> 
> My request was to subscribe to the mailing list about TinyCobol for Linux.
> I'm interested in that programming language. I have about 25 years
> experience in Cobol, from mainframes to PC with CP/M, passing through
> RM-COBOL for Xenix, Unix, to MS-COBOL for MSDOS and Windows.
> I'm beginning to work with Linux and was looking for a languge different
> from C, that I don't like.
> You are doing a great work and I would like to help, testing your compiler.
> I have lots of programs in Cobol, but that use SCREEN SECTION (from DG's
> Interactive Cobol)
> Best regards
> Umberto DARI
> Lloyd Adriatico - Sede
> Tel  0407781488
> Email : da...@ll... <mailto:da...@ll...> 
> 
> _______________________________________________
> 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] Delete statement for relative files.

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

Hi,

Thanks 

I have tested it and delete for relative IO also now works correctly.

I will now start to tackle Alternate Keys.

Regards
Andrew

On Mon, 6 Dec 1999, Rildo Pragana wrote:

> Date: Mon, 6 Dec 1999 21:18:11 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> Reply-To: tin...@so...
> To: tin...@ma...
> Subject: [Tiny-cobol-users] Delete statement for relative files.
> 
> Hi Andrew,
> 
> I have updated the cob_delete to receive an additional argument (recno)
> when it refers to relative files (w/access mode not sequential).
> 
> 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

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

[Tiny-cobol-users] More notes about the binary thing.

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

Hi,

I forgot to tell you in the previous message.  Most of library code is
wrong. They not take in account (yet) our new "usage is comp" variables.
So don't make use of it until the library is fixed.  

Any takers? (we must change all basic math routines: add, multiply, ... to
cope with the new data type)

I have only updated the "move" statement, so I can show you something,
sorry :(

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] New COMP (binary) usage.

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

Hi,

I decided to make a holliday from that horrible "inspect" statement today.
So I've got other more soft things to do: implementation of USAGE IS COMP
for our cobol.  And here is it :)

The test program t16 will show (and prove with a little ascii joke) that
the implementation is correct.  Please compile and run it!

Enjoy!

 ----------------------------------------------------------------
 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] Calling subprograms.

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

Hi David,

I have changed back our "call" statement to generate only a (char *)
pointer for each argument, but your program yet dumps core.  As I told you
before, the problem is with the linkage section receiving (at the
subprogram side), as I have coded previously the "pic_expand" subroutine
in C (it's at t07) and it worked well. (Now, it doesn't work anymore, as
the arguments have changed.)

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] Tiny Cobol

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

Hi Umberto,

On Tue, 7 Dec 1999, DARI UMBERTO wrote:

> My request was to subscribe to the mailing list about TinyCobol for Linux.
> I'm interested in that programming language. I have about 25 years
> experience in Cobol, from mainframes to PC with CP/M, passing through
> RM-COBOL for Xenix, Unix, to MS-COBOL for MSDOS and Windows.

That's fine! 
Unfortunatelly,I have no way to make you a subscriber.  Please, point your
browser to http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users
and fill the form. 

> I'm beginning to work with Linux and was looking for a languge different
> from C, that I don't like.
> You are doing a great work and I would like to help, testing your compiler.
> I have lots of programs in Cobol, but that use SCREEN SECTION (from DG's
> Interactive Cobol)

We shall have a screen section in a few weeks. I'm trying to keep a fast
pace, although I'm becoming tired.  
Be very welcome.  All help for testing and documenting is a
must, as we have plenty of library work and compiler syntax to test.

Ciao bambino,
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

Re: [Tiny-cobol-users] Delay in mailing list delivery?

[Alan D. <ad...@vi...>]

At 08:18 PM 06-12-99 -0200, you wrote:

>I have noticed a large delay to the mails sent to the list being archived.
>Are you receiving the messages in short time? 
>I'm sending this message at 
>         Mon Dec  6 22:16:02 UTC 1999

Hi,

For what it's worth I received the message at -

Date: Mon, 6 Dec 1999 20:18:38 -0200 (EDT)

Your new signature is a lot more restful on the eyes.

Regards,
Alan.au

[Tiny-cobol-users] Tiny Cobol

[DARI U. <DA...@LL...>]

My request was to subscribe to the mailing list about TinyCobol for Linux.
I'm interested in that programming language. I have about 25 years
experience in Cobol, from mainframes to PC with CP/M, passing through
RM-COBOL for Xenix, Unix, to MS-COBOL for MSDOS and Windows.
I'm beginning to work with Linux and was looking for a languge different
from C, that I don't like.
You are doing a great work and I would like to help, testing your compiler.
I have lots of programs in Cobol, but that use SCREEN SECTION (from DG's
Interactive Cobol)
Best regards
Umberto DARI
Lloyd Adriatico - Sede
Tel  0407781488
Email : da...@ll... <mailto:da...@ll...> 

RE: [Tiny-cobol-users] Re: Another observation about subroutines.

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

> This is somewhat dangerous, as the C program don't really know the size of
> the variable and could do anything, even write nulls to the end of the
> variable (this belongs to another variable, of course).

That's one of the 'endearing' features of Cobol - subroutines can corrupt
the storage of calling programs.  Possibly there should some boundary
checking, but I'm afraid that if we make changes to the calling conventions,
precompilers and external libraries might no longer work (Oracle for
example).

> Please think a little more about this.  As we are doing it from (almost)
> the ground up, we can choose anything we find useful.  Let also see what
> the others have to tell us about this...
> (^G^G^G^G^G^G  are you hearing me????? ^G^G^G^G^G^G^G^G^G)
> I suggest also we look at other software manufacturers (besides the bug
> blue) about their methods for doing subprograms and extensions in C or
> other non-cobol languages.  Any docs are welcome.

MicroFocus uses a compiler argument to specify the calling convention
(Pascal, C).  We could have it both ways if we had enough programmers to
write multiple calling convention code :)

> Well, the symbol table don't exists anymore at the runtime.  The only
> information we have about the symbols are what is declared at "struct
> fld_desc", much less than "struct sym".  Functions in "C" use the stack to
> store the "bp" register (base pointer) to request automatic variables, so
> it's diffiult to know what's deeper in the stack (that's why we have
> var_args functions to access variable number of arguments).

We will need to find a way to pass some form of symbol table to the runtime
for a debugger.

> > Some I*B mainframe COBOL compilers for example have a special variable
> > called RETURN-CODE, which are set by the programmer, and are
> > equivalent to the C statement return int.

Also RETURN-CODE in AcuCobol, MicroFocus and other compilers I have used.

> What I don't understand is why you are concerned with calling C functions
> now. Please, let us finish the missing statements and we turn to make the
> mathematical functions and other C functions.

Oracle has released a version for Linux.  If our calling conventions are
compatible with Oracle, people will be able to write Cobol programs using
Tiny-Cobol to access Oracle.  I think that this would add significant
functionality and usability from very early releases.  This might be very
desirable (see the oracle sample code in the test_suite/compile_tests
directory.)

RE: [Tiny-cobol-users] Runtime Move Routine questions

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

> 
> > How do we want to handle run time errors, such as moving non 
> > numeric data into a numeric field?

I would like to see a runtime error routine that

1) Text and numeric description of documented error

2) Hex and ascii dump of all storage areas, identified by storage area

   WORKING-STORAGE
    EF 23 42 4F 7B 28    ...FOE.
    74 00 00 00 00 00    FE.....

   LINKAGE-1
    F0 F0 F0 F0 F0 F0     .....
    31 31 31 31 31 31     11111

3) Text information of compiled file name (from PROGRAM-ID ??)
4) Compiler version information
5) Program compile date and time

6) Source code LINE NUMBER of offending statement
6a) Token number on offending line ??

Being as I want so much, I probably should write this =:()

Glen

RE: [Tiny-cobol-users] Runtime Move Routine questions

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

Jim,
  All is a special case.  It should move repeating copies of the source to
the target.  This does not happen if the ALL modifier is not used.

  Just a note.  The decimal point can be either to the left or to the right
of significant digits.

PIC 999V99
PIC VPPP999
PIV 999PPV
    -----Original Message-----
    From: tin...@so...
[mailto:tin...@so...]On Behalf Of Noeth, Jim
    Sent: Monday, December 06, 1999 9:06 AM
    To: 'tin...@li...'
    Subject: [Tiny-cobol-users] Runtime Move Routine questions


    I am currently working on the run time routines that perform move
related functions. I have run into a few situations that I would like input
on.

    It appears that the decimals field of the fld_desc structure is being
used as a boolean value to indicate whether or not there are digits to the
right of the decimal point. If this field contained the number of digits to
the right of the decimal point instead and an indicator was added to the
structure as to whether or not this was a signed field, the runtime routines
could be made much more efficient, as they would not have to decode the
picture clause, except for editted fields.

    The 'all' field of the fld_desc structure (which is documented in the
info section as occurs) is used to signify that the data associated with the
field, when moved to another field will be repeated until the length of the
receiving field is satisfied. Which definition is correct, or do we need
both?

    How do we want to handle run time errors, such as moving non numeric
data into a numeric field?

    Thanks,
    Jim Noeth

[Tiny-cobol-users] Some progress.

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

Hi,

At least I was able to finish the compilation of the (now correct!!!)
inspect statement, in full.  Well, not everything, but just the parsing
phase, without all those annoying reduce/reduce conflicts. 

The remaining part is much easier. Just a matter of time :)
It was uploaded again. 

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] Fixed bug with large arrays.

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

Hi David,

Ok. I was tired of trying to make "inspect" work and decided to give a try
on your problem with large arrays. Now the size is stored with a ".long",
so instead of 65536, it allows a maximum record of 4294967296 bytes.
(according to my 'bc' calculator :)

All the "inspect" stuff in the compiler is wrong. I think I will have a
break with this thing. When I try to make according the standard, the
parser generates 41 reduce/reduce conflicts. Of course, it will not
compile correct code for most statements in this way.  Some hacking needed
here! (I'm tired of adding state swithces to the scanner)  I have looked
at Josling's parser too, but found nothing I can use straight here.

I hope you're glad with the large arrays. If so, at least something I've
done will not be thrown away today.

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] Delete statement for relative files.

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

Hi Andrew,

I have updated the cob_delete to receive an additional argument (recno)
when it refers to relative files (w/access mode not sequential).

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] Delay in mailing list delivery?

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

Hi,

I have noticed a large delay to the mails sent to the list being archived.
Are you receiving the messages in short time? 
I'm sending this message at 
         Mon Dec  6 22:16:02 UTC 1999

Please David, Andrew or anyone report what time (utc/gmt) it arrived, to
see if there is a large delay.

(I have changed my .signature, because it is very messy in html, anyway)

regards,
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: Cobol Delete

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

Hi Andrew,

On Mon, 6 Dec 1999, Andrew Cameron wrote:

> Once delete is complete I plan to start with the library routines for
> ALTERNATE KEYS.
> We will also need a field in the structure to carry the active key as once
> you access a file via START or READ with an alternate KEY ALL IO to that
> file must use the Alternate KEY until such time as another READ or START
> changes to another ALTERNATE or PRIMARY KEY.
> For this to work the compiler will also need to be able to compiler
> READ xxx KEY IS key-name etc
> where key-name is anyone of the valid keys defined for that file.

Ok.  I would like to have more implementors here to give support to the
others. I will do this for Andrew, but there are many thing I'm supposed
to do at (almost) the same time :)

If someone know how to do this, please take the job. If not, I have to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
read again the syntax of cobol (standards, some manufacturers manuals,..)
and try to make the changes needed so Andrew can continue with his work.
If nobody accepts the job, I'll do it. Please wait some time.

regards,
Rildo

P.S. - Please don't write to me, write to the list, as sometimes others
can be helpful. That's what the list is about: to share
our experiences :)
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/

[Tiny-cobol-users] Re: Another observation about subroutines.

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

Hi David,

On Mon, 6 Dec 1999, David Essex wrote:

> I think that there is another way of doing this. The only thing you need to
> pass is the references to the variables, not their
> descriptions(declarations). So your above example would be as follows.
> 
> [COBOL, calling program]
> PROGRAM-ID: main.
> ...
> WORKING-STORAGE.
> * variable definition
> 01 VAR1   PIC X(10).
> ...
> PROCEDURE-DIVISION.
> CALL "test" USING VAR1.
> 
> [C, called function(sub program)]
> // variable declaration(not definition)
> extern char var1[10];
> // Shouldn't char* be void* ? I am not sure.
> void test( char *var_buf ) { 
>    var1 = var_buf;
>    ...
> }

This is somewhat dangerous, as the C program don't really know the size of
the variable and could do anything, even write nulls to the end of the
variable (this belongs to another variable, of course).  I think it's
better to have the descriptor, so the function could be generalized.
If you don't need it, just make a dummy argument like (void *dummy1) to
receive the descriptor and ignore it.
Most of the library functions already require them, anyway.  
When we make the mathematical functions (abs, cos, sin, &c) we will need
also the descriptors, otherwise we will have to assemble some "move"
instructions to move the returned "double float" value to the variable.

The older (msdos) compiler do exactly what you mean (only "char *" is
passed) and I have experienced many problems with this.  For cobol
subprograms, we just replace the arriving arguments by the "procedure
division using ..." arguments at the called subprogram.  So cobol or C
programs will behave exactly the same, except that the C programs will
have 2 pointers to each variable.  Also, the cobol subprogram can redefine
the arguments to another layout (this is dangerous too, of course, but can
be done), if the size is maintained.

Please think a little more about this.  As we are doing it from (almost)
the ground up, we can choose anything we find useful.  Let also see what
the others have to tell us about this...
(^G^G^G^G^G^G  are you hearing me????? ^G^G^G^G^G^G^G^G^G)
I suggest also we look at other software manufacturers (besides the bug
blue) about their methods for doing subprograms and extensions in C or
other non-cobol languages.  Any docs are welcome.

> The two major drawbacks with this are as follows.  It may complicate the
> sym struct. I am not sure what the C calling method actually puts on the
> stack, so it may complicate matters.

Well, the symbol table don't exists anymore at the runtime.  The only
information we have about the symbols are what is declared at "struct
fld_desc", much less than "struct sym".  Functions in "C" use the stack to
store the "bp" register (base pointer) to request automatic variables, so
it's diffiult to know what's deeper in the stack (that's why we have
var_args functions to access variable number of arguments).
 
> BTW, the COBOL sub program does not return anything to the calling program,
> nor does a main program return anything. So it is equivalent the C void
> return type. There are COBOL compiler extensions, which add a return code.
> Some I*B mainframe COBOL compilers for example have a special variable
> called RETURN-CODE, which are set by the programmer, and are equivalent to
> the C statement return int.
> 
> Also a sub program does not need a asm_call("stop_run"), and the main
> labels (ie. main: main@.. etc) should be changed to the sub program name.
> In t15 I do that using sed before using GAS.

BTW, I can't yet make your example. Please correct the makefile, so I can
try to help you.

Anyway we are already prepared to return codes for the calling program.
Our file i/o routines are doing this to return status code, that are
tested by a separate function (get_status), that fills the "file status"
variable, and also as we test with "at end" or other if-like conditions.
We can change this later, but it means reworking many things in the
compiler. I think it's better leave it this way for now.

What I don't understand is why you are concerned with calling C functions
now. Please, let us finish the missing statements and we turn to make the
mathematical functions and other C functions.

best regards,
Rildo
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/

[Tiny-cobol-users] Re: Cobol Delete

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

Hi,

Once delete is complete I plan to start with the library routines for
ALTERNATE KEYS.

Thanks for implementing the code to compile ALTERNATE KEYS and for
defining the structures that I will need to write the library routines.

We will also need a field in the structure to carry the active key as once
you access a file via START or READ with an alternate KEY ALL IO to that
file must use the Alternate KEY until such time as another READ or START
changes to another ALTERNATE or PRIMARY KEY.

For this to work the compiler will also need to be able to compiler
READ xxx KEY IS key-name etc
where key-name is anyone of the valid keys defined for that file.

Regards
Andrew Cameron

On Mon, 6 Dec 1999, Rildo Pragana wrote:

> Date: Mon, 6 Dec 1999 17:15:45 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> To: Andrew Cameron <an...@an...>
> Cc: tin...@ma...
> Subject: Re: Cobol Delete
> 
> Hi Andrew,
> 
> On Mon, 6 Dec 1999, Andrew Cameron wrote:
> 
> > Currently the Cobol Delete works correctly for Indexed Files.
> > 
> > It does not work for relative files as the current implementation does not
> > return recno.
> > 
> > For it to work I need the following.
> > 
> > int cob_delete(struct file_fdesc *f, char *record, ...)
> > 
> > So that I can get the record Number with
> > va_start(args,record);
> > recno = va_arg(args,recno_t);
> > va_end(args);
> > 
> > Please could you change the Compiler to return this information so that
> > the DELETE Statement will work with Relative IO.
> 
> If I remember well, it did like you told (passing a recno in var_args)
> before. I don't know how this changed. 
> Anyway, I'll fix this shortly.
> 
> I'm still redoing all the inspect statement.  Who said "move" is the most
> difficult part of the language? I would like better to be working in the
> "move" stuff, as I'm getting crazy with "inspect", just after "unstring"
> and "string". I really don't know what's the worse of these :(
> When I finish this, I'll go for a "hollidays" with 
> the accect statement :)  Just some little tricks with ncurses...
> 
> regards,
> Rildo
>  _____   _ __    __       __      __      ___      __  Rildo Pragana
> /\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
> \ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
>  \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
>   \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
>    \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
>     \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/
> 

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

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

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

[Tiny-cobol-users] Re: Cobol Delete

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

Hi Andrew,

On Mon, 6 Dec 1999, Andrew Cameron wrote:

> Currently the Cobol Delete works correctly for Indexed Files.
> 
> It does not work for relative files as the current implementation does not
> return recno.
> 
> For it to work I need the following.
> 
> int cob_delete(struct file_fdesc *f, char *record, ...)
> 
> So that I can get the record Number with
> va_start(args,record);
> recno = va_arg(args,recno_t);
> va_end(args);
> 
> Please could you change the Compiler to return this information so that
> the DELETE Statement will work with Relative IO.

If I remember well, it did like you told (passing a recno in var_args)
before. I don't know how this changed. 
Anyway, I'll fix this shortly.

I'm still redoing all the inspect statement.  Who said "move" is the most
difficult part of the language? I would like better to be working in the
"move" stuff, as I'm getting crazy with "inspect", just after "unstring"
and "string". I really don't know what's the worse of these :(
When I finish this, I'll go for a "hollidays" with 
the accect statement :)  Just some little tricks with ncurses...

regards,
Rildo
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/

Re: [Tiny-cobol-users] May we change to this mailing list?

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

Hi,

I have subscribed

Regards
Andrew Cameron

On Fri, 3 Dec 1999, Rildo Pragana wrote:

> Date: Fri, 3 Dec 1999 17:50:50 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> To: tin...@ma...
> Subject: [Tiny-cobol-users] May we change to this mailing list?
> 
> Hi,
> 
> If you did already subscribed, please answer to this message. I would like
> to know if everyone is at this mailing list.  If so, we can stop sending
> mails directly to the others.
> With a mailing list is better, because we have everything archived and
> others (not developers) can participate and give their suggestions.
> 
> regards,
>  _____   _ __    __       __      __      ___      __  Rildo Pragana
> /\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
> \ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
>  \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
>   \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
>    \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
>     \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/
> 
> 
> _______________________________________________
> 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] Runtime Move Routine questions

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

Hi Jim,

On Mon, 6 Dec 1999, Noeth, Jim wrote:

> I am currently working on the run time routines that perform move related
> functions. I have run into a few situations that I would like input on.
> 
> It appears that the decimals field of the fld_desc structure is being used
> as a boolean value to indicate whether or not there are digits to the right
> of the decimal point. If this field contained the number of digits to the
> right of the decimal point instead and an indicator was added to the
> structure as to whether or not this was a signed field, the runtime routines
> could be made much more efficient, as they would not have to decode the
> picture clause, except for editted fields. 

Your'e right, the field "decimals" refer to the number of decimals to the
right (if positive), or the number of zeros to add at the right if
negative, in this case as an absolute value, when the clause have "P" at
the right.  So it is the scaling of the field.
You don't need to scan the picture to get this.

> The 'all' field of the fld_desc structure (which is documented in the info
> section as occurs) is used to signify that the data associated with the
> field, when moved to another field will be repeated until the length of the
> receiving field is satisfied. Which definition is correct, or do we need
> both?

The "all" means whe shall "wrap around" when reaching the last position of
a literal, because it should be repeated. For instance to move "ABC" with
"all = 1" to a field with size 10, will give "ABCABCABCA".  The size of
the first field (that must be a literal, of course) is 3. 

> How do we want to handle run time errors, such as moving non numeric data
> into a numeric field?

Well, I'm no cobol guru.  There are many of them in this list, so I'll let
one of them answer your question :)

regards,
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/

[Tiny-cobol-users] Runtime Move Routine questions

[Noeth, J. <jm...@ag...>]

I am currently working on the run time routines that perform move related
functions. I have run into a few situations that I would like input on.

It appears that the decimals field of the fld_desc structure is being used
as a boolean value to indicate whether or not there are digits to the right
of the decimal point. If this field contained the number of digits to the
right of the decimal point instead and an indicator was added to the
structure as to whether or not this was a signed field, the runtime routines
could be made much more efficient, as they would not have to decode the
picture clause, except for editted fields. 

The 'all' field of the fld_desc structure (which is documented in the info
section as occurs) is used to signify that the data associated with the
field, when moved to another field will be repeated until the length of the
receiving field is satisfied. Which definition is correct, or do we need
both?

How do we want to handle run time errors, such as moving non numeric data
into a numeric field?

Thanks, 
Jim Noeth

Re: [Tiny-cobol-users] BUGS: Max variable size

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

Hi David,

On Sun, 5 Dec 1999, David Essex wrote:

> There is a problem with defining anything larger than 2**16, (65,536)
> bytes. This is because the max. size definable for .word type(2 bytes) is
> 2**16, (65,536).

Of course :)
  
>  2097 02ec C027     		.word	600000
> ****  Warning:Value 0x927c0 truncated to 0x27c0.

I will fix this soon, please wait. Really, this is one of our code
generation problems.  But I will give no "first class priority" to this
problem, so let me (1) finish the inspect stat; (2) help you with the
(really messy indeed) linkage section problem; (3) fixing or at least
starting to fix the accept stuff.  The reason is we want a useful compiler
for soon.
Well today I'm going out to visit my customer (consulting), so don't
expect too much, perhaps at night...

regards,
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/

[Tiny-cobol-users] BUGS: Max variable size

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

Hi All,

There is a problem with defining anything larger than 2**16, (65,536)
bytes. This is because the max. size definable for .word type(2 bytes) is
2**16, (65,536).
 
Fore example this,

01     TABEL-C.
   05    TAB-C1 OCCURS 10 TIMES INDEXED BY C1.
       10    TAB-C2 OCCURS 20 TIMES INDEXED BY C2.
        15    TAB-C3 OCCURS 300 TIMES INDEXED BY C3.
          25  TAB-C4                  PIC 9(05).
          25  TAB-C5                  PIC 9(05).

will generate this,

test02.s: Assembler messages:
test02.s:2097: Warning: Value 0x927c0 truncated to 0x27c0.

 2096              	# Field: TABEL_C, Stack loc: [bp-602416], Desc: v_base+748
 2097 02ec C027     		.word	600000
****  Warning:Value 0x927c0 truncated to 0x27c0.
 2098 02ee 470000   		.byte	'G',0,0
 2099              	# Field: TAB_C1, Stack loc: [bp-602416], Desc: v_base+753
 2100 02f1 60EA     		.word	60000
 2101 02f3 470000   		.byte	'G',0,0
 2102              	# Field: TAB_C2, Stack loc: [bp-602416], Desc: v_base+758
 2103 02f6 B80B     		.word	3000
 2104 02f8 470000   		.byte	'G',0,0
 2105              	# Field: TAB_C3, Stack loc: [bp-602416], Desc: v_base+763
 2106 02fb 0A00     		.word	10
 2107 02fd 470000   		.byte	'G',0,0
 2108              	# Field: TAB_C4, Stack loc: [bp-602416], Desc: v_base+768
 2109 0300 0500     		.word	5
 2110 0302 390000   		.byte	'9',0,0
 2111 0305 09030000 		.long	v_base+777	# v_base+309(hex)
 2112 0309 3905     		.byte	'9',5
 2113 030b 00       		.byte	0
 2114              	# Field: TAB_C5, Stack loc: [bp-602411], Desc: v_base+780
 2115 030c 0500     		.word	5
 2116 030e 390000   		.byte	'9',0,0
 2117 0311 15030000 		.long	v_base+789	# v_base+315(hex)
 2118 0315 3905     		.byte	'9',5
 2119 0317 00       		.byte	0


If you use a larger(.long or multiple .word combos) type you get a FP
overflow error. The problem code is in htcobgen.c, in the proc_trail function.


Rildo, you are the resident assembler expert, any way to fix this ?


David

[Tiny-cobol-users] Release available in Metalab

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

Hi,

Our newest version, taken from cvs tree, was released at metalab.unc.edu
(directory /pub/Incoming).  I suppose it's final address will be
/pub/Linux/devel/lang/cobol, but I'm not sure because there is no entry
for cobol (we are the pioneers!). I hope they will create the new
directory.

Our announce at Freshmeat was released, pointing to our ftp directory and
home page. Sorry, but there was no Metalab snapshot available at that
time. 
I expect a bunch of new contributors now
Who will coordinate the beta-testers?  Please don't let me exchange
mails with everyone, as I have plenty of things to code... ;)
We need soon a public relations person.

I haven't listened from Alan Duff and Tim Steen.  What are you doing
fellows?  Let's engage in some tasks or at least discuss something to do,
as we work better in group :)

best regards,
Rildo
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/