Re: Vector enablement control?
Yes, and an even better answer. Thanks, Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jim Mulder Sent: Friday, November 1, 2019 10:42 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector enablement control? The question you really want to ask is "how should I determine if the task under which I am running has used already used vector instructions"? The answer is to look at PSAVSS or STCBVSS (which are classified as Programming Interfaces). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 10/31/2019 01:30:13 PM: > From: "Ngan, Robert" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/01/2019 11:36 AM > Subject: Vector enablement control? > Sent by: "IBM Mainframe Assembler List" > > With the new COBOL compilers capable of generating vector instructions > for handling packed fields, I'm looking at modifying our ESTAE > routines to dump the contents of the vector registers. > The PoOPs says you should not issue a vector instruction unless both > the vector enablement control and AFP-register control bits in CR0 are on. > If you're running z/OS on a z13 of higher (i.e. your machine a vector > instruction support), would either of these two bits ever be off? > > From a standard ESTAE routine, I can examine the CR0 contents from the > SDWA, but in a CICS ABEND exit, I don't have access to CR0. > > Robert Ngan > HCL Technologies DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: Vector enablement control?
Thanks, exactly what I wanted to know. Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Peter Relson Sent: Friday, November 1, 2019 06:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector enablement control? If you're running z/OS on a z13 of higher (i.e. your machine a vector instruction support), would either of these two bits ever be off? Yes. Note that "machine" is only one of the factors involved. Also involved are "z/OS release" and "LOADxx MACHMIG statement options". You should never use the vector extension facility unless bit CVTVEF is on. There is no z/OS release for which CVTVEF can be assumed to be on regardless of machine and environment (i.e., the vector extension facility is not part of any z/OS architecture levelset). When CVTVEF is on, work units generally start with the relevant CR0 bit off. The first VEF instruction results in a data exception program check (interrupt code 7). The system reacts to that by beginning vector register status save/restore for that work unit at which point that work unit will subsequently have the relevant CR0 bit on and that first VEF instruction is re-executed. The bit's being off is not relevant to much of anything; that is just a starting state. P.S. Is there a mapping macro for the control register bit flags? no. Peter Relson z/OS Core Technology Design DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: Vector enablement control?
The question you really want to ask is "how should I determine if the task under which I am running has used already used vector instructions"? The answer is to look at PSAVSS or STCBVSS (which are classified as Programming Interfaces). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 10/31/2019 01:30:13 PM: > From: "Ngan, Robert" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/01/2019 11:36 AM > Subject: Vector enablement control? > Sent by: "IBM Mainframe Assembler List" > > With the new COBOL compilers capable of generating vector > instructions for handling packed fields, I'm looking at modifying > our ESTAE routines to dump the contents of the vector registers. > The PoOPs says you should not issue a vector instruction unless both > the vector enablement control and AFP-register control bits in CR0 are on. > If you're running z/OS on a z13 of higher (i.e. your machine a > vector instruction support), would either of these two bits ever be off? > > From a standard ESTAE routine, I can examine the CR0 contents from > the SDWA, but in a CICS ABEND exit, I don't have access to CR0. > > Robert Ngan > HCL Technologies
Re: Vector enablement control?
If you're running z/OS on a z13 of higher (i.e. your machine a vector instruction support), would either of these two bits ever be off? Yes. Note that "machine" is only one of the factors involved. Also involved are "z/OS release" and "LOADxx MACHMIG statement options". You should never use the vector extension facility unless bit CVTVEF is on. There is no z/OS release for which CVTVEF can be assumed to be on regardless of machine and environment (i.e., the vector extension facility is not part of any z/OS architecture levelset). When CVTVEF is on, work units generally start with the relevant CR0 bit off. The first VEF instruction results in a data exception program check (interrupt code 7). The system reacts to that by beginning vector register status save/restore for that work unit at which point that work unit will subsequently have the relevant CR0 bit on and that first VEF instruction is re-executed. The bit's being off is not relevant to much of anything; that is just a starting state. P.S. Is there a mapping macro for the control register bit flags? no. Peter Relson z/OS Core Technology Design
Re: Vector enablement control?
answering my own question: >> And the question is? Uops- I only saw the first answer there is of course no question;-) -- Martin
Re: Vector enablement control?
And the question is? -- Martin
Re: Vector enablement control?
According https://share.confex.com/share/124/webprogram/Session16897.html It should be sufficient for application use to check CVTVEF https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100564.htm If On then vector facility should be available. Petr Svoboda
Vector enablement control?
With the new COBOL compilers capable of generating vector instructions for handling packed fields, I'm looking at modifying our ESTAE routines to dump the contents of the vector registers. The PoOPs says you should not issue a vector instruction unless both the vector enablement control and AFP-register control bits in CR0 are on. If you're running z/OS on a z13 of higher (i.e. your machine a vector instruction support), would either of these two bits ever be off? >From a standard ESTAE routine, I can examine the CR0 contents from the SDWA, >but in a CICS ABEND exit, I don't have access to CR0. Robert Ngan HCL Technologies P.S. Is there a mapping macro for the control register bit flags? DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
