Comment embedded....
On 09/10/2012 07:12 PM, Paul Gilmartin wrote:
On Mon, 10 Sep 2012 18:20:46 -0500, Joel C. Ewing wrote:
Ways other than STCK/STCKE for getting time involve an SVC, or calling a
system service, or calling a subsystem service (CICS), where
front-ending the service is an obvious approach -- probably why the
question was raised specifically on how a hardware instruction like STCK
could be handled when there is nothing to front-end. Just replacing
what looks like an STCK in a module does carry some risk of corrupting
what is really a data field that just happens to have an "inconvenient"
value, unless Hourglass does a complete logic-flow analysis of the
module (doubtful) or allows for some manual guidance on what constitutes
data areas that shouldn't be checked. Even checking for an "STCK/STCKE"
surrounded by other instructions wouldn't be sufficient to eliminate the
possibility of a data field, since in some contexts (like target of an
EXecute), instructions themselves may be "data" and could be mixed with
other data fields.
Yup.
To do its thing, obviously Hourglass must also front-end those other
time services and not just deal with STCK./STCKE
But don't all those services funnel through STCK[E] at the base. How
else would one get the time? It would need to zap STCK[E]
instructions deep within those services. Risky business.
The intent of a product like Hourglass is to change time reality for a
specific application or batch job step without affecting the true system
time.
The only STCK[E] instructions that would be touched are in application
code after the application module is loaded into the specific address
space for which alternate time-reality was needed. Only in the case of
direct application code usage of STCK[E] is there is no alternative to
interception at the STCK level. STCK[E]'s in system code are not
touched. Aside from the noted technical problems posed by protected and
refreshable code and stability issues from the lack of 100% certitude in
identifying the instructions, there are interfaces that are available
at a higher level that allow the time result of a system service to be
"perturbed" for a single address space without having to work with
system code at the STCK level.
My recollection from our Y2K remediation efforts is that direct usage of
an STCK in application code rather than indirect usage via system
service calls or via some standard installation date/time routine, was
extremely rare. This leads me to suspect that a feature like Hourglass
application code STCK modification would only need to be enabled in
those rare cases where it was known to be needed, and providing some
external guidance on where to look for STCK instructions in the
application code in those rare cases would then also be feasible.
Joel C Ewing
I suppose one _might_ make a TCP/IP connection to port 13 or port 37
of a known timeserver. But why ever would one do that? (I've done it
to estimate clock skew, before we bought an ETR.)
How does it deal with STCK[E] instructions in LPA? And with REFRPROT?
And with UNIX System Services? I suppose most of these things funnel
through some point in Content Supervision where they can be hooked.
And the Java VM.
Are there any products that checksum their load modules, perhaps with
the purpose of preventing meddling with license key expiration?
Does CICS still bypass Content Supervision and load its own load
modules for performance reasons, as was discussed here lately?
On 09/10/2012 05:01 PM, Charles Mills wrote:
Yow!
What he said.
-- gil
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
