tiny-cobol-users

[Tiny-cobol-users] Compilation errors

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

I'm getting many errors in compilation.
We should get rid of even warnings at the pedantic level, no?
This would create confidence in the project.

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

[Tiny-cobol-users] I need a guru in stabs encoding.

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

Hi,

I found no way to make our gdb interface working within performs. The
problem is that cobol's perform is not really a sub-routine and I will
have to find another way to simulate single stepping through it.

If you know about any guru in those matters, please tell me how can I
contact him to get some answers.  It would be nice if we could single step
within performs as well. The only way to do now, is manually placing some
breakpoints and continuing (with "c") the execution.  
There must be a way to make this automatic!

BTW, I have announced again in Freshmeat. Let's see if we can get more
help from others. I have done also some (little) advances in the "inspect"
statement. Very sloooowly.

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] Debugging cobol source with gdb.

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

Hi Glen,

On Sat, 11 Dec 1999, Glen Colbert wrote:

> I'm starting to believe that Rildo is a programming GOD!

Really not so much, if you have the documentation handy ;^)

As I told before, I have found inside gdb docs a little paper called "The
stabs debugging format". It tells all the truth about those
mysterious stabs.  If you want, I can send it to you in postscript
(because gdb distribution is very large, circa 18MBytes, so you may be
discomfortable browsing inside it.)

A real hacker must know where to find 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] Debugging cobol source with gdb.

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

I'm starting to believe that Rildo is a programming GOD!

Glen

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Rildo
> Pragana
> Sent: Friday, December 10, 1999 12:36 PM
> To: tin...@ma...
> Subject: [Tiny-cobol-users] Debugging cobol source with gdb.
> 
> 
> Hi,
> 
> I have implemented the first steps for debugging Tiny Cobol source with
> gdb.  I have some docs about "stabs", just if you are curious how this
> works. 
> 
> There is not yet variable inspection, only single-stepping with source
> lines being listed, but I'm planning to make it available soon.
> 
> To debug, don't forget to assemble the .s file with the -g switch, or the
> stabs information will be removed.  The start gdb and put a breakpoint at
> "main" and use "n" to single step by the cobol source lines. Don't change
> the directory, because there is no path information in the file saved. In
> other words, make sure the source file is at the same directory as the
> object being debugged. You will see the source listed as the execution
> progress.
> 
> Enjoy!
> 
> 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] Volunteer (fwd)

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

Hi,

I received this e-mail from Pichai Asokan, from India. 

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: Sat, 11 Dec 1999 09:02:07 +0530
From: Pichai Asokan <pa...@os...>
To: rpr...@ac...
Subject: Volunteer

Hi
I am a Open Source enthusiast. I started life writing COBOL on an ICL mini.
I estimate that I have written close to 100,000 lines of COBOL code between
1984-89. I am currently consulting and also starting an Open Source Support
Company. I would like to know if I can contribute in any way. I have a lot
of experience writing course materials and in writing code in COBOL, C, C++,
Python
Let me know how I can help and I will try and assemble some more volunteers
from Chennai, India

P Asokan

PS: My Debian box is down. Goofed while potatoing :=% hence the mail from
Windows

[Tiny-cobol-users] More data types for debugging with gdb.

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

Hi,

I think I finished most of the work with the debuggin symbols generation.
Now, if I wanted something better I would be required to make internal
changes at gdb, much documented but not easy to do.  If you want to make
another parser, expression evaluator specific for cobol, iside gdb, please
go ahead.

What's working:
---------------
* you can place breakpoint at every line of the procedure division, the
same with watchpoints.

* you can display seamlessly DISPLAY variables, COMP variables, and to
with a lesser inconvenience, COMP-3. This last is defined as an array of
bytes, so you can only say something like "p/x COMP-3-VAR" to have a
display with the sign encoded (0xC or 0xD hexadecimal characters).

* that variables could be set to another value "set VAR=newvalue", as
expected.

What you cannot do:
-------------------
* referencing array variables (occurs) or variables that need further
qualification (VAR OF PARENTVAR).

* doing calculations in cobol style, as there is no cobol support inside
gdb. (again, if you want... make it!)


The way it is already have many interest, because it single-steps and can
evaluate anything with C-like expressions. If we make some auxiliary C
functions, we can make it more usable without the nightmare of patching
gdb's code.

Please try it. It will make your life easier for writing functions
for the cobol library, or even debugging cobol source.

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] Re: Tiny Cobol release 0.0.2 (fwd)

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

Hi,

I have announced our last release at the C.O.L.A. (comp.os.linux.archives)
newsgroup. Here is the mail I've received from the newsgroup moderator.

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: Sat, 11 Dec 1999 01:59:19 +0200 (EET)
From: mj...@ik...
To: Rildo Pragana <rpr...@ac...>
Subject: Re: Tiny Cobol release 0.0.2

I've just posted your article (the beginning of which is quoted below)
to comp.os.linux.announce.  It should show up in the newsgroup soon,
unless there are problems with the news flow.  If you haven't seen it
within three or four days after you get this letter, please notify me.
Thanks.

Note that I may have changed the subject line, added a Followup-to
header, and possibly done something else to the article to make it serve
the readers better.  Please check the article in the newsgroup and modify
your later announcements in a similar way.  Note that you do not have
to do things in exactly the same way, but something similar would be good.
For example, if you pick a Followup-to header yourself, it makes it easier
for me to process the announcement (which makes me work faster).  If I
modified the subject line, perhaps by adding a "LOCAL:" or "COMMERCIAL:" 
prefix, or changed "foo version 1.0 released" to "foo 1.0 - wysiwyg foo 
processor', then please make the subject of the next announcement similar.
(Put as much relevant information in the subject as possible, so that 
readers can pick interesting articles based on the subject alone.)

Mikko Rauhala, moderator.

> This article has been digitally signed by the moderator, using PGP.
> http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
> Send submissions for comp.os.linux.announce to: lin...@ne...
> PLEASE remember a short description of the software and the LOCATION.
> This group is archived at http://www.iki.fi/mjr/linux/cola.html

[Tiny-cobol-users] More debuggig options.

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

Hi,

Well, my friends.  Now I implemented the debugger's access of "usage is
display" variables.  You can get those variables listed (with correct
size, of course) inside gdb.  You only have access to the symbols when the
program is running, so please; 
   (1) start gdb with the object name; 
   (2) put a breakpoint at "main" (with the command: b main); 
   (3) run.
Then you can display any variable, but only makes sense to play with
"display" variables, as the others will show garbage. You can use the
gdb's command "x/x VAR" to get the value of a "usage is comp" variable, or
"x/b VAR" to do the same with a COMP-3, for each 2-digit values.
I will look for ways to show the properties (like the picture, for
instance) as well, and to convert other kind of variables for working
inside gdb.

Nevertheless, I don't think this is going to be easy, because gdb is
optimized for running C/C++ and Modula programs, _not_ Cobol.  So, there
are some ideosyncrasies of Cobol that it don't know. Sorry :(

There is a test ready to run in test.code/t16.  Run it as stated above and
execute "d ARRAY" to see what's the contents of 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] Hello

[Boris K. <BKo...@ge...>]

Rildo,

Olá compadre.  So Paulista, mas já som muitos anos que eu esto morando na america.

Currently we are running on an HP 3000 using HP's COBOL.  The 3000 is posixly correct so I suspect I can set things up in the POSIX space.

I guess I'll give it a try in the New Year and report my finding to you.  Besides GCC, what other (tools|utilities|software|*) do you think I may need?

Abraços

-- 
The opinions expressed are my own, especially if I'm right.
Linux the choice of a GNU generation http://www.linux.org
This includes COBOL http://www.gnu.org/software/cobol/index.html 
See my web page at http://users.erols.com/bpkprsnl/


>>> Rildo Pragana <rpr...@ac...> 12/10/99 11:39AM >>>
Hi Boris,

On Fri, 10 Dec 1999, Boris Kortiak wrote:

> After reading the web page I am still left with some doubts.
> Is Tiny COBOL ready for use in a development environment?

Maybe, maybe not. We are still missing some important statements like
"inspect" (being implemented now), the screen section, report section and
many smaller things.  Please notice we do not support ANSI-85 now, only
'74.  This will be left for the future (in a couple of months perhaps we
start to upgrade).

[Tiny-cobol-users] Help, please.

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

I would like to get another implementor for more libraries.  I stopped the
"inspect" statement to take care of our debugging, because it will make
our lives better when developing and testing cobol source.

I plane to make our variables (with type conversion, including COMP-3 and
COMP, as well as DISPLAY) viewable inside gdb. That's is a dream for
developers, I already know it! :)

If some of you could help us better doing other parts, I can concentrate
myself doing this more intriguing (and interesting, by that matter) part. 

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] Debugging cobol source with gdb.

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

Hi,

I have implemented the first steps for debugging Tiny Cobol source with
gdb.  I have some docs about "stabs", just if you are curious how this
works. 

There is not yet variable inspection, only single-stepping with source
lines being listed, but I'm planning to make it available soon.

To debug, don't forget to assemble the .s file with the -g switch, or the
stabs information will be removed.  The start gdb and put a breakpoint at
"main" and use "n" to single step by the cobol source lines. Don't change
the directory, because there is no path information in the file saved. In
other words, make sure the source file is at the same directory as the
object being debugged. You will see the source listed as the execution
progress.

Enjoy!

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] Hello

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

Hi Boris,

On Fri, 10 Dec 1999, Boris Kortiak wrote:

> After reading the web page I am still left with some doubts.
> Is Tiny COBOL ready for use in a development environment?

Maybe, maybe not. We are still missing some important statements like
"inspect" (being implemented now), the screen section, report section and
many smaller things.  Please notice we do not support ANSI-85 now, only
'74.  This will be left for the future (in a couple of months perhaps we
start to upgrade).
Anyway, your help is welcome. If you try to make some development with it
and find some bugs, I will be happy to try to fix them.  We intend our
tool to be used for real world applications.

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] Hello

[Boris K. <BKo...@ge...>]

After reading the web page I am still left with some doubts.

Is Tiny COBOL ready for use in a development environment?

[Tiny-cobol-users] More changes.

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

Hi,

I have implemented, as Andrew requested, a clause "KEY IS <alternate key>"
for the READ statement. I haven't tested it, though, just see it's
compiler output.

Now, the arguments for indexed files of the cob_read function are:

int
cob_read ( struct file_desc *f, char *record, struct fld_desc *fkey,
	char *keybuf );

The 2 last arguments refer to the key descriptor and storage. Please
notice that this is _not_ the function prototype, that continue to be:

int
cob_read( struct file_desc *f, char *record, ... );

This is only to make clear what is passed.  You shall use va_arg to read
the remaining parameters, after checking that the file organization is
indexed. The newer arguments return undefined objects for other file
organizations, so be careful.
 
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] Help testing please.

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

Hi,

I made several (many) changes for taking care of "usage is comp"
variables. Please look at test.code/t16.  There are 3 tests there, please
analyse each one.  I need help for doing more extensive testings and point
me where there are fails or bugs.  I'm no expert in cobol programming and
just want to make this tool to you, my friends. I am a C/yacc/lex/asm 
programmer, of course.

Please help doing the tests and pointing the mistakes or misunderstanding
of mine.  When reporting bugs to me, please don't just say "this don't
run", put what's expected as well and why :)  I thank you for your
interest.

The implemented stuff is already at our cvs repository, 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] Converted indices to use binary (usage comp) variables

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

Hi,

I have changed David's work a little, to allow use of binary variables as
indices, and introducing a new gen_set function to generate inline code
for doing the index calculations (it's much faster than calling a
C function).   Please revise it at test.code/t16.  Look at the assembly
code generated to understand what I mean :)

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] Updated section of Compiler-Overview.txt.

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

Hi,

I have updated the info/Compiler-Overview.txt file with a short
explanation (well, I tried...) of the internal workings of
subscripting/indexing for the compiler.  If someone is interested, please
go see it.

I have also updated our web pages, sent by David this morning.  It
reflects our new mailing list, ftp downloading area, and some links
including a full cobol parser from I*M.

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] (no subject)

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

> Also, as for handling run time errors, I would like to propose the
following
> calling convention:
>
>         void runtime_error(int iErrorNbr, struct fld_desc *pFldDesc, void
*pData);
>
I think we need a more complex pointer to the data.  We will need to display
working storage, i-o buffers, and pointers received in linkage.  A simple
... varargs would give us access to the data, but no method of identifying
what type of storage it is (buffer, linkage, etc.)

We can load the program name and compile date, compiler version, and other
relevent dump information as constants when creating the executable.

RE: [Tiny-cobol-users] Tiny Cobol

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

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Andrew
> Cameron
> Sent: Tuesday, December 07, 1999 12:54 PM
> To: tin...@so...
> Subject: Re: [Tiny-cobol-users] Tiny Cobol
> 
> 
> 
> Hi,
> 
> Welcome, I am glad to see another programmer who used DG Cobol for
> Data General.

I also have suffered through using DG Cobol :(
Glen 

Re: [Tiny-cobol-users] Command Line

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

Hi Glen,

At 06:47 PM 08/12/99, Glen Colbert wrote:
>Is anyone still using the -l option on the compile command line?  I would
>like to start on passing ld options crom the compiler command line.

Well get rid of it, then stop the compiler with and invalid option. This
should dicurage anyone from futher using it.

Also there is a bug that maybe you can look at. If you run htcobol with out
any command line arguments, it core dumps.


David

[Tiny-cobol-users] Command Line

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

Is anyone still using the -l option on the compile command line?  I would
like to start on passing ld options crom the compiler command line.

Glen

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

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

    First, a response to the message from Glen. I have used the ALL modifier
and am familiar with it, but am not familiar with the 'P' in the picture
clause (in 25 years of COBOL programming, I've never run accross it



    Jim,

    In 15 years, I've used it a total of twice (interest computation
intermediate fields on foreign currencies)



    Glen

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

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

Rildo,

Thanks for the explanation of the 'P' stuff, makes sense now.

Jim Noeth=20
> -----Original Message-----
> From:	Rildo Pragana [SMTP:rpr...@ac...]
> Sent:	Wednesday, December 08, 1999 9:46 AM
> To:	'tin...@so...'
> Subject:	RE: [Tiny-cobol-users] Runtime  Move Routine questions
>=20
> Hi Jim,
>=20
> On Wed, 8 Dec 1999, Noeth, Jim wrote:
>=20
> > I was out yesterday, and just finished reading all my email from
> yesterday.
> > I'll respond to multiple email messages in this message.
> >=20
> > First, a response to the message from Glen. I have used the ALL =
modifier
> and
> > am familiar with it, but am not familiar with the 'P' in the =
picture
> clause
> > (in 25 years of COBOL programming, I've never run accross it). I =
got the
> > book out and looked at all the various ways a picture clause can be
> > constructed, and I as such, I would like to add a precision field =
to the
> > fld_desc structure. This new field would contain the number =
(positive)
> of
> > 'P' characters on the right side of the picture clause, and the =
negative
> of
> > the number of 'P' characters on the left side of the picture =
clause. I
> would
> > also like to add one additional field to the structure that would =
be
> zero if
> > the field being described was unsigned, and non zero if the field =
is
> signed.
>=20
> Please look at this program fragment, taken from our compiler =
listings,
> and you will see that you don't need more variables in the fld_desc
> structure:
>=20
> 0014:       WORKING-STORAGE SECTION.
> 0015:       01 VAR1    PIC 9999V999.
> 0016:       01 VAR2    PIC VPP9.
> 0017:       01 VAR3    PIC 999PPPP.
> 0018:
>                                      vvvvvvv
> -------------------------------------------------+---------------
> Symbol ( Variables )      Type Level Len Dec Mul | Desc Loc  Pic
> -------------------------------------------------+---------------
>                       VAR1   9     1   7   3   1 | 0000 0007 000B
>                       VAR2   9     1   1   3   1 | 0012 0008 001D
>                       VAR3   9     1   3  -4   1 | 0024 000B 002F
> =09
> ^^^^^^^
> 									  =20
> The fields "Len" and "Dec" can give you the full information about =
scaling
> the
> number.  The first (VAR1) have 3 decimal digits. The second also, but =
only
> 1
> char in length, so it must be after the decimal point (of course).  =
The
> third
> (with a negative "Dec" value) tell us that we have "to shift the =
decimal
> point"
> to the right 4 digits, or we have to scale it by 10000.
> Each "P" means a shift in the decimal point but don't reserve storage =
for
> the
> digit. Play around with the compiler to look what those variables
> generate.
>=20
> The fld_desc equivalents are:  fld_desc->len for "Len" above, and
> fld_desc->decimals for "Dec" above.
>=20
> > Also, as for handling run time errors, I would like to propose the
> following
> > calling convention:
> >=20
> >         void runtime_error(int iErrorNbr, struct fld_desc =
*pFldDesc,
> void
> > *pData);
> >=20
> > Where iErrorNbr is a standard set of error numbers (we can use this =
to
> > obtain text to go along with the number). To get things moving =
along, we
> can
> > just write a stub routine, which can be extended later. I (like =
Glen)
> would
> > also like to see things like file name of the source file (which is
> pretty
> > easy) and the line number of the offending statement, but I don't =
know
> if
> > that data is easily obtainable at runtime.
>=20
> Well, I hope to have =E5 better picture of this, so I can understand =
what
> you
> mean.  If you just want the runtime to generate the source line with =
the
> problem, there is another way to generate it.
> =20
> > I would be interested in writing the math routines (multiply, add, =
etc.)
> > when I'm finished with the move routines, if no one else has =
started it
> by
> > then.
> 
> We already have both "move" and arithmetic routines.  The first one =
is
> very
> buggy. That's why I suggested it to be redone.  The arith functions =
we can
> do
> them again if we plan to change it to a multi-precision library (like
> gmp).
> They are working converting the numbers to/from double floats.
>=20
> > My last thing is a suggestion, which I realize may be a slight =
departure
> > from the way that the compiler has been developed. The suggestion =
is
> that
> > rather than building x86 assembly language straight out of the =
compiler,
> > that the compiler generate a relatively simple psuedo code, which =
can
> then
> > be translated into x86 assembly language. The reason is that =
porting the
> > compiler for a different processor is then made much easier,  just =
write
> a
> > new pseudo code translator for the new processor. Parsing the =
pseudo
> code
> > should be much simpler than parsing a complex language like COBOL.
>=20
> Perhaps we should generate C instead (the best intermediate =
language!),
> but
> this means a complete redesign of our code generator.  I have done =
already
> the
> first steps, but let us leave this to a future release.  We must =
first
> have
> this thing working according the standard cobol'74.  Then we can =
think of
> improvements and portings.
>=20
> best 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
>=20
>=20
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users

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

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

Hi Jim,

On Wed, 8 Dec 1999, Noeth, Jim wrote:

> I was out yesterday, and just finished reading all my email from yesterday.
> I'll respond to multiple email messages in this message.
> 
> First, a response to the message from Glen. I have used the ALL modifier and
> am familiar with it, but am not familiar with the 'P' in the picture clause
> (in 25 years of COBOL programming, I've never run accross it). I got the
> book out and looked at all the various ways a picture clause can be
> constructed, and I as such, I would like to add a precision field to the
> fld_desc structure. This new field would contain the number (positive) of
> 'P' characters on the right side of the picture clause, and the negative of
> the number of 'P' characters on the left side of the picture clause. I would
> also like to add one additional field to the structure that would be zero if
> the field being described was unsigned, and non zero if the field is signed.

Please look at this program fragment, taken from our compiler listings,
and you will see that you don't need more variables in the fld_desc structure:

0014:       WORKING-STORAGE SECTION.
0015:       01 VAR1    PIC 9999V999.
0016:       01 VAR2    PIC VPP9.
0017:       01 VAR3    PIC 999PPPP.
0018:
                                     vvvvvvv
-------------------------------------------------+---------------
Symbol ( Variables )      Type Level Len Dec Mul | Desc Loc  Pic
-------------------------------------------------+---------------
                      VAR1   9     1   7   3   1 | 0000 0007 000B
                      VAR2   9     1   1   3   1 | 0012 0008 001D
                      VAR3   9     1   3  -4   1 | 0024 000B 002F
									 ^^^^^^^
									   
The fields "Len" and "Dec" can give you the full information about scaling the
number.  The first (VAR1) have 3 decimal digits. The second also, but only 1
char in length, so it must be after the decimal point (of course).  The third
(with a negative "Dec" value) tell us that we have "to shift the decimal point"
to the right 4 digits, or we have to scale it by 10000.
Each "P" means a shift in the decimal point but don't reserve storage for the
digit. Play around with the compiler to look what those variables generate.

The fld_desc equivalents are:  fld_desc->len for "Len" above, and
fld_desc->decimals for "Dec" above.

> Also, as for handling run time errors, I would like to propose the following
> calling convention:
> 
>         void runtime_error(int iErrorNbr, struct fld_desc *pFldDesc, void
> *pData);
> 
> Where iErrorNbr is a standard set of error numbers (we can use this to
> obtain text to go along with the number). To get things moving along, we can
> just write a stub routine, which can be extended later. I (like Glen) would
> also like to see things like file name of the source file (which is pretty
> easy) and the line number of the offending statement, but I don't know if
> that data is easily obtainable at runtime.

Well, I hope to have å better picture of this, so I can understand what you
mean.  If you just want the runtime to generate the source line with the
problem, there is another way to generate it.
 
> I would be interested in writing the math routines (multiply, add, etc.)
> when I'm finished with the move routines, if no one else has started it by
> then.

We already have both "move" and arithmetic routines.  The first one is very
buggy. That's why I suggested it to be redone.  The arith functions we can do
them again if we plan to change it to a multi-precision library (like gmp).
They are working converting the numbers to/from double floats.

> My last thing is a suggestion, which I realize may be a slight departure
> from the way that the compiler has been developed. The suggestion is that
> rather than building x86 assembly language straight out of the compiler,
> that the compiler generate a relatively simple psuedo code, which can then
> be translated into x86 assembly language. The reason is that porting the
> compiler for a different processor is then made much easier,  just write a
> new pseudo code translator for the new processor. Parsing the pseudo code
> should be much simpler than parsing a complex language like COBOL.

Perhaps we should generate C instead (the best intermediate language!), but
this means a complete redesign of our code generator.  I have done already the
first steps, but let us leave this to a future release.  We must first have
this thing working according the standard cobol'74.  Then we can think of
improvements and portings.

best 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

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

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

To all,

I was out yesterday, and just finished reading all my email from yesterday.
I'll respond to multiple email messages in this message.

First, a response to the message from Glen. I have used the ALL modifier and
am familiar with it, but am not familiar with the 'P' in the picture clause
(in 25 years of COBOL programming, I've never run accross it). I got the
book out and looked at all the various ways a picture clause can be
constructed, and I as such, I would like to add a precision field to the
fld_desc structure. This new field would contain the number (positive) of
'P' characters on the right side of the picture clause, and the negative of
the number of 'P' characters on the left side of the picture clause. I would
also like to add one additional field to the structure that would be zero if
the field being described was unsigned, and non zero if the field is signed.

Also, as for handling run time errors, I would like to propose the following
calling convention:

        void runtime_error(int iErrorNbr, struct fld_desc *pFldDesc, void
*pData);

Where iErrorNbr is a standard set of error numbers (we can use this to
obtain text to go along with the number). To get things moving along, we can
just write a stub routine, which can be extended later. I (like Glen) would
also like to see things like file name of the source file (which is pretty
easy) and the line number of the offending statement, but I don't know if
that data is easily obtainable at runtime.

I would be interested in writing the math routines (multiply, add, etc.)
when I'm finished with the move routines, if no one else has started it by
then.

My last thing is a suggestion, which I realize may be a slight departure
from the way that the compiler has been developed. The suggestion is that
rather than building x86 assembly language straight out of the compiler,
that the compiler generate a relatively simple psuedo code, which can then
be translated into x86 assembly language. The reason is that porting the
compiler for a different processor is then made much easier,  just write a
new pseudo code translator for the new processor. Parsing the pseudo code
should be much simpler than parsing a complex language like COBOL.

Jim Noeth


> -----Original Message-----
> From:	Glen Colbert [SMTP:gco...@US...]
> Sent:	Monday, December 06, 1999 6:37 PM
> To:	tin...@so...
> Subject:	RE: [Tiny-cobol-users] Runtime  Move Routine questions
> 
> 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 
>