Re: [GNU-COBOL] New to list

[Fred Mobach <fred@mobach.nl>]

Davyd Ondrejko wrote:

> > Some comments are permitted, I hope.
>
> All things are permitted.
>
> > Alphanumeric fields : PIC strings contains A, X and 9 characters !
>
> Alphanumeric, or alphanumeric edited?

Alphanumeric fields are fields which can contain all possible codes. The picture
can be contructed as a combination of A, X and 9.  Although it should be treated
as if only X was used in the PIC string.


> > I never saw A0-A9 :-). Do you want to know how this translates to
> > ASCII?  That's difficult as I've never seen an official translation
> > tabel for the whole EBCDIC set.
>
> Really?  I have a full code table (00 to FF) translating from decimal to
> hex to binary, and which has the relevant codes for BCDIC, EBCDIC,
> ASCII, 7-track tape BCDIC, card code EBCDIC, and another column that I'm
> not evens sure *what* it is.  (The heading in the first page says "Inst.
> (RR)" and on the second page it's "Inst. (RX)"; I think it has something
> to do with assembler.)  If I remember correctly, that came from one of
> those IBM pocket manual thingys.  If you'd like a copy, I think I could
> send you one without getting *too* far into copyright infringement.

That would be great to get that copy. Please send it to :
Fred Mobach
Den Akker 8
4054 MD  Echteld
The Netherlands
Thanks in advance
BTW. The column with Inst. contains the mnemonic of the machine instructions. RR
means the instruction has more than 1 register operand. RX means 1 register
operand and 1 (indexed) memory location. You should find on other pages also SS,
which means operations with 2 memory locations as operands. No, I don't have that
copy, but it's the same on the Siemens BS2000 mainframes :-).


> > If the field is in USAGE IS COMP format the field is a binary numeric
> > field signed as usual on the target system.
>
> True.  The DOS/VSE compiler that I'm working on has a little additional
> quirk (which I think is also true on other compilers) that Gnubol may or
> may not want to implement.  Remember that the COMP field will take up 2,
> 4 or 8 bytes of storage depending on the PIC clause; a field defined as
> PIC S9(4) COMP will take up two bytes of storage, and so can hold a
> number up to around 32,767.  Even though it is defined as a 4-digit
> field, we (i.e., programmers where I work) often use those fields to
> hold five-digit numbers (below 32767, of course.)  No errors are
> generated, although a warning is issued in the compile listing.

You will only get that warning if you're using a constant greater than 9999, I
assume. Or is the DOS/VSE compiler so nice to check on the value boundaries after
each arithmetic operation ?


> > Fixed point without sign :
> > PIC  strings with 9 as placeholder for the numeric digits, V for the
> > place of the assumed decimal point and P for scaling.
> > If the field is in USAGE IS DISPLAY mode all cyphers are represented by
> > 0-9 and the value is assumed to be positive.
> > The usage of the USAGE IS COMP format is impossible as it always assumes
> > a sign.
>
> No, it isn't impossible; it's fairly common actually.  Just like USAGE
> IS DISPLAY, it's always assumed to be positive, and on many systems will
> then be able to store a higher value.  (For instance, the PIC S9(4) COMP
> field mentioned above could store a value of up to 65,535 if declared as
> unsigned.)

We're using different compilers. This will generate some traffic on this list in
the future. Do we have enought bandwidth ?


> > If the field is in USAGE IS COMP-3 format (the well-known BCD code
> > format) each byte holds two digits.
>
> Except the rightmost byte which holds one plus a sign indicator, as you
> mentioned above.

Saw this construction ( PIC 9(n) USAGE IS COMP-3) on Bull mainframes long ago.
Those systems could work with unsigned packed decimal and called it BCD
arithmetic.


> > The effect of SYNC in combination with USAGE IS COMP depends upon the
> > length of the field : alignment is done at the length of the field. If
> > the field is 2 bytes in length the alignment is done at a 16-bit
> > boundary, otherwise it's done at a 32-bit boundary. Note that (as far as
> > I know) Cobol support numeric variables at a maximum length of 18
> > cyphers.
>
> You should be also point out, for anybody reading this who might not be
> as familiar with COBOL, that the SYNC clause can *only* be used with the
> COMP clause.
>
> > Do you want to know how Cobol works with floating-point variables ? Just tell
> > me, but I have to investigate it as I've never used it before in Cobol :-).
>
> What do you mean by floating-point variables?  Things like PIC 99V9?

Not exactly, I mean variables like in common use in Fortran and Algol with
mantissa and exponent.

Regards,

Fred Mobach


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.