Global variables at the Address Space level 
Author Message
 Global variables at the Address Space level

Hi All,

I'm adding trace logic to a multi-task address space.  I'd like to
create some Global variables at the address space level to control
what gets traced and when.  I realize that this can be implemented via
callable token services IEANTCR and IEANTRT, but those routines look
like more overhead than I'm comfortable with, considering how often
these things will be accessed.  Are there any 4 byte areas
specifically reserved for user modification in any of the system
control blocks at the A/S level that I can step to myself via the CVT?
If not, does anyone have any other suggestions?

TIA,
Wayne



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level
: Hi All,

: I'm adding trace logic to a multi-task address space.  I'd like to
: create some Global variables at the address space level to control
: what gets traced and when.  I realize that this can be implemented via
: callable token services IEANTCR and IEANTRT, but those routines look
: like more overhead than I'm comfortable with, considering how often
: these things will be accessed.  Are there any 4 byte areas
: specifically reserved for user modification in any of the system
: control blocks at the A/S level that I can step to myself via the CVT?
: If not, does anyone have any other suggestions?

: TIA,
: Wayne

How about TCBUSER for the job step task?
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:
>Hi All,

>I'm adding trace logic to a multi-task address space.  I'd like to
>create some Global variables at the address space level to control
>what gets traced and when.  I realize that this can be implemented via
>callable token services IEANTCR and IEANTRT, but those routines look
>like more overhead than I'm comfortable with, considering how often
>these things will be accessed.  Are there any 4 byte areas
>specifically reserved for user modification in any of the system
>control blocks at the A/S level that I can step to myself via the CVT?
>If not, does anyone have any other suggestions?

>TIA,
>Wayne

Well, since that is what Name/Token services are designed for,
they should be blazingly fast.  Wouldn't surprise me if the path
length were a few dozens of instructions.  Even if it were a
thousand, you wouldn't notice it.

Cheers,
Greg



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:

> Hi All,

> I'm adding trace logic to a multi-task address space.  I'd like to
> create some Global variables at the address space level to control
> what gets traced and when.  I realize that this can be implemented via
> callable token services IEANTCR and IEANTRT, but those routines look
> like more overhead than I'm comfortable with, considering how often
> these things will be accessed.  Are there any 4 byte areas
> specifically reserved for user modification in any of the system
> control blocks at the A/S level that I can step to myself via the CVT?
> If not, does anyone have any other suggestions?

> TIA,
> Wayne

You could LOAD a load module that was actually a dirty area and then
either do a LOAD/DELETE sequence to find it(rather slow) or you could
just chase the CDE chain.

I would stick with the Name Token pair.

--

Beyond Software, Inc.      http://www.beyond-software.com
"Transforming Legacy Applications"



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level
Instead of LOAD/DELETE, use CSVQUERY to locate a module that has been
previously LOADed.
Quote:


> > Hi All,

> > I'm adding trace logic to a multi-task address space.  I'd like to
> > create some Global variables at the address space level to control
> > what gets traced and when.  I realize that this can be implemented via
> > callable token services IEANTCR and IEANTRT, but those routines look
> > like more overhead than I'm comfortable with, considering how often
> > these things will be accessed.  Are there any 4 byte areas
> > specifically reserved for user modification in any of the system
> > control blocks at the A/S level that I can step to myself via the CVT?
> > If not, does anyone have any other suggestions?

> > TIA,
> > Wayne

> You could LOAD a load module that was actually a dirty area and then
> either do a LOAD/DELETE sequence to find it(rather slow) or you could
> just chase the CDE chain.

> I would stick with the Name Token pair.

> --

> Beyond Software, Inc.      http://www.beyond-software.com
> "Transforming Legacy Applications"



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:

> I'm adding trace logic to a multi-task address space.  I'd like to
> create some Global variables at the address space level to control
> what gets traced and when.

Is this code for your own local use, or is it going out as a product?

Quote:
>I realize that this can be implemented via
> callable token services IEANTCR and IEANTRT, but those routines look
> like more overhead than I'm comfortable with, considering how often
> these things will be accessed.

How often are we talking about? If you mean hundreds or more times per
second then the name token code won't help. You probably need to access your
data in a few instructions via a well known path. However if the frequency
is less than that tokens are probably ok. Their average pathlength isn't
very long and they support lots of different execution modes.

Quote:
>Are there any 4 byte areas
> specifically reserved for user modification in any of the system
> control blocks at the A/S level that I can step to myself via the CVT?

In theory CVTUSER, TCBUSER are available for customer use. But they are so
often abused that vendors now shy away from it. It's a recipe for disaster
if its code for public consumption. Otherwise you could use it - provided it
wasn't already in use by vendor code or some other hokey local program.

Quote:
> If not, does anyone have any other suggestions?

How would you propose to set those values? Most system control blocks are
key zero. You need to be authorized for that. If you are able to run
authorized at all there are quite a few sneaky things you could do to stash
your information so it can be accessed quickly.

Do you control the code that is running within the address space, or is it
just any old code that someone wants to trace? If you control it, then you
have a wealth of options. If you don't there are still some good choices,
but you have to be a lot more carefull. More information please!



Mon, 16 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level
CSVQUERY is typically much faster than LOAD, but both are at least an order
of magnitude more than IEANTRT (maybe two or more). Wayne K. wanted
something FAST.
Quote:

>Instead of LOAD/DELETE, use CSVQUERY to locate a module that has been
>previously LOADed.


>> > I'm adding trace logic to a multi-task address space.  I'd like to
>> > create some Global variables at the address space level to control
>> > what gets traced and when.  <SNIP>>>
>W> You could LOAD a load module that was actually a dirty area and then
>W> either do a LOAD/DELETE sequence to find it(rather slow) or you could
>W> just chase the CDE chain.
>W>
>W> I would stick with the Name Token pair.



Tue, 17 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level
On Thu, 29 Oct 1998 17:21:26 -0600, "Chris Craddock"

Quote:


>> I'm adding trace logic to a multi-task address space.  I'd like to
>> create some Global variables at the address space level to control
>> what gets traced and when.

>Is this code for your own local use, or is it going out as a product?

A: It's going out product code.

Quote:

>>I realize that this can be implemented via
>> callable token services IEANTCR and IEANTRT, but those routines look
>> like more overhead than I'm comfortable with, considering how often
>> these things will be accessed.
>How often are we talking about? If you mean hundreds or more times per
>second then the name token code won't help. You probably need to access your
>data in a few instructions via a well known path. However if the frequency
>is less than that tokens are probably ok. Their average pathlength isn't
>very long and they support lots of different execution modes.

A: It will be everywhere including bottom level loop-in-loop
subroutines.

Quote:
>>Are there any 4 byte areas
>> specifically reserved for user modification in any of the system
>> control blocks at the A/S level that I can step to myself via the CVT?

>In theory CVTUSER, TCBUSER are available for customer use. But they are so
>often abused that vendors now shy away from it. It's a recipe for disaster
>if its code for public consumption. Otherwise you could use it - provided it
>wasn't already in use by vendor code or some other hokey local program.

A: This is a vendor add-on to vendor code.  The other guys don't use
TCBUSER.  It's also not the kind of application that end users will
frequently mess with.  I haven't checked CVTUSER, but that one scares
me simply because it's so close to the top of the chain.

Quote:
>> If not, does anyone have any other suggestions?
>How would you propose to set those values? Most system control blocks are
>key zero. You need to be authorized for that. If you are able to run
>authorized at all there are quite a few sneaky things you could do to stash
>your information so it can be accessed quickly.

>Do you control the code that is running within the address space, or is it
>just any old code that someone wants to trace? If you control it, then you
>have a wealth of options. If you don't there are still some good choices,
>but you have to be a lot more carefull. More information please!

A: The code runs authorized, so SPK0 is no problem.  If you think
sneaky is safer than TCBUSER, let me know.

Thanks,
Wayne



Tue, 17 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:

>>Is this code for your own local use, or is it going out as a product?

>A: It's going out product code.

Then I would recommend against using the *USER fields.

Quote:
>A: It will be everywhere including bottom level loop-in-loop
>subroutines.

Then it probably needs to be accessible in a few (say less than 20)
instructions.

Quote:
>A: This is a vendor add-on to vendor code.  The other guys don't use
>TCBUSER.  It's also not the kind of application that end users will
>frequently mess with.

Not the point. If you deliver code to an installation that has ISV code, or
in house code that does use TCBUSER, then you will break their application,
or theirs will break yours.

Quote:
>A: The code runs authorized, so SPK0 is no problem.  If you think
>sneaky is safer than TCBUSER, let me know.

I definitely think sneaky is safer than TCBUSER. Contact me offline....

Chris.



Wed, 18 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:

> Hi All,

> I'm adding trace logic to a multi-task address space.  I'd like to
> create some Global variables at the address space level to control
> .....
> If not, does anyone have any other suggestions?

> TIA,
> Wayne

    Without getting into details of your product, don't you have a global
control block that is accessable to all the tasks within your address
space?  It would make the most sense to anchor your trace information off
of the global block.  Then it would be just a matter of following
pointers.

Jim Bahls



Thu, 19 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:


> >A: It's going out product code.

> Then I would recommend against using the *USER fields.

<AOL>
I concurr; the *USER fields are there for the installation to use, not
for independent third party vendors.

Quote:
> >A: This is a vendor add-on to vendor code.  The other guys don't use
> >TCBUSER.  It's also not the kind of application that end users will
> >frequently mess with.
> Not the point. If you deliver code to an installation that has ISV code, or
> in house code that does use TCBUSER, then you will break their application,
> or theirs will break yours.

Or, more likely, the customer will reject the product before it has a
chance to trash his production. Use of fields reserved for the customer
is a good way to shoot youraself in the foot. Just say no.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Fri, 20 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:

>I'm adding trace logic to a multi-task address space.  I'd like to
>create some Global variables at the address space level to control
>what gets traced and when.  I realize that this can be implemented via
>callable token services IEANTCR and IEANTRT, but those routines look
>like more overhead than I'm comfortable with, considering how often
>these things will be accessed.  Are there any 4 byte areas
>specifically reserved for user modification in any of the system
>control blocks at the A/S level that I can step to myself via the CVT?

If you are a subsystem (in the formal MVS sense) you can anchor
data in the subsystem affinity table for each task.  This might
be a bit faster than name-token services if you set it up
correctly.  Of course if you are adding code to someone else's
subsystem they might already be using the associated SSAF entry.

See the subsystem interface doc for details.

/b
--
Bill Manry  -  IBM Products Division  -  Oracle Corporation USA
These are my opinions, not necessarily Oracle's.



Sat, 21 Apr 2001 03:00:00 GMT  
 Global variables at the Address Space level

Quote:


>> Hi All,

>> I'm adding trace logic to a multi-task address space.  I'd like to
>> create some Global variables at the address space level to control
>> .....
>> If not, does anyone have any other suggestions?

>> TIA,
>> Wayne

>    Without getting into details of your product, don't you have a global
>control block that is accessable to all the tasks within your address
>space?  It would make the most sense to anchor your trace information off
>of the global block.  Then it would be just a matter of following
>pointers.

>Jim Bahls

That's the most obvious solution, but it would require a significant
amount of the kind of recoding that I'd rather avoid.  Unfortunately,
after sifting through the responses, it looks like that's the best way
to go.

Thanks,
Wayne



Sat, 21 Apr 2001 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. top-level (global) vs internal (local) variables/definitions

2. Class variables / global variables / Init variables

3. Global Variable / Sessions / ASP Application type Variable

4. global dynamically allocating space in FORTRAN

5. global name space and importing

6. setting global grab on top level window

7. Q:global vs. 2nd/3rd level procedure calls

8. Address Spaces

9. SRBs for cross address-space communication

10. Address space to swap in

11. Great fool for I/O address space

12. RAM & ROM Mixed Address Space Systems

 

 
Powered by phpBB® Forum Software