On Sunday, 96/02/18, Murray Lesser wrote to David Noon about "Visual
Pl/i" as follows:

ML> but I deal with a magazine editor I respect who doesn't want any
ML> more text-mode applications, who gave me a "review" copy of VisPro
ML> Rexx 3.0 Gold to play with, and who claims he would love a review of
ML> Visual PL/I "for old times' sake!"

Hi Murray,

Your editor was probably jerking your chain, since he wants no more
text-mode stuff, but does want Visual PL/I. Surely "for old times'
sake" would apply to text-mode programs.

ML>     The default .MAK file (built by the system) uses LINK386 and a
ML> 5,000,000-byte stack.  It also insists on linking with /CO.  Is
ML> circa 5MB a reasonable stack size for PM programs?

I think 5MB is perhaps a little large, even if it is all virtual. The
foreground thread shouldn't be doing that much work, so it shouldn't
need more than 2MB. I presume your "mentor" is the same as mine on
this issue: Peter Elderon of IBM Santa Teresa labs.

ML>     I got the thing to link with ILINK but had to put in the
ML> NOFReeformat switch.  I even tried adding ".LIB" to the two
ML> default library names (CEELINK and IBMLINK) while in FReeformat
ML> (default ILINK) mode, but kept getting an NMAKE error 20, whatever
ML> that is.  (No NMAKE error list in the [expletive deleted] TOOLS.INF
ML> file for WarpTlkt!)  Is there any other way to influence the MAK
ML> file built by Visual PL/I (besides editing the MAK file before
ML> finishing the build) than the changes one can make on this notebook
ML> settings page?

The hard-copy docs are just as bad as TOOLS.INF, so you have to guess
what the error means. I think it means "I ran CMD.EXE and it went
wrong, so go figure" or something equally generic.

The creation of the .MAK file is performed by a utility called
MAKEMAKE.EXE. There are some parameters, but it is also documented
very thinly. I just let it do its thing and then fix it up later.

ML>     There are two top-left icons in the "Objects Toolbox"
title bar. The
ML> rightmost one has a diagonal line, normally.  When clicked on, it
ML> changes to another figure that is too small for my tired eyes to
ML> make out, but seems to do nothing else.  I couldn't find anything in
ML> the manual, or the HELP files, that explains this.  Any words of
ML> wisdom?

The other icon is a padlock. This determines whether or not the
toolbox window has its size locked or not. When it has the diagonal
line you need to click the icon before you can stretch the window;
when it has the padlock you need to click the icon to lock the size and
prevent the frame from being stretchable.

ML>     There doesn't seem to be any way to reset the *PROCESS defaults used
ML> by VPLI.  It insists on MARGINS(1, 100), and produces the
ML> source-code file to suit.  Somewhere, in some README, I thought I
ML> read that the left MARGINS parameter could not be less than 2.  Oh
ML> well, the tutorial case compiles, links, and runs--even though it
ML> doesn't do anything useful.

The left margin can be any number from 1 to the right margin minus 1.
It defaults to 2 because that is the most useful number for using the
mainframe compiler, which has a 3rd value in its MARGINS list.

ML>     For the multithreaded tutorial case, when I searched the .PLI
ML> source-code file, I found the ATTACH.  But no STOP/WAIT nor
ML> DETACH. Seems the thread kills itself when it is done, using a
ML> "WinTerminate" command.  I suppose one can have text-mode threads
ML> issue their own END commands if they know when they are finished. 
ML> (Supposition:  In this case, the main thread uses WAIT, before
ML> DETACHing the thread to release its resources.  Is supposition
ML> correct?)

The WinTerminate() API shuts down a PM anchor block, but does nothing
to the thread itself.

There is an implicit EXIT statement when returning from the PROC that
was named in the ATTACH, and this terminates the thread. However, the
caller, usually the main thread, should issue a WAIT and a DETACH too.
If the daughter thread has already completed then the WAIT is trivial,
but both should still be done.

ML>     Somehow, as someone who hasn't earned his living by programming
ML> since 1954, I tend to resent the assumptions made by programming
ML> tools that disagree with what I would have assumed if I were
ML> building the app from scratch.  However, I suppose a professional
ML> developer must accept the loss of control in favor of the time
ML> gained.  Most certainly, even I wouldn't bother with a PM app
ML> without a builder program.

Even though the code is not aesthetically pleasing, it does come out
of the visual generator like sausages coming out of a sausage machine.
I guess fillet mignon still has to be carved by hand.

Regards

Dave


 * KWQ/2 1.2i * If homebrew did not exist, it would be necessary to invent it.
--- Maximus/2 3.01