[Info-vax] Coding Excel files...

[Paul Sture]

On 2014-02-12, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
> In article <ldftaf$4ll$1 at news.albasani.net>,
Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>>VAXman- @SendSpamHere.ORG wrote 2014-02-12 13:39:
>>> In article <52fafbba$0$8113$c3e8da3$3304c218 at news.astraweb.com>,
JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
>>>> On 14-02-11 18:54, VAXman- @SendSpamHere.ORG wrote:
>>>>> I'm not so certain I'd want to be jumping into kernel
>>>>> mode with BASIC.
>>>>
>>>> But isn't kernel mode the default for you, and you only have to worry
>>>> about things breaking on those rare occasions when you jump to user mode
>>>> ? :-)
>>>
>>> Pretty much so. :)
>>>
>>> I've been at SUPERVISOR mode in a lot of my time working on a DCL debugger
>>> I've mentioned here a few times.  I'd been called away from that in recent
>>> weeks to work on RMS CDC (EXEC mode), coded an Excel spreadsheet generator
>>> (USER mode) for a client that writes their app in COBOL (on OpenVMS),..
>>
>>That is, coding COBOL to create files in Excel/XLS format?
>
> COBOL is not a programming language! ;)

COBOL was the first attempt at cross-machine compatibility.  Oh, and
designed by committee :-)

<https://en.wikipedia.org/wiki/COBOL#History_and_specification>

"The first compilers for COBOL were subsequently implemented later that
year (1960), and on December 6 and 7, essentially the same COBOL program
ran on two different computer makes, an RCA computer and a Remington-Rand
Univac computer, demonstrating that compatibility could be achieved."

In my experience that compatibility meant lowest common denominator. The
earliest COBOL I worked with on DEC gear was one for RSX and IIRC the first
COBOL compiler for VMS was a compatibility mode version of that.  Because
these adhered to the COBOL standards of the time:

o - subroutine variables could be passed by reference only
o - no global variables

Calling system services was a simple matter of creating wrappers in
another lnaguage (FORTRAN or Macro in our case), but the lack of global
variable support was a performance killer because you had to make local
copies to pass to the COBOL, then copy back any modifications.

Fortunately the VAX-COBOL compiler which arrived circa VMS V3 had a bunch
of goodies which were expected to be incorporated in the COBOL 1985
specification, plus "DEC extensions" to make life easier on VMS.

There were compiler options to flag code using DEC extensions so that the
claim to compatibility could be maintained.  I was very glad I never had to
put that to the test.

> It was all done in C, so that it is callable from their COBOL code (is that
> the correct term for all that verbosity?), employing the class libraries of
> Perl that handle Data::Table, Spreadsheet::WriteExcel, Excel::Writer::XLSX.
> I had looked at the Python libs but my gray matter began to boil trying to
> figure out how to exploit/call its classes from C.  Also, they wanted logos
> displayed on the Excel spreadsheet, so I also took advantage of its Image::*
> class.  The most annoying part was having to install PERL so that I could
> build all of the classes.

COBOL verbosity isn't so bad when you have a decent editor and a bit of
imagination.  The last time I had a major file conversion project using
COBOL I used a mixture of DCL and COBOL to generate the COBOL programs
which actually did the work.

> Anyway, the customer now only needs to pass a descriptor to the data to be
> put in the spreadsheet, a filename for the spreadsheet and the file name of
> the logo (optional parameter) if desired.

I was about to say that "C is the new COBOL", but I recently read that
Java now has that honour - think millions of lines of code which helped
build empires.

--
Paul Sture