Re: Is TCBSENV propagated to child TCB by ATTACHX
On Mon, Jun 25, 2018 at 12:29 PM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I do understand that all these cool things are, in fact, quite dangerous > facilities for the uninitiated and ignorant, and well-deserving of the > provided protection from untutored use. > > I don't think it's a sufficient business case for IBM purposes, but the > lack of GUPI encapsulation for these kinds of capabilities which are > already available in the system does at least somewhat limit the scope of > applications that can be envisioned and implemented by programmers without > access to private sandbox systems in which to experiment and learn. > Going back to the start, I totally agree that IBM should expose some GUPI interface to the DUCT oriented facilities used by the TRAP mechanism. After all, they did for the "linkage stack" instructions like BAKR. And they published caveats about using them. One big drawback to using BAKR is that there is not a simple method to recover from a "stack full" condition. Another drawback is that, from what I've read, BAKR is CPU intensive compared to any of the standard linkage methods currently defined by IBM. > > Sometimes I wish I still worked for a viable ISV where such > experimentation is encouraged and rewarded, and then I remember the > uncertainty and extraordinary work pressure of employment at such > companies. Very bad for one's digestion and usually detrimental to calm > family life. > > Peter > > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
Did anybody submit an RFE for a safe encapsulation of TRAP and PER handling? Is the MC interface still available for privileged users other than GTF? I've done software development; the pressure is no worse than at a data center, and in many cases you have a lot more control and more people to bounce ideas off of. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, June 25, 2018 1:29 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX I do understand that all these cool things are, in fact, quite dangerous facilities for the uninitiated and ignorant, and well-deserving of the provided protection from untutored use. I don't think it's a sufficient business case for IBM purposes, but the lack of GUPI encapsulation for these kinds of capabilities which are already available in the system does at least somewhat limit the scope of applications that can be envisioned and implemented by programmers without access to private sandbox systems in which to experiment and learn. Sometimes I wish I still worked for a viable ISV where such experimentation is encouraged and rewarded, and then I remember the uncertainty and extraordinary work pressure of employment at such companies. Very bad for one's digestion and usually detrimental to calm family life. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, June 25, 2018 12:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX Because the raw facilities are dangerous and IBM hasn't provided services to safely encapsulate them. The safeguards may seem confining, but I remember too well what life was like without them to want to return to those days. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, June 25, 2018 10:11 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX [Slightly OT and very much tongue-in-cheek . . .] Why do all the cool things to play with (servers and worker spaces and TRAP and . . . ) require authorized code? That keeps inquiring minds from experimenting and learning the cool things on our own (since no one seems to want to actually pay for learning anything these days). Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, June 25, 2018 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX Only if the attacher is authorized and asks for that to be done, by setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior to the ATTACH(X). If the bit is on, the bit and the value are propagated to the daughter TCB. Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
I do understand that all these cool things are, in fact, quite dangerous facilities for the uninitiated and ignorant, and well-deserving of the provided protection from untutored use. I don't think it's a sufficient business case for IBM purposes, but the lack of GUPI encapsulation for these kinds of capabilities which are already available in the system does at least somewhat limit the scope of applications that can be envisioned and implemented by programmers without access to private sandbox systems in which to experiment and learn. Sometimes I wish I still worked for a viable ISV where such experimentation is encouraged and rewarded, and then I remember the uncertainty and extraordinary work pressure of employment at such companies. Very bad for one's digestion and usually detrimental to calm family life. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, June 25, 2018 12:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX Because the raw facilities are dangerous and IBM hasn't provided services to safely encapsulate them. The safeguards may seem confining, but I remember too well what life was like without them to want to return to those days. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, June 25, 2018 10:11 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX [Slightly OT and very much tongue-in-cheek . . .] Why do all the cool things to play with (servers and worker spaces and TRAP and . . . ) require authorized code? That keeps inquiring minds from experimenting and learning the cool things on our own (since no one seems to want to actually pay for learning anything these days). Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, June 25, 2018 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX Only if the attacher is authorized and asks for that to be done, by setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior to the ATTACH(X). If the bit is on, the bit and the value are propagated to the daughter TCB. Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
Writing requirements is a black art. If you give detail IBM claims that you're telling them how to it, and if you don't give detail then they implement something that doesn't satisfy the requirement. BTW, I still have the shirt. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Monday, June 25, 2018 1:05 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX On Mon, Jun 25, 2018 at 11:11 AM Seymour J Metz wrote: > None of those options help learning about z/OS internals, due to OCO. When > logic manuals and source code become available, then it will be possible to > legitimately discuss learning internals. I won't hold my breathe. > Very true. I remember chanting, with others, "Just say NO to OCO." IBM summarily ignored us. I will say that in many ways since then IBM's attempts to make more interfaces documented and "GUPI" are nicely done. But "use the source, Luke!" is the GNU mantra and I embrace it. IBM's thoughts seem to be "don't tell us how to do things, tell us what you need & why". Of course, if it doesn't have a business case, then the profit driven IBM will feel free to either ignore or "back burner" it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
On Mon, Jun 25, 2018 at 11:11 AM Seymour J Metz wrote: > None of those options help learning about z/OS internals, due to OCO. When > logic manuals and source code become available, then it will be possible to > legitimately discuss learning internals. I won't hold my breathe. > Very true. I remember chanting, with others, "Just say NO to OCO." IBM summarily ignored us. I will say that in many ways since then IBM's attempts to make more interfaces documented and "GUPI" are nicely done. But "use the source, Luke!" is the GNU mantra and I embrace it. IBM's thoughts seem to be "don't tell us how to do things, tell us what you need & why". Of course, if it doesn't have a business case, then the profit driven IBM will feel free to either ignore or "back burner" it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
Because the raw facilities are dangerous and IBM hasn't provided services to safely encapsulate them. The safeguards may seem confining, but I remember too well what life was like without them to want to return to those days. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, June 25, 2018 10:11 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX [Slightly OT and very much tongue-in-cheek . . .] Why do all the cool things to play with (servers and worker spaces and TRAP and . . . ) require authorized code? That keeps inquiring minds from experimenting and learning the cool things on our own (since no one seems to want to actually pay for learning anything these days). Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, June 25, 2018 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX EXTERNAL EMAIL Only if the attacher is authorized and asks for that to be done, by setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior to the ATTACH(X). If the bit is on, the bit and the value are propagated to the daughter TCB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
None of those options help learning about z/OS internals, due to OCO. When logic manuals and source code become available, then it will be possible to legitimately discuss learning internals. I won't hold my breathe. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Monday, June 25, 2018 10:27 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX On Mon, Jun 25, 2018 at 9:11 AM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > [Slightly OT and very much tongue-in-cheek . . .] > > Why do all the cool things to play with (servers and worker spaces and > TRAP and . . . ) require authorized code? That keeps inquiring minds from > experimenting and learning the cool things on our own (since no one seems > to want to actually pay for learning anything these days). > My UNIX methods don't require APF authorization to fork()/exec() or spawn() a new address space for a different user. It just requires the proper RACF authorization. Which can be very granular, allowing the same code to allow changing to "A" but not to "A1". APF is generally a way to allow advanced facilities because misuse of those facilities can cause a z/OS system failure. And IBM "Statement of Integrity" is the documentation to that effect. https://secure-web.cisco.com/1P8TX3CcswLF8KtL3ds8KORQ7V7OsVWqKy2LUq4LodxGxtzH3PFVShMXRiHJ5YA0aNgB9QjW92MxwW5poJUlyoUisao9lyauLVZw9N5ODPOpKari0xfbD3a0VcOp51MkRqoSHedHXF5saqphSj80-nLsVpeGi8_NPVuwDx9Ne3gJQ62ihsHh6qBf5OSOHFljmYBMrAOp8aqETeY-RUZyiSHVhQ62EGy3NMl1MqgiX3TMnerUUE8DlyzqX-8bKlGhjUYKVatJZ1E38iKbmA3C-4Fxzws5tJyQ1lGZ37tf69oHu7zoJvL821ItXKh-VLpxSxQfLPqZ6814Y0LgssHC4cDfPNc_OUfNXqlQ-pf5zIoi3O3deuTrja0mcjRTqM94k/https%3A%2F%2Fwww-01.ibm.com%2Fcommon%2Fssi%2Fcgi-bin%2Fssialias%3Fsubtype%3DWH%26infotype%3DSA%26htmlfid%3DZSL03361USEN%26attachment%3DZSL03361USEN.PDF IBM’s commitment includes design and development practices intended to prevent unauthorized application programs, subsystems, and users from bypassing z/OS security – that is, to prevent them from gaining access, circumventing, disabling, altering, or obtaining control of key z/OS system processes and resources unless allowed by the installation. Specifically, z/OS “System Integrity” is defined as the inability of any program not authorized by a mechanism under the installation’s control to circumvent or disable store or fetch protection, access a resource protected by the z/OS Security Server (RACF® ), or obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. In the event that an IBM System Integrity problem is reported to IBM, IBM will always take action to resolve it in the specified operating environment for releases that have not reached their announced End of Support 1 dates. If you really want to learn z/OS "internals", I think that IBM's solution is (1) have a "sandbox" system where you don't care and so APF authorize just about anything; (2) shell out over USD 5000 / year for a PD system; (3) shell out about USD 600 (?) for a z/OS image on the Dallas Innovation Center (ISV only?). ISV's can get the zPDT, which is a slightly different version of the PD system. If I'm reading things correctly. I guess "knowledge is power" and you need to pay your power bill. Or some such thing. This is why I run Linux/Intel on an Intel XEON E3 system at home. I have _no_ real support, but full source code and a "do whatever you want -- your gun;your foot" attitude from RedHat (I run Fedora). > > Peter > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
On Mon, Jun 25, 2018 at 9:11 AM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > [Slightly OT and very much tongue-in-cheek . . .] > > Why do all the cool things to play with (servers and worker spaces and > TRAP and . . . ) require authorized code? That keeps inquiring minds from > experimenting and learning the cool things on our own (since no one seems > to want to actually pay for learning anything these days). > My UNIX methods don't require APF authorization to fork()/exec() or spawn() a new address space for a different user. It just requires the proper RACF authorization. Which can be very granular, allowing the same code to allow changing to "A" but not to "A1". APF is generally a way to allow advanced facilities because misuse of those facilities can cause a z/OS system failure. And IBM "Statement of Integrity" is the documentation to that effect. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH=SA=ZSL03361USEN=ZSL03361USEN.PDF IBM’s commitment includes design and development practices intended to prevent unauthorized application programs, subsystems, and users from bypassing z/OS security – that is, to prevent them from gaining access, circumventing, disabling, altering, or obtaining control of key z/OS system processes and resources unless allowed by the installation. Specifically, z/OS “System Integrity” is defined as the inability of any program not authorized by a mechanism under the installation’s control to circumvent or disable store or fetch protection, access a resource protected by the z/OS Security Server (RACF® ), or obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. In the event that an IBM System Integrity problem is reported to IBM, IBM will always take action to resolve it in the specified operating environment for releases that have not reached their announced End of Support 1 dates. If you really want to learn z/OS "internals", I think that IBM's solution is (1) have a "sandbox" system where you don't care and so APF authorize just about anything; (2) shell out over USD 5000 / year for a PD system; (3) shell out about USD 600 (?) for a z/OS image on the Dallas Innovation Center (ISV only?). ISV's can get the zPDT, which is a slightly different version of the PD system. If I'm reading things correctly. I guess "knowledge is power" and you need to pay your power bill. Or some such thing. This is why I run Linux/Intel on an Intel XEON E3 system at home. I have _no_ real support, but full source code and a "do whatever you want -- your gun;your foot" attitude from RedHat (I run Fedora). > > Peter > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
[Slightly OT and very much tongue-in-cheek . . .] Why do all the cool things to play with (servers and worker spaces and TRAP and . . . ) require authorized code? That keeps inquiring minds from experimenting and learning the cool things on our own (since no one seems to want to actually pay for learning anything these days). Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, June 25, 2018 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX EXTERNAL EMAIL Only if the attacher is authorized and asks for that to be done, by setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior to the ATTACH(X). If the bit is on, the bit and the value are propagated to the daughter TCB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
On Mon, Jun 25, 2018 at 8:44 AM Peter Relson wrote: > Only if the attacher is authorized and asks for that to be done, by > setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior > to the ATTACH(X). > If the bit is on, the bit and the value are propagated to the daughter > TCB. > Thank very much. That satisfies my curiosity completely. Not that I would ever designed a MUSAS application in today's z/OS environment. Possibly due to an extreme *IX infection, I'd use z/OS UNIX services to either fork()/exec() or spawn() a new address space, using the UNIX facilities (using the proper RACF permissions) to start a new address space for the new user. Much like the z/OS ftp server does. Isolating the users in separate address spaces is much much expensive, but it significantly more secure. However, that is just my opinion. > > Peter Relson > z/OS Core Technology Design > > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
Only if the attacher is authorized and asks for that to be done, by setting bit TCBSENVP (the "P" stands for "propagate") in its own TCB prior to the ATTACH(X). If the bit is on, the bit and the value are propagated to the daughter TCB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
On Fri, 22 Jun 2018 09:43:15 -0500, John McKown wrote: >This is strictly a curiosity question. Suppose for some unspecified & >irrelevant to this discussion that my code is running under a TCB which has >a non-zero TCBSENV value. If my code were to do an ATTACHX to create a >subtask, would the new TCB have the same TCBSENV as my code, or would it be >zero? I did RTFM but did not see anything that addresses this. And an IBM >KC search got so many hits that I was completely befuddled. No, in the general case ATTACH/X does not propagate TCBSENV from parent to child. There is one exception I recall, but I leave research on the details (and proper terminology) to someone else. I believe that WLM provides functions that allow requestors to schedule work to a server address space, and cooperating worker address spaces to pull requests off of the server queue for processing. Those WLM services also capture the security credentials for the requestor. When the worker pulls a request the system instantiates a copy of the requestor's ACEE for the worker so the request runs with the requestor's security credentials. In that environment (and only in that environment, as far as I know) if the code running in the worker does an ATTACH/X, TCBSENV _is_ propagated to the daughter TCB. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
On 6/22/2018 7:43 AM, John McKown wrote: This is strictly a curiosity question. Suppose for some unspecified & irrelevant to this discussion that my code is running under a TCB which has a non-zero TCBSENV value. If my code were to do an ATTACHX to create a subtask, would the new TCB have the same TCBSENV as my code, or would it be zero? I did RTFM but did not see anything that addresses this. And an IBM KC search got so many hits that I was completely befuddled. I've always wondered if that is what the uncommented TCBSENVP is for... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
TCBSENV is not propagated to the daughter on ATTACH. My suggestion would be to ATTACH DISP=NO and get the mother task to populate the field in the daughter. Rob Scott Rocket Software Original message From: Charles Mills Date: 22/06/2018 16:50 (GMT+00:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is TCBSENV propagated to child TCB by ATTACHX I am very familiar with TCBSENV and I don't know the answer. My "guess" would be that it IS propagated, but that is a guess. Easy to run an experiment if you wanted to. I do know that TCBSENV is "optional" -- it is zero a lot of the time. (That is, if you have code that sees a lot of "random" TCB's you will see a lot of TCBSENV == 0.) ASXBSENV is often a fallback. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, June 22, 2018 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is TCBSENV propagated to child TCB by ATTACHX This is strictly a curiosity question. Suppose for some unspecified & irrelevant to this discussion that my code is running under a TCB which has a non-zero TCBSENV value. If my code were to do an ATTACHX to create a subtask, would the new TCB have the same TCBSENV as my code, or would it be zero? I did RTFM but did not see anything that addresses this. And an IBM KC search got so many hits that I was completely befuddled. -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is TCBSENV propagated to child TCB by ATTACHX
I am very familiar with TCBSENV and I don't know the answer. My "guess" would be that it IS propagated, but that is a guess. Easy to run an experiment if you wanted to. I do know that TCBSENV is "optional" -- it is zero a lot of the time. (That is, if you have code that sees a lot of "random" TCB's you will see a lot of TCBSENV == 0.) ASXBSENV is often a fallback. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, June 22, 2018 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is TCBSENV propagated to child TCB by ATTACHX This is strictly a curiosity question. Suppose for some unspecified & irrelevant to this discussion that my code is running under a TCB which has a non-zero TCBSENV value. If my code were to do an ATTACHX to create a subtask, would the new TCB have the same TCBSENV as my code, or would it be zero? I did RTFM but did not see anything that addresses this. And an IBM KC search got so many hits that I was completely befuddled. -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is TCBSENV propagated to child TCB by ATTACHX
This is strictly a curiosity question. Suppose for some unspecified & irrelevant to this discussion that my code is running under a TCB which has a non-zero TCBSENV value. If my code were to do an ATTACHX to create a subtask, would the new TCB have the same TCBSENV as my code, or would it be zero? I did RTFM but did not see anything that addresses this. And an IBM KC search got so many hits that I was completely befuddled. -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
