Reusable Server Kernel

Problem 47 (Minor): BKWDEC stores into x'0010' causing PIPCMS1178W using PIPE command

=============== 2003-06-25 15:35:06 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Fixed in /rsk/rskfix.vmarc posted today.
=============== 2003-06-23 10:58:11 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Not sure if this forum is still valid??  
If so...
I'm using the updated version of the RSK from the RSK page on CMS 16.  Under the RSK, running assembler code I call CMS via CMSCALL to run a REXX exec.  This REXX exec issues a simple PIPE command ("PIPE < TEST1 EXEC A | Hole").  PIPE issues this warning:
PIPCMS1178W The pointer to the Contents Vector table has been restored from the alternate pointer.
According to John Hartmann on the CMS Pipelines list, this means that PIPE has noticed that someone changed the contents of location x'00000010', which is ACMSSCVT, or the simulated OS CVT (I don't know what that is).
I simplified my application so that it does as little as possible and was still able to repro the store into addr x'10'.  The store occurs from two locations:
BKWDEC+5C6: ST    50E0A010 >> 00000010    CC 2
BKWDEC+6FE: CS    BA132000 >> 00000010    CC 0
I start by IPL CMS to be starting as clean as possible.  I setup three traces: TRACE ST INTO 10.4, TRACE I R BKWDEC+5C6, and TRACE I R BKWDEC+6FE.  (Resolving BKWDEC+xxx by hand). I then invoke my mini-application on the RSK.  I then use my IUCV client to send a message to the server.  The server will do nothing more than IUCV SEVER the client on receipt of the message.  My service routine (set by call to ssServiceBind) does:
1) Address c-Block
2) Setup & call QueueSend() with VMSS_LMSG's VL_IBITS set to VL_B_STOPACK (only bit turned on) and the VMQUESE_PLIST setup with info from the c-Block.
3) Exit (back to whatever calls the service routine)
The call to QueueSend() exits with RC=0 (Reason=0) and my client shows a SEVER, so I'm sure it is setup correctly.
At this point I either see the exit from my service routine, followed by trace hits in BKWDEC...*OR* I see hits in BKWDEC followed by the exit from my trace routine.  Sounds like BKWDEC is probably executing on a different thread?
Here are the trace hits I get in BKWDEC (I get all four, just like this, each and every time I send a msg to the server...that is, four hits per call to QueueSend to terminate the connection):
BKWDEC+6FE: CS    BA132000 >> 00000010    CC 0
BKWDEC+5C6: ST    50E0A010 >> 00000010    CC 2
BKWDEC+6FE: CS    BA132000 >> 01F899E8    CC 0
BKWDEC+5C6: ST    50E0A010 >> 01F899E8    CC 2
Note that the first time the traces hit they are manipulating address X'10'.  The second time they hit they are manipulating something a bit more valid looking (1F899E8).  At BKWDEC+5C6, R10=01F899D8.  Here's what's at that address:
D T0.100;BASE10
R01F899D0  00000000 00000000 E2C5D9E5 C9C3C540 E6 *........SERVICE *
R01F899E0  E3C5E2E3 D4F14040 00000000 00000004    *TESTM1  ........*
R01F899F0  00000000 0000000C 00000000 00000000    *................*
R01F89A00  00000000 00000000 00000000 00000000    *................*
R01F89A10 to 01F89ADF suppressed line(s) same as above ....
Note that "TESTM1" is the name of my "service".  
So, we have:
BKWDEC does this thing with CS and ST not once, but twice.  Odd?  The first time it looks like garbage and second time might be valid?
Ok, so I have a problem and a concern.
My problem is getting PIPE to stop complaining.  My concern is that this store into X'10' is an error and may lead to other problems down the road as the server is doing its thing.
Thanks,
John