[Info-vax] Coding Excel files...

[Paul Sture]

On 2014-02-12, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
> In article <ldg9ak$soa$1 at news.albasani.net>,
> Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>>{...snip...}
>>
>>Not at all. The data is usualy in some Rdb table (written by the
>>Cobol applications) and some batch job runs Python and creates
>>the XLS files (using the Python Rdb interface and the Excel
>>tools). Sometimes the Cobol code submittes the batch job or
>>it can be done using a table trigger.
>
> Good grief.  I hate COBOLlers LIB$SPAWNing shit all over the place.  I hate
> it even more when the LIB$SPAWN a SUBMIT command.

If you do need to submit a job, you can do it straight from COBOL, though
our approach was to supply a wrapper routine to make it easy for the
typical coder, with suitable defaults for omitted parameters.

The problem with COBOL (OK, OK, *one* problem with COBOL) is that unlike
BASIC, FORTRAN etc, the VMS compiler doesn't come with system header files
to include at compile time.

Yes, you can write some reasonably simple DCL to extract stuff from the
libraries and generate COBOL variable definitions, but that's potentially
a time bomb across VMS versions.  It was preferable to hard coding
status returns into each COBOL program (which was the way it was done
in the few system call examples in the manuals), but was far from perfect.

A neater solution is to write simple macro to pull those values in as
globals and let the linker do its stuff.  E.g.

----
; UAIDEF.MAR

        $uaidef GLOBAL  ; define as global
        .end
----

and in COBOL, variable definitions of the form:

01 ss$_normal pic 9(9) comp value external ss$_normal.

>
>>Another Cobol app writes data to a table and a table trigger
>>submittes a job that uses the Python PDF ("ReportLab") tools
>>to create PDF reports (accessed through the web server, WASD).
>
> So, if I've read you right, you're running a Python script in a BATCH job to
> convert tabled data to XLS.
>
>
>
>>I'm sure Perl works fine also, but I personaly don't like Perl. :-)
>>Python feels more "modern" and structured.
>
> No real PERL (save to figure out how well the class libraries handled the
> Excel output.  I link those bits into C code which the customer can call
> from their COBOL.  The most COBOL I ever wrote was to show them how to do
> the call.  Strange, they'd never seen the:
>
>   INSPECT blah-blah TALLYING blah-blah-LEN FOR CHARACTERS BEFORE SPACES.
>
> ...syntax before I'd used it.  I thank Google for that COBOL syntax.

Google wasn't around when I looked at the INSPECT...TALLY-HO stuff

     CALL STR$TRIM using ...

was much more readable and a lot less typing too.

>
> They then invoke the call:
>
>   CALL "Table2Excel" USING BY DESCRIPTOR table-data-descriptor
>                            BY DESCRIPTOR Excel-FILE(1:Excel-FILE-LEN)
>                            BY DESCRIPTOR Image-FILE(1:Image-FILE-LEN)
>                            BY DESCRIPTOR "Orange"  <==header bg color
>                            BY DESCRIPTOR "Black"   <==header fg color
>                      GIVING RET-STATUS.

That can be shortened by omitting the "BY DESCRIPTOR" on all lines but the
first.  BY REFERENCE is the default if you don't specify anything, but once
you specify an argument type it becomes the default for the remaining
parameters.

Note that COBOL doesn't support anything but BY REFERENCE for receiving
routines.  If you ever find yourself in the unlikely position of wanting
to do that LIB$ANALYZE_SDESC (or do I mean STR$ANALYZE_SDESC???) is your
friend.

>
> There's no need for unnecessary process creation and waiting about for
> that process to complete.  It's all done, and quite quickly too, in the
> context of the caller.

That's fine if it's quick, but back in the days of one VT per desk and
slow VAXen you risked tying down someone's terminal for an unacceptable
amount of time waiting for a report to finish.  I converted a whole
slew of programs which did that to (optionally) submit a batch job and
free the terminal up immediately.

--
Paul Sture