tiny-cobol-users

[Tiny-cobol-users] "Inspect replacing" implemented.

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

Hi,

Please the cobol experts here, test the "inspect .. replacing ..."
statement to see if there are bugs in it.  The tallying phrase was not
implemented yet, but anyway it's far easier to do. (I prefer to do the
most difficult part first :)
A short test is in test.code/t14.

Please report any inconsistency or misbehaviour fast, so I can move to
other things.  Thank you.

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

Re: [Tiny-cobol-users] (no subject)

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

I think BCD stands for binary coded decimal and the IBM implementation produces a binary number aligned to some boundary (byte, word, &c).  It is not a packed format.

As an aside BCD is part of EBCDIC: Extended Binary Coded ...

Of course I could be all wet.

>>> Fred Mobach <fr...@mo...> 12/14/99 12:00PM >>>
<snip>
A less common format was the BCD format. The difference with the packed
decimal format is the absence of the sign nibble. So a BCD format
numeric field of n bytes contains 2*n numeric positions, where a field
with packed decimal format of n bytes contains 2*n-1 numeric positions.
<snip>

Re: [Tiny-cobol-users] (no subject)

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

"Noeth, Jim" wrote:

> Glen (and others who commented on the move routines)
>
> Thanks for the feedback. I am using a 7 by 7 matrix to determine which
> type of move to generate (The compiler doesn't currently support all
> possible data types, but it probably will in the future). This results
> in 49 possible move types, although a number of them are illogical
> (such as moving an numeric edited field to a packed decimal field). I
> have started by defining each of this in a large case statement, so
> each of the move types does stand alone, but is all inline code as
> opposed to individual routines. Making individual routines out of them
> is a good idea, though, I will pursue that.
>
> My intent was to build the code for the move verb inline, as opposed
> to calling a routine to execute the move. This will result in a larger
> executable, but will not incur the overhead of pushing arguments onto
> the stack and calling a subroutine.
>
> By the way, the matrix is made  up of the following source/destination
> types (although not all are currently supported):
>
> Alpha/Alpha Numeric (no distinction is made)
> Binary Integer
> Display (numeric)
> Editted Alpha
> Editted Numeric
> Floating Point
> Packed Decimal

Perhaps it's pointed out before here, but because I don't know I'll do
it again.

The packed decimal format, which is still used on mainframes because it
saves memory and instruction cycles. It's not so fast as Integer binary
arithmetic but faster than Display numeric arithmetic. So programmers
should choose binary fields over packed decimal fields. But because of
the very old Cobol standard in those days they didn't : the binary
integer fields didn't have the possibility of the assumed decimal point,
which is really needed in business practice.

Over the years I've met two version of the packed decimal format.

Most common is the packed decimal format, where the right-hand end
nibble contains the code for the sign. In the sign nibble the F and C
codes indicate a positive value, the B and D codes a negative value.
Zero was in general coded as positive, but tests revealed me that a
negative zero didn't influence the results.

A less common format was the BCD format. The difference with the packed
decimal format is the absence of the sign nibble. So a BCD format
numeric field of n bytes contains 2*n numeric positions, where a field
with packed decimal format of n bytes contains 2*n-1 numeric positions.

I don't know if you intend to code the move for the BCD code fields in
the same routines as the packed decimal fields. If you do, fine.
Otherwise you might consider to make a 8 by 8 matrix.

Regards,

Fred Mobach

[Tiny-cobol-users] Alternate Record Keys.

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

Hi,

I have started to implement Alternate Record Keys.

So far the the open and close statements will open and close all the files
associated with alternate record keys.

The write statement will write out all the keys. I still need to code
logic to return the correct error codes.

I need to write the code for read, read next, read prev, delete and start.
This should be finished in the next few days. 

The system will create a seperate file for each alternate key. This file
will contain the alternate key as well as the master key. We then will use
the master key to read the data record.

See t04 for some idea of how it works.

Regards
Andrew
-----------------------------------------------------------------------------

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

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

Re: [Tiny-cobol-users] A question about serialization of inspect

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

Based on HP COBOL II (COBOL 85) the first case is what you should get.

>>> Rildo Pragana <rpr...@ac...> 12/14/99 10:47AM >>>
<snip>
INSPECT VAR REPLACING
    LEADING "AB" BY "CD"
    ALL "CD" BY "EF".

What should be expected after the execution: "CDABEF" or "EFABEF" ?
<snip>

RE: [Tiny-cobol-users] Coding Standard.

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

Hi,

I personally also prefer the K&R Style instead of GNU.
Adding the -bl option fixes the Brackets 
Perhaps we can use that standard.

ie
indent -kr -bl filename.c

The ideal is to attempt to use that same standard on each file. Failure to
to this will cause the whole file to be checked in each time with CVS.
How about  a comment line near the beginning of each file which shows what
switches were used with indent.
See the above example.

Regards
Andrew



On Mon, 13 Dec 1999, Glen Colbert wrote:

> Date: Mon, 13 Dec 1999 17:44:27 -0700
> From: Glen Colbert <gco...@US...>
> Reply-To: tin...@so...
> To: tin...@so...
> Subject: RE: [Tiny-cobol-users] Coding Standard.
> 
> > -----Original Message-----
> > From: tin...@so...
> > [mailto:tin...@so...]On Behalf Of Andrew
> > Cameron
> > Sent: Monday, December 13, 1999 10:41 AM
> > To: tin...@so...
> > Subject: [Tiny-cobol-users] Coding Standard.
> 
> > I would like to suggest that all C code be beautified by using the GNU
> > indent program with the gnu coding standard.
> 
> I'm probably the worst violator of these standards.  I can find my block
> errors easier if the starting and ending brackets stand alone on a line and
> are indented to the same level (as opposed to having the starting bracket
> appear where ever and the ending bracket indented by the level of nesting it
> implies).
> 
> This aside, we want this to become the GNU Cobol (Cobol is not quite an
> acronym).  I am willing to mangle my style in the interests of the project.
> I will, however, still write using my indention method, then run the code
> through a 'Mangler' to make it match the standard.
> 
> Would it be possible to compromise on this, leaving each of us to use our
> own style, then 'beautifying' or 'mangling' the source when we build a
> release?
> 
> Glen
> 
> 
> _______________________________________________
> 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] A question about serialization of inspect

[Bernard G. <ber...@cr...>]

Hi,

       Under VMS, the result is none of these: "CDCDEF". It seems to replace 
ALL LEADING "AB".

      Hope this helps,

Regards,

Bernard Giroud



I have a simple question about the inspect statement. Trying to make it
less complex, we can serialize the "inspect tallying" clause to make
each count separate, but the same doesn't seem to apply to "inspect
replacing".  For instance:

MOVE "ABABCD" TO VAR

INSPECT VAR REPLACING
    LEADING "AB" BY "CD"
    ALL "CD" BY "EF".

What should be expected after the execution: "CDABEF" or "EFABEF" ?

>>

[Tiny-cobol-users] A question about serialization of inspect

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

Hi,

I have a simple question about the inspect statement. Trying to make it
less complex, we can serialize the "inspect tallying" clause to make
each count separate, but the same doesn't seem to apply to "inspect
replacing".  For instance:

MOVE "ABABCD" TO VAR

INSPECT VAR REPLACING
    LEADING "AB" BY "CD"
    ALL "CD" BY "EF".

What should be expected after the execution: "CDABEF" or "EFABEF" ?

(sorry I don't have any cobol compiler to test it myself, just ours :)

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

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

Glen (and others who commented on the move routines)

Thanks for the feedback. I am using a 7 by 7 matrix to determine which type
of move to generate (The compiler doesn't currently support all possible
data types, but it probably will in the future). This results in 49 possible
move types, although a number of them are illogical (such as moving an
numeric edited field to a packed decimal field). I have started by defining
each of this in a large case statement, so each of the move types does stand
alone, but is all inline code as opposed to individual routines. Making
individual routines out of them is a good idea, though, I will pursue that.

My intent was to build the code for the move verb inline, as opposed to
calling a routine to execute the move. This will result in a larger
executable, but will not incur the overhead of pushing arguments onto the
stack and calling a subroutine.

By the way, the matrix is made  up of the following source/destination types
(although not all are currently supported):

Alpha/Alpha Numeric (no distinction is made)
Binary Integer 
Display (numeric)
Editted Alpha
Editted Numeric
Floating Point
Packed Decimal

Jim Noeth 

> -----Original Message-----
> From:	Glen Colbert [SMTP:gco...@us...]
> Sent:	Monday, December 13, 1999 6:36 PM
> To:	tin...@so...
> Subject:	RE: [Tiny-cobol-users] (no subject)
> 
> > -----Original Message-----
> > From: tin...@so...
> > [mailto:tin...@so...]On Behalf Of Noeth, Jim
> > Sent: Monday, December 13, 1999 10:00 AM
> > To: 'tin...@li...'
> 
> > 'gen_move'
> > routine to generate the code directly, all of the information to do
> these
> > 'overhead' calculations is available at compile time, and we
> > could generate
> > code that is very specific to each move statement.
> 
> Hi Jim,
> 
>   I think that the most supportable approach (in the long term) would be a
> routine for each source/target combination.  This would result in about
> 28-40 different move commands (depending on the number of numeric types
> that
> we define).  While this is a LOT more to program, it will allow individual
> tuning and troubleshooting.
> 
>   You should also consider that these move types are closely related to
> the
> math routines.....and each math routine will probably end by calling a
> move
> to move the data from a math library variable (FPU register, GNU Infinite
> Math type, or whatever) to numeric and/or numeric edited fields.
> Additional
> consideration may be needed for constants (MOVE -123.45 TO WS-NUMBER) as
> these seem to be treated differently by the compiler (what data type
> should
> we assign constants to)...
> 
>   To permit multiple programmers to work in the move libraries without
> tripping on each other, we should probably divide the move library into
> seperate source code based either on source or target data type (math
> would
> be easier if we divided by source, edited field moves would be easier if
> we
> divided by destination type).
> 
>   A nice feature would be to only link in the move code used by the
> program
> (multiple move and math libraries?), but this is probably overkill.
> 
> Glen
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users

[Tiny-cobol-users] Suggestion for change of test suite.

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

Hi Glen,

I suggest you make a small change in our test suite, so we don't need to
manually setup the path for our files. Please make the 

$CCX=gcc;$LD=gcc;$ASM=as;$COB=cob;$COBPP=cobpp

point to each argument in our directory tree, as everything is available
there, now that your test suite is inside our directories.  This way will
be easier for all developers just run cobol_test.pl.

Example: COB=../compiler/htcobol

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

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

Hi Glen,

Thanx for the report. I hope there are no other bugs with it.
BTW, we don't need to link lib/mccntrl.s, for there will no exit_procedure
anymore.

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

RE: [Tiny-cobol-users] More changes (required by Andrew)

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

Rildo,

  I think your perform changes may have broken something.

########################################################################
# GO TO Within PERFOR                                                  #
# Test Directory: perform_tests             Test File perf05           #
########################################################################

 P005:  FAIL PERFORM PIC 9(4) TIMES TEST : Expecting (0027) got (0000)
  GO TO Within PERFOR                                                :
FAILED

This is a test where there is a GO TO within a perform.  It was working up
till today.

[Tiny-cobol-users] Thought

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

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

RE: [Tiny-cobol-users] Coding Standard.

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

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Andrew
> Cameron
> Sent: Monday, December 13, 1999 10:41 AM
> To: tin...@so...
> Subject: [Tiny-cobol-users] Coding Standard.

> I would like to suggest that all C code be beautified by using the GNU
> indent program with the gnu coding standard.

I'm probably the worst violator of these standards.  I can find my block
errors easier if the starting and ending brackets stand alone on a line and
are indented to the same level (as opposed to having the starting bracket
appear where ever and the ending bracket indented by the level of nesting it
implies).

This aside, we want this to become the GNU Cobol (Cobol is not quite an
acronym).  I am willing to mangle my style in the interests of the project.
I will, however, still write using my indention method, then run the code
through a 'Mangler' to make it match the standard.

Would it be possible to compromise on this, leaving each of us to use our
own style, then 'beautifying' or 'mangling' the source when we build a
release?

Glen

RE: [Tiny-cobol-users] (no subject)

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

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Noeth, Jim
> Sent: Monday, December 13, 1999 10:00 AM
> To: 'tin...@li...'

> 'gen_move'
> routine to generate the code directly, all of the information to do these
> 'overhead' calculations is available at compile time, and we
> could generate
> code that is very specific to each move statement.

Hi Jim,

  I think that the most supportable approach (in the long term) would be a
routine for each source/target combination.  This would result in about
28-40 different move commands (depending on the number of numeric types that
we define).  While this is a LOT more to program, it will allow individual
tuning and troubleshooting.

  You should also consider that these move types are closely related to the
math routines.....and each math routine will probably end by calling a move
to move the data from a math library variable (FPU register, GNU Infinite
Math type, or whatever) to numeric and/or numeric edited fields.  Additional
consideration may be needed for constants (MOVE -123.45 TO WS-NUMBER) as
these seem to be treated differently by the compiler (what data type should
we assign constants to)...

  To permit multiple programmers to work in the move libraries without
tripping on each other, we should probably divide the move library into
seperate source code based either on source or target data type (math would
be easier if we divided by source, edited field moves would be easier if we
divided by destination type).

  A nice feature would be to only link in the move code used by the program
(multiple move and math libraries?), but this is probably overkill.

Glen

Re: [Tiny-cobol-users] Move implementation.

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

Ted Rolle wrote:

> Well, as a COBOL/S370 assembler fan, I can assure you that is the way the
> IBM COBOL compiler works.
>
> Having a 'generalized' MOVE routine would involve much overhead and
> require a lot of tweaking and changes whenever someone comes up with a
> new idea.
>
> I vote for a 'lean and mean' type-specific MOVE.  It would localize
> changes and result in faster code.

As being a Cobol / Siemens Assembler fan I'll support this vote. Thank you Ted, you're
completely right.

Regards,

Fred Mobach

Re: [Tiny-cobol-users] More changes (required by Andrew)

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

Thanks.

I will test and contiue with the Alternate Routines.

Regards
Andrew

On Mon, 13 Dec 1999, Rildo Pragana wrote:

> Date: Mon, 13 Dec 1999 17:06:12 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> Reply-To: tin...@so...
> To: tin...@ma...
> Subject: [Tiny-cobol-users] More changes (required by Andrew)
> 
> Hi Andrew,
> 
> Here are the other change. Now you have another DB* field at the
> alternate key descriptor.  I don't stopped to think too much about this,
> but I understand what you mean.  I hope this is all you need now :)
> 
> Please, someone (Glen, maybe) check our current version doesn't introduced
> any serious bug. I have no time to check all the test code to see if it's
> working now.
> 
> Keep the good work my friends.
> 
> best regards,
>  ----------------------------------------------------------------
>  Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
>  P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
>  Brazil 54792-990              +55-81-459-1776
> 
> 
> _______________________________________________
> 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 changes (required by Andrew)

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

Hi Andrew,

Here are the other change. Now you have another DB* field at the
alternate key descriptor.  I don't stopped to think too much about this,
but I understand what you mean.  I hope this is all you need now :)

Please, someone (Glen, maybe) check our current version doesn't introduced
any serious bug. I have no time to check all the test code to see if it's
working now.

Keep the good work my friends.

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

[Tiny-cobol-users] Sorry, a little mistake.

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

Hi Andrew,

I have made a mistake in my previous patch. Please try with this other.  I
have put my field in the wrong place.
Now I think it's correct.  (I have no way to fully test, though)

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] Changes in file_desc (htcoblib.h)

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

Hi Rildo

Thanks.

I also need altkey_desc modified to include 
DB *alt_dbp;         /* pointer for libdb for Alternate key operations */
so I can store the File Handle for each of the Alternate Key files.

Regards
Andrew Cameron

On Mon, 13 Dec 1999, Rildo Pragana wrote:

> Date: Mon, 13 Dec 1999 16:37:28 -0200 (EDT)
> From: Rildo Pragana <rpr...@ac...>
> Reply-To: tin...@so...
> To: tin...@ma...
> Subject: [Tiny-cobol-users] Changes in file_desc (htcoblib.h)
> 
> Hi Andrew,
> 
> I have added at the end of file_desc, just before the alternate keys
> array, a new field.  It is a (struct altkey_desc *key_in_use) pointer you
> shall store the alternate key when opening the file, or NULL if the master
> key is used instead.
> I hope this will make you progress.
> 
> 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] Changes in file_desc (htcoblib.h)

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

Hi Andrew,

I have added at the end of file_desc, just before the alternate keys
array, a new field.  It is a (struct altkey_desc *key_in_use) pointer you
shall store the alternate key when opening the file, or NULL if the master
key is used instead.
I hope this will make you progress.

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

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

Nahhh... I'm pedantically referring to the capitalization...
Both are acronyms:  COBOL stands for Common Business-Oriented Langage and
GNU (recursively!) stands for GNU's Not Unix

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

On Mon, 13 Dec 1999, Rildo Pragana wrote:

> Hi Ted,
> 
> On Mon, 13 Dec 1999, Ted Rolle wrote:
> 
> > Cobol is COBOL; Gnu is GNU.
> 
> Now we have both of them in our project. (the best of both worlds)
> I'm not a Cobol programmer, but I think it should be very productive for
> you, as all cobol programmers I know are diligent advocates :)
> 
> 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 Ted,

On Mon, 13 Dec 1999, Ted Rolle wrote:

> Cobol is COBOL; Gnu is GNU.

Now we have both of them in our project. (the best of both worlds)
I'm not a Cobol programmer, but I think it should be very productive for
you, as all cobol programmers I know are diligent advocates :)

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] Coding Standard.

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

Hi,

I would like to suggest that all C code be beautified by using the GNU
indent program with the gnu coding standard.

Any Comments.

Regards
Andrew

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

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

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

[Tiny-cobol-users] Cobol Alternate Keys

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

Hi,

Rildo I have been giving the Alternate keys some thought. 

Please could you amend the structure that is passed to the open statement
to include a file ident field for  the alternate key structure. 
In order to handle Alternate Keys with the
current implementation of DB we will need a seperate file for each
alternate key. This will will contain the Alternate key and the master
key.

The key that is being used for all reads will be set either by START or
READ ... KEY IS. This  key is used for all Indexed access until such time
as it is changed by another START key is of READ .. Key is.

Regards
Andrew Cameron

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

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

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