HP3000-L Archives

May 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Brown <[log in to unmask]>
Reply To:
Jeff Brown <[log in to unmask]>
Date:
Thu, 25 May 1995 22:20:36 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (93 lines)
In article <[log in to unmask]>, [log in to unmask]
says...
>
>In <[log in to unmask]> [log in to unmask] (Jeff Brown) writes:
>>
>>I have a compatibility mode program which calls a subroutine called
>>"GETSTAT" which I cannot find as either a "segment" or an "entry" in
>>either the account SL.PUB nor in SL.PUB.SYS.  The program is located
>>in the "PUB" group, and run with "Lib=P".  The program has been
>>exhibiting occasional strange behavior, and this is the one called
>>module that I cannot locate.
>>
>>Does anyone know where I can find this module, and what it does?
>
>Well, this is an incredibly long long shot, but there is a little-known
>SL called RTMSL.PUB.SYS.  This SL is *supposed* to be the "Run Time
>Monitor SL" which HP supplied to assist customers in converting from
>MPE/V systems to MPE/XL, but due to the fact that routines in this SL
>are silently loaded prior to their counterparts in the actual system
>SL, some vendors have used this to trap system calls without using
>procedure exits.  (Ironically, that is what it was intended to do in
>the first place, but the "trapped" calls simply logged the fact that
>the call was made, allowing HP to evaluate how existing CM programs
>utilized the system)
>
>Now, here is where the "long shot" comes in to play:  If the routine in
>question existed in your SYSTEM SL prior to a certain system updates or
>installation of third party softare, then either HP or the third party
>vendor would copy the system SL to RTMSL and then update the routines
>in RTMSL that they wanted to trap. (usually ignoring the other
>routines, but obviously removing those known to cause a conflict)  If,
>at some later date, you update the system with a new FOS, a
>brand-new-from-tape SL is loaded (which obviously doesn't have your
>routine in it), so the routine no longer shows up in a segmenter
>listing of SL.PUB.SYS, but gets loaded due to the fact that it DOES
>exist in RTMSL.
>
>Now, for what the routine does?  My guess (from the name and parm
>values) is that it retrieves the job control word known simply as
>"JCW".
>
>Tom Emerson
>[log in to unmask]
>
 
********************************************
 
Tom,
 
Thank you for your reply.
 
We do not have an SL called RTMSL.PUB.SYS, nor does RTMSL exist on any
group.account on our system, and PUB.SYS only contains the SL.PUB.SYS.
 
Your suggestion does remind me of another time I had to track down a
module which was not in the account SL (maybe it was even this one -
I have this vague feeling it was).  The solution then was that some
HP library had an undocumented entry point of the module name, so that
the code executed it.  I believe this came up during our upgrade to
the PA-RISC machine from a classic machine and the module then being
investigated somehow caused a security violation.
 
I suspect that it does do what you suggest, taking some bits or a byte
from the bigger result.  Here is a bit more of the code showing the
use of what is returned by GETSTAT:
 
 CHECK-SON.
 
   ... snip ...
 
     CALL    "GETSTAT"
       USING STAT-WORD,
             RETURN-STAT.
 
     IF    RETURN-STAT = 1
        AND FIRST-TIME-SW = 1
            PERFORM WAIT-MESSAGE-RTE
      ELSE
            NEXT SENTENCE.
 
     IF   RETURN-STAT = 0
           NEXT SENTENCE
      ELSE
           MOVE C-CHECK-SON-PAUSE-SECONDS
             TO SECONDS
           CALL    "PAUSECMD"
             USING SECONDS
           GO TO CHECK-SON.
 
 
Jeff Brown
[log in to unmask]

ATOM RSS1 RSS2