Home > Archive > Cobol > November 2005 > Re: COBOL-THREE-level table
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: COBOL-THREE-level table
|
|
| Judson McClendon 2005-11-23, 6:55 pm |
| Curious, I did a brief search for times I had used a 3 dimensional table
(don't think I ever used more than 3), and came up with the following. I
think the background for this program is interesting.
Back in the 80's I wrote a system called OBAR to collect obstetrical
history, problems and treatment information from OB/GYN doctors across the
county, then make that information available to any other OB/GYN in the
county to whom the mother might go for a problem or delivery. It was an easy
system to write, but boring, no challenge. As part of OBAR, they wanted a
separate but related Ultrasound component that collected a number of
measurements from the ultrasound exams, and for each exam print a data sheet
with graphic charts plotting fetal growth against norms using several
different formulas for calculating fetal growth. Everything but printing the
graphical charts was a piece of cake. But writing a COBOL program (the user
didn't have any other language programmers and wanted to be able to maintain
the program) on an EBCDIC mainframe to print a graphics chart on an 8-bit
graphics laser printer connected over a 7-bit ASCII communication line
running Burroughs/Unisys Poll/Select protocol was a seriously non-trivial
task. My client was convinced it was impossible without inordinate costs.
I started by writing a basic graphics library in COBOL, bit plot, line draw,
character draw, the works. For simplicity, I used 4-bit digits as 'bits',
which the Unisys A Series could easily access in COBOL. It was really
strange writing Bressenham's line drawing algorithm in COBOL. Anyway, that
was lots of fun and permitted creating a graphic chart in the COBOL program.
But the really fun part was printing the chart on the laser printer. I wound
up constructing the printer graphics command sequences in memory, breaking
them down into 6-bit chunks, translating those into EBCDIC characters which,
when translated to ASCII by the commuincations hardware, would result in
printable ASCII characters which, when bit shifted to the left, resulted in
the original 6-bit chunk. I sent these to the printer, delimited by escape
in and escape out character sequences. I then wrote an assembly language
printer driver that, when loaded onto the PCs where the laser printers were
connected, that were running the terminal emulation software that connected
the PCs and printers to the mainframe, would work normally until it saw the
escape in sequence denoting the beginning of the graphics chunks. The driver
then reassembled the chunks and sent them to the laser printer, until the
escape out sequence was encountered. It worked great, but explaining how
this worked to the MIS director caused his eyes to become a bit unfocused.
:-)
Anyway, below is a section of the table used for character plotting, and it
is a 3 dimensional table: character, bit-row, bit-column.
****************************************
**************************
* *
* L E T T E R B I T M A S K T A B L E *
* *
* THIS IS THE LETTER 'BIT MASK' TABLE FOR THE GRAPHICS *
* PRIMITIVE DRAW LETTER ROUTINE. *
* *
****************************************
**************************
01 LETTER-BIT-TABLE.
03 LBT-VALUES.
05 FILLER PIC X(01) VALUE "?".
05 FILLER PIC 9(08) COMP VALUE 01111100.
05 FILLER PIC 9(08) COMP VALUE 11000110.
05 FILLER PIC 9(08) COMP VALUE 11000110.
05 FILLER PIC 9(08) COMP VALUE 00001100.
05 FILLER PIC 9(08) COMP VALUE 00011000.
05 FILLER PIC 9(08) COMP VALUE 00011000.
05 FILLER PIC 9(08) COMP VALUE 00011000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00011000.
05 FILLER PIC 9(08) COMP VALUE 00011000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
*
...
*
05 FILLER PIC X(01) VALUE ",".
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00000000.
05 FILLER PIC 9(08) COMP VALUE 00001100.
05 FILLER PIC 9(08) COMP VALUE 00001100.
05 FILLER PIC 9(08) COMP VALUE 00001100.
05 FILLER PIC 9(08) COMP VALUE 00011000.
*
03 LBT-LETTERS REDEFINES LBT-VALUES
OCCURS 18 TIMES
INDEXED BY LBT-XLET.
05 LBT-LETTER PIC X(01).
05 LBT-ROW OCCURS 11 TIMES
INDEXED BY LBT-XROW.
07 LBT-BIT PIC 9(01) COMP
OCCURS 8 TIMES
INDEXED BY LBT-XBIT.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Chuck Stevens 2005-11-23, 6:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:Xf%gf.15900$s92.14365@bignews6.bellsouth.net...
> Curious, I did a brief search for times I had used a 3 dimensional table
> (don't think I ever used more than 3), and came up with the following. I
> think the background for this program is interesting.
It's not surprising that you didn't use more than three dimensions very
often; in ANSI X3.23-1974, anything beyond that is an implementor-defined
extension. ANSI X3.23-1985 increased this to require support for
seven-dimensional tables.
-Chuck Stevens
| |
| Judson McClendon 2005-11-23, 6:55 pm |
| "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> It's not surprising that you didn't use more than three dimensions very
> often; in ANSI X3.23-1974, anything beyond that is an implementor-defined
> extension. ANSI X3.23-1985 increased this to require support for
> seven-dimensional tables.
I don't remember ever using a compiler that didn't support more than three.
Didn't the old Medium System COBOL 68 compiler support subscripts up to the
limit imposed by having only 59 level numbers (i.e. 58)? Or am I imagining
that?
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Judson McClendon 2005-11-23, 6:55 pm |
| "Judson McClendon" <judmc@sunvaley0.com> wrote:
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> I don't remember ever using a compiler that didn't support more than
> three. Didn't the old Medium System COBOL 68 compiler support subscripts
> up to the limit imposed by having only 59 level numbers (i.e. 58)? Or am I
> imagining that?
Nope, I was wrong. I just referred to my trusty Burroughs Medium Systems
COBOL 68 Manual, and it only supported 3 levels of occurs/subscripting. I
couldn't find such a limit specified in the Medium Systems COBOL 74 manual,
perhaps that was it? I was sure that I had worked with a COBOL compiler
that, at least in theory, supported this many subscripting levels.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Chuck Stevens 2005-11-23, 6:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:jy4hf.16522$s92.10760@bignews6.bellsouth.net...
> I don't remember ever using a compiler that didn't support more than
> three. Didn't the old Medium System COBOL 68 compiler support subscripts
> up to the limit imposed by having only 59 level numbers (i.e. 58)? Or am I
> imagining that?
Dunno; I don't speak V Series COBOL that fluently (and I think you're
reaching back to the COBOLL and COBOLV days as distinct from LCOBOL, L7COBL,
L9COBL and B7COBOL!), and I don't have ready access to the manuals.
The Unisys MCP compilers seem to issue *warnings* if the dimensions exceed
3, not syntax errors (ANSI-related warnings for COBOL74, FIPS warning for
COBOL85). But I've successfully built a do-nothing program with fifteen
dimensions -- it compiles with both COBOL74 and COBOL85 and the produced
code executes -- but the COBOL74 compiler doesn't allow a record longer than
65KB, which kind of cramps what you might do with that many dimensions.
And, as I mentioned, it is always an extension if an implementor supports
more than three dimensions in an ANSI-74 implementation or more than 7
dimensions in an ANSI-85 implementation.
-Chuck Stevens
|
|
|
|
|