Chris, Yeah - I realised that about initiators - but it is *still* the same address space and that can be handy to know (for example if you are tracking fragmented private area storage).
The fact that ASSBSTKN not GUPI sorta hinted to me that IBM are reserving the right to change its value without an address space restart - but maybe I am just being foolish .... As you pointed out, the SRB (once inside) can research the characteristics of the address space to see if things are as expected or not - so any SRB likely to come up against inits can have code to cater for the occasion. ASSBSTKN not being GUPI raised its head at work a while ago when the guy that writes the code to maintain address space history and trend data asked me how to uniquely identify an address space in strict enough terms for his model - something that is not as easy as it first seems... Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi_g2 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: 25 January 2007 13:35 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Cross Memory and AR ASC Mode Rob asks... > I have often wondered why ASSBSTKN is not GUPI as the values are > guaranteed to be unique between IPLs. I remember asking IBM many years > ago and was told that "it just wasn't, OK". Can you say "initiators" boys and girls? The STOKEN for an address space does indeed remain unique for the life of the IPL, but many jobs run (serially) within an initiator and each of those would "see" the same STOKEN value returned by EXTRACTH, or just by snarfing it out of the ASSB. But -logically- job 1 and job 2 are different things that just happened to run in the same space. You would very likely land in two wildly different places on successive SRB schedules. I suspect the same issue exists for other "reused" address spaces such as BPXAS' and those ASCH thingies I've never had anything to do with. Bottom line, just knowing the STOKEN - and even the jobname(!) isn't really enough. You would have to use the STOKEN to at least get into the right address space and when you "get there", do a little local sniffing to decide if you're REALLY REALLY where you meant to be. The details make this a tough little problem to crack on ones own eh? And the IBM doc (such as it is) is vague to the point of uselessness in these areas. The only way anyone figures this out REALLY is to collide with the ground often enough to notice where the hills are. The valleys often remain dark for your entire working life unless you're fortunate enough to live inside what Jim Mulder calls "the blue wall". CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
