Re: STCBSST bit of STCBFLG1 of STCB DSECT
Since there is no reason anyone should ever be looking at this bit, there is no reason anyone should care in which task. Nevertheless, FWIW, it is in the propagated-to subtask Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Since there is no reason anyone should ever be looking at this bit, there is no reason anyone should care in which task. Nevertheless, FWIW, it is in the propagated-to subtask Peter Relson z/OS Core Technology Design Thank you! ;-) Justin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
A correction, courtesy of Jim: STCBSST is on only when subspace information is being propagated from a mother task to a daughter task. Thus the mother task can be actively using a subspace and not have STCBSST on. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
A correction, courtesy of Jim: STCBSST is on only when subspace information is being propagated from a mother task to a daughter task. Thus the mother task can be actively using a subspace and not have STCBSST on. Peter Relson z/OS Core Technology Design I'm sorry to be such a bother, but... In which task's STCB is the bit set? Thank you, Justin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
On Wed, 2 May 2012 21:47:31 -0500, Justin R. Bendich jbend...@austin.rr.com wrote: 9. BSG (BRANCH IN SUBSPACE GROUP) 10. Invoke XDC via its SVC HOOK. I then examine the STCBFLG1 byte and find that it's zero. I don't know for sure how this all works, but have you considered the possibility that step 10 takes you out of subspace mode until you return from the SVC? Why not try checking the flag from your code, instead? Then you'll know for sure. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Let's start by saying if you want to know if you are prior to z/OS 1.12 then simply query bit CVTZOS_V1R12. If that bit is off, then you are prior to z/OS 1.12. Maybe that suffices -- if you are prior to z/OS 1.12 then you know that a subspace cannot access storage above 2G (although a non-subspace could).. I don't know if there's a bit that RSM provided indicating that the APAR that was mentioned has been installed. Testing for the release might not be as efficient as you desire, but at least it works. You might find it necessary to have your caller tell you if they are in the state you are interested in. I'm not sure that the terminology used is letting the OP ask the right question. There is no such thing as subspace mode architecturally. It's not clear whether the OP is referring to subspace active or reduced authority both of which are potentially applicable, or even to a subspace task (a software term). Neither subspace-active nor reduced-authority state is something that can be in a z/OS control block because a suitably authorized program can change that on its own via the BSG and/or BSA instruction. Architecturally the state is kept in the dispatchable unit control table (DUCT) which is an architected block. I strongly discourage you from writing a program that accesses the DUCT as that is the sort of block that sometimes changes from machine to machine (and the operating system would be responsible for adapting to such changes; applications might have difficulty keeping up). STCBSST is not a programming interface. It means that the task is a subspace task (i.e., has subspace capabilities). It does not have any bearing on whether the task is currently subspace-active or reduced-authority although I would be surprised if you could be in either of those two states without having STCBSST on. For what it's worth, if you abend, bit SDWASSA will be on when the abend occurred while subspace-active. SDWABSA will be on for an ESTAE-type recovery routine (not for an FRR) when the abend occurred while in reduced authority mode. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Jim, Walt and Peter -- Thank you very much for your responses. They are truly helpful. Justin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
On Thu, 3 May 2012 08:37:59 -0500, Justin R. Bendich wrote: Jim, Walt and Peter -- Thank you very much for your responses. They are truly helpful. Ditto. In rare instances (like this) a thread comes up that I thought I wasn't interested in, and the responses prove me wrong. All too often the inverse is true unfortunately. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Justin R. Bendich wrote: 10. Invoke XDC via its SVC HOOK. Walt Farrell wrote: but have you considered the possibility that step 10 takes you out of subspace mode until you return from the SVC? I write: I know it's not clear from the posts, but... XDC does not run within an SVC. The SVC, when reached by execution, establishes a caller-owned ESTAE with XDC as the exit routine. It (the SVC) then sets a trap (an X'00' opcode which will cause an 0C1) at the caller's resume address. Finally, the SVC terminates back to the caller (the user code) so that the trap get's immediately executed. So the environment within which XDC runs is a simple ESTAE environment for the code being debugged. The SVC is long gone. But what effect this might have on the STCBSST flag, I do not know. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
In 6694875548510117.wa.jbendichaustin.rr@bama.ua.edu, on 05/02/2012 at 09:47 PM, Justin R. Bendich jbend...@austin.rr.com said: 1. JES2 starts the job-step in key 8. No. JES2 is not involves. It is the Initiator that attaches the j/s task. 5. ATTACH a JOBSTEP task. With it's own JSCB, or sharing? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
STCBSST bit of STCBFLG1 of STCB DSECT
APAR OA34311 enhances z/OS V1R12 to allow a dispatchable unit (maybe only task?) running in subspace mode to access virtual storage above the 2GB bar. This enhancement was not provided for z/OS V1R11. Our software needs to run on z/OS V1R11, and it sometimes needs to run in subspace mode. We would like to be able to determine programmatically whether our task is in subspace mode, so as to bring data below the bar for it. We have tried to use the STCBSST (X'10') bit of the STCBFLG1 byte at 25 off the STCB. There seem to be situations in which the task is in subspace mode, but the bit is not set. I wrote a test program which performed the following steps (sorry this is so complicated, but i have developed infrastructure and it's easier to just plug into it than to rewrite it): 1. JES2 starts the job-step in key 8. The test code then does: 2. MODESET KEY=ZERO 3. Set TCBPKF to X'60' 4. Allocate some storage in key 6. Copy parameters so the module i'm going to launch will be able to access them. 5. ATTACH a JOBSTEP task. It ends up running in key 6, PROBLEM state. This task then does: 6. ATTACH a non-JOBSTEP task, which does: 7a. IARSUBSP IDENTIFY 7b. IARSUBSP CREATE 7c. IARSUBSP ASSIGN 8. ALESERV ADD,STOKEN=token,ALET=alet where the token is as returned by step 7b. 9. BSG (BRANCH IN SUBSPACE GROUP) 10. Invoke XDC via its SVC HOOK. I then examine the STCBFLG1 byte and find that it's zero. If the program continues and attempts to access storage above the bar (you could insert a step between 6 and 7 to obtain this storage), i get S0C4-3B, as documented in OA34311 (i'm running on z/OS V1R11. There is no problem on z/OS V1R12, as we have applied the PTF). Are there some other pieces of data i should be examin- ing to see whether the current task has subspaces? Am i having this problem only because the task which is creating the subspace is not JOBSTEP? Thank you for any help, Justin R. Bendich jbendich at austin dot rr dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
STCBSST bit of STCBFLG1 of STCB DSECT
Are there some other pieces of data i should be examin- ing to see whether the current task has subspaces? Tasks do not have spaces. Address spaces have subspaces. I do not see a Programming Interface for determining whether or not an address space has subspaces. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
