On Friday, 95/12/15, Murray Lesser wrote to David Noon about "Pl/i
Query" as follows:

ML> knowledgeable friend told me that I was having thunking problems,
ML> and suggested a couple of things to try.  Eliminating BYADDR as an
ML> attribute of a pointer variable was wrong; running the test case
ML> produced an address exception and died.

Hi Murray,

I think your "knowledgeable friend" was right. If the KBDKEYINFO
structure is to be passed BYADDR, then the pointer has to be passed
BYVALUE. This is also in conformance with IBM's include file, which
passes a HANDLE #KBDKEYINFO BYVALUE as the first argument to
KbdCharIn().

However, this approach of IBM's would seem to pass a 0:32 pointer to
KbdCharIn(), which would seem to be at variance from the API's
definition. I suspect it could be yet another buglet in their %include
files.

ML> The only reason I could
ML> tell that using the SEGMENTED attribute was the right thing to do is
ML> that I found the part of the "Language Reference" manual that told
ML> when thunking to 16-bit code, any BYADDR pointer must also be
ML> SEGMENTED; making that change had no effect on the performance of
ML> the test case!

Can you please post the snippet of code that does the getch()? Any
pointer passed to a 16-bit function or subroutine should be SEGMENTED,
whether passed BYVALUE or BYADDR. The SEGMENTED option applies to the
pointer itself, not its address, which should be "thunked"
automatically by the LINKAGE(PASCAL16) option.

ML>     But, I think he was absolutely right about it being a thunking
ML> problem.  Just to complicate matters, I inserted the part of my
ML> "_getch" that worked into my multitasking test case, compiled and
ML> linked it.  No compile errors, no link errors.  Then I ran it. 
ML> Disaster!  The background beeping continued until I pressed a key,
ML> just as it should. Then I got death message "IBM0951I ONCODE=3501 A
ML> system error occurred in PL/I multithreading support for the DETACH
ML> statement."

Did you do a STOP THREAD(...) before you did the DETACH THREAD(...)?
You can only detach a thread that has been waited for or forcibly
stopped (and is therefore no longer a candidate for dispatch).

ML>     I guess I need to RTFM the foot-long shelf of PL/I manuals a little
ML> more, and run a few more experiments, before I consult my friend
ML> again. I think I'll try a package, and put all the KBD API variables
ML> in static storage.  If this doesn't work, I'll try compiling for
ML> tiled memory.  As a last resort, I suppose I could learn a simple
ML> language; there is a demo of an OS/2 Pascal compiler in DevCon 9
ML> (honest, Carolyn, I'm only kidding!).

The TILED option affects the run-time library's handling of ALLOCATE
statements and function calls. The compiler is supposed to ensure that
automatic and static variables that appear as arguments to 16-bit
functions and subroutines do not cross "tile" boundaries, irrespective
of the TILED compiler option.

Regards

Dave


 * KWQ/2 1.2i * Read the docs. Wow, what a radical concept!
--- Maximus/2 3.00