Excerpted from a message dated 01-16-99, Francois Thunus to Murray
Lesser:

 ML>     Seriously, I was trying to show Eddy what a complete (albeit
 ML> trivial) PL/I program looked like.  If you name the source file
 ML> containing my demo program TOUPPER.PLI, compile and link it, and then
 ML> key in the command line: "toupper This is a test" (no
quotes), you will
 ML> get back: "THIS IS A TEST" (without quotes) displayed on
your screen.

FT>When I wrote the upcase() I didn't really read the example, granted.
  >And when I read it, I thought it was an UpStr() procedure. I didn't
  >realize it was a complete program in itself.

Hi Francois--

     Probably my fault in naming it TOUPPER.PLI.  I started out to write
a procedure to be called by other programs, but I soon realized that it
was better to use the built-in translate() directly, each time it was
needed.  The "from" and "to" strings are only written
once, no matter
how many times translate() is used in a module, and irrespective of
which way the translation might be be made.  So I modified my unfinished
"called procedure" to take on the characteristics of a complete program
for my reply to Eddy's question.  For late entrants to this thread, here
is a repeat of the PL/I code in question:

*process langlvl(saa2), limits(extname(31)), libs, not('^'); 
 toupper: proc(infile) options (main noexecops);
    dcl infile char(100) var;
    dcl translate builtin;
    dcl (From value('abcdefghijklmnopqrstuvwxyz'),
         To value('ABCDEFGHIJKLMNOPQRSTUVWXYZ')) char(26);
 display (translate(infile,to,from));
 end toupper;

FT>...out of curiosity, how big would be the executable ? I'll write the
  >equivalent in Pascal and compile under Borland, Borland/2, speed 
  >pascal and VP just to have an idea. I know it's not always the size
  >that matters, but I'm curious. I've seen the size vary so much with
  >C compilers that I'm curious to make the same experiment with pascal
  >compilers.

    The executable size with the same PL/I compiler varies, depending on
the compiler and linker options used.  Before I give examples, I should
point out that the PL/I for OS/2 compilers, since v 1.2, have required
the use of ILINK, rather than LINK386 (IBM's older 32-bit linker).  (I
am now using VA PL/I for OS/2, v 2.0).  The 32-bit linker options I use,
given in the appropriate CONFIG.SYS linker environment variables, are:

      /STACK:0X200000 /BASE:0X10000 /PM:VIO /A:16 /E:2

    Since my IBM-written compilers for OS/2 make use of the OS/2
automatic stack control, the 2MB defined stack is a maximum value, not
the running value; I use it for all the PL/I (and the few C programs) I
write.  For compilers that make use of this facility, the actual stack
space in memory starts off as 4KB (one page), and is expanded as
necessary.  Thus, by using a very-large defined stack size, I avoid the
necessity of testing for stack overflow.  In fact, I'm not even sure
that such tests are available on my OS/2 compilers :-).  (Incidentally,
the Borland OS/2 C compilers did not make use of this OS/2 capability.)
The /A:16 option may increase the executable code size, but decreases
loading time.

    I have tested ILINK against LINK386 for programs compiled with my
old IBM C Set++ compiler (C only) using the same compiler options.  In
general, the executable code produced by ILINK is smaller than that
produced by LINK386 for the same object code.

    When compiling TOUPPER.PLI as written, and linking with ILINK as
noted above, the executable code comes out at 1296 bytes.  Of course,
this example is misleading because it is dynamically linked to the PL/I
runtime DLLs, which are always in residence in my system.

    If I recompile the same source code for static linking (to include
the runtime in the executable), it grows to 72000 bytes (same ILINK
options plus /NOE).  This is also misleading, because toupper is such a
simple program.  Usually, when I compile any of my little PL/I utilities
for static linking, the executable comes out in the neighborhood of 300
to 500 KB, because much more of the runtime is required than for this
simple demo.  The executable code for the same utilities with dynamic
linking will run 2 to 5 KB.  I usually compile a new program for static
linking as part of the development process, because the run-time error
checking seems to be more complete and errors have shown up that were
hidden in the dynamically linked executable.  Of course, when I am
satisfied with the utility, I recompile and relink it for dynamic
linking to save disk space.

    Hope this helps,

        --Murray

___
 * MR/2 2.25 #120 * Fidonet is almost like having a social life

--- Maximus/2 2.02