RE: [Cobolforgcc-devel] Runtime routines - confused

[William M. K. <wm...@ix...>]

Pardon me for "jumping it" (as I am now subscribed to this list).

A few comments included within (and some GENERAL comments at bottom)


> -----Original Message-----
 <snip>
>
> > >
> > > The "flags" field in the prototype for the cobr_display() routine was
> > > intended to pass arguments like trailing sign, and over punch.  This
> > > does present a small problem since it could imply an over punched sign
> > > for a binary type.  My books seem to indicate that only something with
> > > usage DISPLAY is permitted to use the "S" picture element.
>
> True so that some flag values would be invalid for some data
> types. You can either assume they are valid (so a pic x(n) would
> not even check the flag for leading overpunch), or check and
> abort() if inconsistent flags are used.

I haven't checked the '85 Standard yet, but this canNOT possibly be true (at
least in practice).
     PIC S(4) COMP (or BINARY)
is one of the most common data definitions that there is. Do you want me to find
a Standards reference to support this?

 <snip>

>
> > > On the other hand, if you are planing to add expanded functionality to
> > > the DISPLAY routine, then it would be better to keep the flag field.
> > > Perhaps special flags for languages, character sets, output to stderr
> > > instead of stdout.
>
> Yes, the number of possibilities can grow quickly. Although for
> display upon I would  probably have another routine with an extra
> parameter for the FILE*.

I assume that you are "planning" on allowing for DISPLAY to go to MULTIPLE
places.  For example in most of the current implementations you can do

   Display ... UPON CONSOLE
   DISPLAY ... UPON SYSOUT

in the same program (and they may well be "different" places (windows, or
whatever).

FYI,
  I assume that you know that the "UPON" phrase is SUPPOSED to be an "indirect"
reference to the place where output goes.  The relationship between this "name"
and the acutal place is put in the Special-Names clause.  However, almost (but
not quite all) vendors allow you to put the actual name in the DISPLAY (or
ACCEPT) statement.

  ***

General

Concerning PIC's with "S" and DISPLAY - are you aware that this is

A) an extension (but one that ALMOST all implementations allow)
B) not portable (with current implementations)

If you have

   05 NumField  Pic S99 Value -12.
        ...
   Display NumField

then,

IBM (mainframe, WinTel, and Unix) display *two* characters - with the last
character being the ALPHANUMERIC that has the same hex value as the single byte
for "-2".

On the other hand, MERANT display *three* characters "-12".  (Notice the
"switch" from sign-trailing to leading)

  ***

Again, concerning "S" and numeric fields.

Have you followed the debate on whether the following is or is NOT legal:

  05 NumField  Pic S999 Blank When Zero.

The problem beeing whether or not this is a numeric or numeric-edited field - or
not valid at all.  I beleive (but won't swear to it) that the committees (and
next Standard) have ended up saying that this is NOT valid.  However, the
following ARE valid.

  05 NumEdit1  Pic  99v99  Blank When Zero.
  05 NumEdit2  Pic  99ppp  Blank When Zero.

P.S.  That last raises the "question" of what you need to/should do with "P"
when doing a DISPLAY statement.

P.P.S. Another area for which there are multiple implementations is DISPLAY with
NO ADVANCING.

IBM returns to the beginning of the line - but "overwrites" it (no advancing).

MERANT (and most WinTel implementations) leave the "cursor" where it is so the
next Display FOLLOWS the last.

  ***

I hope this helps (and is appropriate input to this list)