Re: OT-ish: Very old IBM hardware & manuals available
Maybe contact the Computer History Museum https://computerhistory.org/ . They probably have the resources to ship anything they're interested in. Their collection includes IBM hardware that predates any of us having seen a digital computer. It's been quite a while since I was there, but they were working on fixing up an IBM drum storage device which I think was the size of beer keg and held something like 550 bytes, no typo, or maybe it was a few kbytes. /Leonard Robert Prins wrote on 1/23/2024 7:57 AM: Hi all, My father worked for IBM in the Netherlands for more than 30 years, starting as a CE in the late 1950'ies. Last year he was diagnosed with Alzheimer, and over the past few months my siblings and me have been emptying his apartment and storage room, and we've come across a sizeable quantity of IBM "stuff", from manuals for the 650 to old square cm "integrated circuits" and even a magnetic core memory card. My siblings weren't in the least interested in any of it, so I took it, and although it's nice to look at, our house is already full enough as it is, so... If anyone thinks they can offer a good home to these things, and I will, hopefully soon, put pictures of everything that surfaces on my website, feel free to contact me off this list and we can take it from there. You'll most definitely be paying for shipping (from Lithuania), and based on what I'm going to find out on fleabay, I might ask for a bit more. Robert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Eric Rossman wrote: >The CPACF is a physically separate chip that runs in lockstep >with the CP that invokes it. So, it is does cost general CP but >much less than implementing it in millicode. Actually, every processor core includes its own CPACF coprocessor section. In other words, CPACF is “on core.” That includes CPs (general purpose processor cores), IFLs, zIIPs, and all the other main processor core types.(*) You can see a design illustration of this arrangement in IBM Redbook SG24-8951 (“IBM z16 Technical Guide”) in Figure 3-13. If your processor core is configured for SMT2 (typical with zIIPs and IFLs) then the CPACF section will also operate in SMT2 mode. Said another way, every processor core thread has its own CPACF section thread. Really the only thing you need to worry about in terms of having CPACF available is to make sure that Feature Code 3863 is installed on your system. FC 3863 is a zero additional charge feature. It’s available in almost every country and territory, but apparently there are one or a couple odd places with peculiar import regulations. Those few places may still allow FC 3863 but may require some sort of permit or other legal paperwork. Ordinarily your IBM representative or IBM business partner will add FC 3863 to your machine order reflexively in the countries/territories where there’s no local regulatory issue. But that’s something to double check. If you don’t have FC 3863 installed then CPACF still partially works, but it only provides hashing and random number functions. FC 3863 enables the full range of CPACF algorithms/instructions including encrypt/decrypt. (*) I think those other processor types also use CPACF instructions from time to time, if available. For example, the Coupling Facility Control Code (CFCC) likely uses CPACF instructions (if FC 3863 is present) when you configure encryption-related functions to strengthen a CF’s security posture. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Timothy, You forgot to mention the other alternative for using CPACF facilities - direct application-level HLASM coding. I did that once a long while ago, in the era before protected clear keys, for encryption of a single field in a huge business record, security provided by "hiding" the encryption key value (I know, not very secure at all, but it was a short-term urgent business necessity). Long since replaced of course by more modern and far more secure methods, but the CPACF hardware facility is there to use (assuming it is turned on) should one have the need, and with protected clear keys it can even be somewhat secure. Of course, it's probably only curious old dinosaurs like me who would even think of "roll your own" for an encryption need when these days there is so much infrastructure available to do the work for you. Peter From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Wednesday, January 24, 2024 5:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP >So Timothy (and probably just for me), I've seen a couple >of sites without crypto HSM cards not bother to run ICSF. >Can I assume in that case there's pretty-much no way any >encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is "darn important." But the way you phrased your question I'd answer no. It's technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that's using CPACF instructions - via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. -- 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: Encryption and decryption - processor or TCPIP
Thanks Timothy, and thanks to others who helped with my side questions. On 1/24/2024 2:20 AM, Timothy Sipples wrote: So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is “darn important.” But the way you phrased your question I’d answer no. It’s technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that’s using CPACF instructions — via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- 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: Another Getting away from the mainframe tale -- Jammed it in Reverse...
IBM beat on top and bottom line. Stock is flying. Up $10 a share after hours. Dying my a$$ Sent from Yahoo Mail for iPhone On Friday, January 19, 2024, 4:01 PM, Dave Beagle <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote: No wonder IBM stock is hitting another new high today. Sent from Yahoo Mail for iPhone On Friday, January 19, 2024, 3:44 PM, Steve Thompson wrote: They migrated to that mainframe environment as quickly as they could. A reverse Boot Hill story. Steve Thompson -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/osmf error
Hi, Sheila. I cannot help specifically, however, if you do not have the complete error message I am including it below. The message says the reason for the failure is noted in the error. You might consider posting the ENTIRE error message to the group. IZUR400E The request could not be completed. z/OSMF could not connect to the DDS or Linux data gatherer at URL address. Reason: reason. Explanation The request failed because z/OSMF could not connect to the Resource Measurement Facility (RMF) Distributed Data Server (DDS) or to the Linux data gatherer located at the specified URL. The reason for the error is provided. In the message text: address Host name or IP address and port for the DDS or Linux data gatherer. reason Description of the cause of the error. System programmer response Ensure that the z/OSMF server is running. Verify that the resource is available and that the DDS or Linux data gatherer is active. Examine the z/OSMF logs for more details about the error. If the problem persists, contact the IBM Support Center. User response Verify that the host name or IP address and port are specified correctly, and ensure that there are no trailing spaces. If the problem persists, contact your z/OSMF administrator or system programmer. Ramsey On Wed, Jan 24, 2024 at 1:58 PM Chalk, Shelia wrote: > Hello, > > I am new to z/osmf. I am getting this error > IZUR400E The request could not be completed. z/OSMF could not connect to > the DDS or Linux data gatherer at UR > Can someone point me in the right direction? > > Thanks > > Shelia Chalk > Mainframe System Programmer > sch...@ssfcu.org > > > == > This email, and any files transmitted with it, is confidential and > intended solely for the use of the individual or entity to which it is > addressed. If you have received this email in error, please notify the > system manager. This message contains confidential information and is > intended only for the individual named. If you are not the named addressee, > you should not disseminate, distribute or copy this e-mail. Please notify > the sender immediately by e-mail if you have received this message by > mistake and delete this e-mail from your system. If you are not the > intended recipient, you are notified that disclosing, copying, distributing > or taking any action in reliance on the contents of this information is > strictly prohibited. > > -- > 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: Encryption and decryption - processor or TCPIP
> > Peter wrote: > > > Still I am trying to understand encryption and decryption > > > load goes to general CP Incase if you don't have CPACF or > > > ICSF ? > Phil Smith III wrote: > > Even with CPACF and ICSF, some/most of the encryption load > > is on the CPU. > > They aren't magic. CPACF is faster, but it's still > > fundamentally executing Z instructions in the millicode. Tony H wrote: > Really? Surely there is on-chip crypto hardware that the > millicode invokes to do much of the work? I can't imagine it's > just like the millicode implementation of the sort > instructions or something. You are correct. The CPACF is a physically separate chip that runs in lockstep with the CP that invokes it. So, it is does cost general CP but much less than implementing it in millicode. > But I think the OP deserves a simple answer: YES. If there's > no crypto hardware then ICSF will do it all using ordinary > zArch instructions. If there is no crypto hardware (no CPACF), ICSF won't start. > In the early days there was (is?) even an ability to plug your > own crypto provider software into the back end of ICSF, with > interface documentation "by request only". I've been in ICSF for over 25 years. I've never heard of this. Eric Rossman ICSF architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/osmf error
Hello, I am new to z/osmf. I am getting this error IZUR400E The request could not be completed. z/OSMF could not connect to the DDS or Linux data gatherer at UR Can someone point me in the right direction? Thanks Shelia Chalk Mainframe System Programmer sch...@ssfcu.org == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
You will need at least a CPACF to initialise ICSF. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: 24 January 2024 18:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP On Wed, 24 Jan 2024 at 12:38, Phil Smith III wrote: > Peter wrote: > >Still I am trying to understand encryption and decryption load goes > >to general CP Incase if you don't have CPACF or ICSF ? > > Even with CPACF and ICSF, some/most of the encryption load is on the CPU. > They aren't magic. CPACF is faster, but it's still fundamentally > executing Z instructions in the millicode. > Really? Surely there is on-chip crypto hardware that the millicode invokes to do much of the work? I can't imagine it's just like the millicode implementation of the sort instructions or something. But I think the OP deserves a simple answer: YES. If there's no crypto hardware then ICSF will do it all using ordinary zArch instructions. Probably there are a few things it can't do, like true random number generation, but generally you don't need any crypto hardware at all. In the early days there was (is?) even an ability to plug your own crypto provider software into the back end of ICSF, with interface documentation "by request only". Tony H. -- 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: Encryption and decryption - processor or TCPIP
On Wed, 24 Jan 2024 at 12:38, Phil Smith III wrote: > Peter wrote: > >Still I am trying to understand encryption and decryption load goes to > >general CP Incase if you don't have CPACF or ICSF ? > > Even with CPACF and ICSF, some/most of the encryption load is on the CPU. > They aren't magic. CPACF is faster, but it's still fundamentally executing > Z instructions in the millicode. > Really? Surely there is on-chip crypto hardware that the millicode invokes to do much of the work? I can't imagine it's just like the millicode implementation of the sort instructions or something. But I think the OP deserves a simple answer: YES. If there's no crypto hardware then ICSF will do it all using ordinary zArch instructions. Probably there are a few things it can't do, like true random number generation, but generally you don't need any crypto hardware at all. In the early days there was (is?) even an ability to plug your own crypto provider software into the back end of ICSF, with interface documentation "by request only". Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: xl/C data types?
>> For example, does z⧸OS XL C⧸C++ support packed decimal? Others? Gil, Fixed-point (Packed) Decimal Data z/OS XL C supports fixed-point (packed) decimal as a native data type for use in business applications. The packed data type is similar to the COBOL data type COMP-3 or the PL/I data type FIXED DEC, with up to 31 digits of precision. https://www.ibm.com/docs/en/zos/2.5.0?topic=cc-additional-features-zos-xl Note : Open XL does not have Packed Decimal support Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
xl/C data types?
(from another list) On 1/23/24 14:29:31, Arthur David Olson wrote: I'm wondering if an implementation [of C] is required to support all the features of the hardware it is meant for. (If not, implementations on [non-]power-of-2 word-size two's complement machines might not have some of the intN_t types.) . For example, does z⧸OS XL C⧸C++ support packed decimal? Others? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >Still I am trying to understand encryption and decryption load goes to >general CP Incase if you don't have CPACF or ICSF ? Even with CPACF and ICSF, some/most of the encryption load is on the CPU. They aren't magic. CPACF is faster, but it's still fundamentally executing Z instructions in the millicode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - CBFORMAT
Thanks. Needless to say, this is not one of the best documented interfaces.
Your help is valued.
--Bill
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Wednesday, January 24, 2024 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
You can make each model an entry point in the module, with an ALIAS for each
one when you bind the module.
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Bill Yeager
Sent: Wednesday, January 24, 2024 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Jim,
Just one more question, if you please...
I'd like to put a bunch of CB mappings in one module if it's possible. The
manual was totally unclear as to whether this is possible and, if so, how to do
it.
Do you know?
Thanks,
Bill
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Tuesday, January 23, 2024 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
>
Re: Encryption and decryption - processor or TCPIP
I think there might be some confusion as to terminology. CPACF is a hardware engine built into the CEC. Crypto Express cards are hardware engines purchased to be plugged into the box. ICSF can use CPACF (which still counts against general CP but is much more efficient than software crypto), Crypto Express, or our own software implementation (for things not implemented in HW or when HW support is not available). ICSF generally prefers Crypto Express for RSA and CPACF for AES, DES, ECC, hashing. Eric Rossman From: Peter Sent: Wednesday, January 24, 2024 11:15 AM To: IBM Mainframe Discussion List ; Eric D Rossman Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Eric Still I am trying to understand encryption and decryption load goes to general CP Incase if you don't have CPACF or ICSF ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Macro to retrieve RACF CSDATA
Hello, I would like to retrieve the CSDATA stored in my RACF user profile. This is what I have: USER=TSGJR CSDATA INFORMATION -- FULLNAME John Blythe Reid DATAFLD2 : ABCDEF I'm looking at the macro RACROUTE REQUEST=EXTRACT,TYPE=EXTRACT to obtain the data in CSDATA DATAFLD2 for my user but I can't see how to do it. Could anyone give me a hand with this please ? Regards, John. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - CBFORMAT
You can make each model an entry point in the module, with an ALIAS for each
one when you bind the module.
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Bill Yeager
Sent: Wednesday, January 24, 2024 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Jim,
Just one more question, if you please...
I'd like to put a bunch of CB mappings in one module if it's possible. The
manual was totally unclear as to whether this is possible and, if so, how to do
it.
Do you know?
Thanks,
Bill
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Tuesday, January 23, 2024 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
> ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC
> BLSQMDEF END
>
>2B79E814 D6D7D9D4 E6D9E3C5 D9D9C5D8 | OPRMWRTERREQ |
>2B79E820 E6D9E3C5 D9C5C1C4 | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814
> + EYEC. OPRM
>Control block is truncated
>
>--
>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
Re: Encryption and decryption - processor or TCPIP
Eric Still I am trying to understand encryption and decryption load goes to general CP Incase if you don't have CPACF or ICSF ? On Wed, Jan 24, 2024, 6:44 PM Eric D Rossman wrote: > Responding to a bunch of questions/comments in one reply. > > Tom Brennan: > > I thought I heard that you can start ICSF without a crypto > > card and it will use CPACF for some of the heavier encryption > > processing (maybe like generating prime numbers) and save > > individual tasks some CP time. > > ICSF will use CPACF for RNG, hashing (SHA-1, 2, 3), DES, AES, and ECC > operations. It will also use it for ECC key pair generation if you use PKCS > #11 interfaces. > > Lennie Dymoke-Bradshaw: > > ... ICSF without a Crypto Express card. ... However, this only > > supports clear keys in the CKDS. The CKDS ... is different in > > some way and cannot be converted to a secure key CKDS. > > True. There is an unsupported way to convert from clear key only > CKDS to secure key (and clear key) CKDS but it's not for the > faint of heart (since you are messing directly with your KDS). > > Lennie Dymoke-Bradshaw: > > I don't know if there is a way of using the PKDS or TKDS in > > this configuration. > > PKDS, no. TKDS, yes. The TKDS existed before EP11 existed. > > Lennie Dymoke-Bradshaw: > > I have been told it is possible to run Data set encryption > > with CPACF only and a clear key CKDS > > This is possible, but less secure since the keys are not protected by a > master key. > > Timothy Sipples: > > ICSF supports many, many cryptography-dependent features in > > z/OS. Even many business applications that just need a simple > > API to get a random number rely on ICSF. ICSF is > > “darn important.” > > Thank you! I might be biased but I think everyone should have ICSF. > > Timothy Sipples: > > And if persistent TLS connections are an option then they’d > > dramatically reduce the number of network roundtrips, > > eliminating a lot of network latency. > > Agreed. Also, System SSL session caching is also quite helpful. > > Eric Rossman > > > -- > 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: IPCS - CBFORMAT
Jim,
Just one more question, if you please...
I'd like to put a bunch of CB mappings in one module if it's possible. The
manual was totally unclear as to whether this is possible and, if so, how to do
it.
Do you know?
Thanks,
Bill
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Tuesday, January 23, 2024 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
> ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC
> BLSQMDEF END
>
>2B79E814 D6D7D9D4 E6D9E3C5 D9D9C5D8 | OPRMWRTERREQ |
>2B79E820 E6D9E3C5 D9C5C1C4 | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814
> + EYEC. OPRM
>Control block is truncated
>
>--
>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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >After implementing ATTLS there is some delay in our CICS transaction but I >was suspecting if sn absence of crypto processor can overload the general >processor to cause this delay ? Define "some delay". Adding AT-TLS means that a TLS handshake is being added to the communication. That isn't instantaneous, and means some additional network back-and-forth. I'd strongly suspect that it's more just network latency added by that than the cost of the encryption itself. As for CPACF, this tiny Rexx program will tell you if it's enabled. It does require that CSF (ICSF) be running/have run since IPL. It tests a bit CSF sets after *it* verifies the existence of CPACF by trying the instructions. /* REXX */ if bitand(storage(d2x(x2d(c2x(storage(d2x(x2d(c2x(, storage(d2x(x2d(c2x(storage(10,4)))+x2d(C8)),4)))+, x2d(B8)), 4)))+x2d(11A)), 1), '08'x) <> '00'x then say 'CPACF is enabled' else say 'CPACF is not enabled' /* tests CCVT_KMC_AES256 (x'08', "KMC AES 256 key enabled") on flag CCVT_KMC_EXPORT3 (offset 11A) in CSFCCVT, pointed to by CVTABEND (offset x'B8') into CVT (X'10' in page 0) */ If by some chance CPACF is NOT enabled, it's a free feature on all current IBM hardware, so get it turned on! Do make sure that anything you enable AT-TLS for both can handle TLS at the other end AND is not already doing TLS. We've had several incidents where people turned on AT-TLS "because it's good" and our product was already doing TLS. The double encryption does not work out well--specifically, it results in strange connection failures because "inner" level of negotiation works, but then instead of seeing a request, it sees another TLS negotiation start, which it doesn't understand since it's not looking for one. It doesn't sound like this is your issue--if it were, you'd be having failures, not delays!--but it's important to understand and I'll keep repeating it because it seems to be a common error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Responding to a bunch of questions/comments in one reply. Tom Brennan: > I thought I heard that you can start ICSF without a crypto > card and it will use CPACF for some of the heavier encryption > processing (maybe like generating prime numbers) and save > individual tasks some CP time. ICSF will use CPACF for RNG, hashing (SHA-1, 2, 3), DES, AES, and ECC operations. It will also use it for ECC key pair generation if you use PKCS #11 interfaces. Lennie Dymoke-Bradshaw: > ... ICSF without a Crypto Express card. ... However, this only > supports clear keys in the CKDS. The CKDS ... is different in > some way and cannot be converted to a secure key CKDS. True. There is an unsupported way to convert from clear key only CKDS to secure key (and clear key) CKDS but it's not for the faint of heart (since you are messing directly with your KDS). Lennie Dymoke-Bradshaw: > I don't know if there is a way of using the PKDS or TKDS in > this configuration. PKDS, no. TKDS, yes. The TKDS existed before EP11 existed. Lennie Dymoke-Bradshaw: > I have been told it is possible to run Data set encryption > with CPACF only and a clear key CKDS This is possible, but less secure since the keys are not protected by a master key. Timothy Sipples: > ICSF supports many, many cryptography-dependent features in > z/OS. Even many business applications that just need a simple > API to get a random number rely on ICSF. ICSF is > “darn important.” Thank you! I might be biased but I think everyone should have ICSF. Timothy Sipples: > And if persistent TLS connections are an option then they’d > dramatically reduce the number of network roundtrips, > eliminating a lot of network latency. Agreed. Also, System SSL session caching is also quite helpful. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
No need to apologise; You made me snigger. “Fix it with finance” is what I often use. Caveat vendor? Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 13:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Sorry MaRtin. L -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 24 January 2024 13:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of
Re: Encryption and decryption - processor or TCPIP
Sorry MaRtin. L -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 24 January 2024 13:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic
Re: Encryption and decryption - processor or TCPIP
Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto
Re: IPCS - CBFORMAT
Jim,
You nailed it with the LISTMAP. Once I had gotten an error with this control
block (earlier), IPCS had set the length to 4 and remembered it. I used
"DROPMAP structure(oprm)" and then rand the CBF again it worked!
Thanks so much.
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Tuesday, January 23, 2024 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
> ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC
> BLSQMDEF END
>
>2B79E814 D6D7D9D4 E6D9E3C5 D9D9C5D8 | OPRMWRTERREQ |
>2B79E820 E6D9E3C5 D9C5C1C4 | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814
> + EYEC. OPRM
>Control block is truncated
>
>--
>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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it’s this. The interesting bit would be if this zIIP usage were large – and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the
Re: Encryption and decryption - processor or TCPIP
Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a
Re: Encryption and decryption - processor or TCPIP
Lennie Dymoke-Bradshaw wrote: >In the back of my mind I also think that the crypto processing for TCP/IP >could be performed on a zIIP processor (which could be using its CPACF, of >course). IPSec/IKEv2 can exploit zIIPs (and CPACF). https://www.ibm.com/docs/en/zos/3.1.0?topic=iv-additional-ipsec-assist-using-system-z-integrated-information-processor-ziip-ip-security But I think we’re drifting a bit. z/OS AT-TLS performs quite well if it’s configured correctly. And if persistent TLS connections are an option then they’d dramatically reduce the number of network roundtrips, eliminating a lot of network latency. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
>So Timothy (and probably just for me), I've seen a couple >of sites without crypto HSM cards not bother to run ICSF. >Can I assume in that case there's pretty-much no way any >encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is “darn important.” But the way you phrased your question I’d answer no. It’s technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that’s using CPACF instructions — via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I’m assuming TCP/IP address space(s) – which generally are in SYSSTC and so above eg Db2 Engine. (At this point I’m interested in detecting / sizing such goings on – probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a dump that hasn't been redacted, for example - to obtain the private > keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS > are operating with clear key, but "we can do better." And we do: > Crypto Express facilitates protected key and secure key operations. > Get them, use them, love them. :-) > > But let's leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you're actually seeing longer
Re: Encryption and decryption - processor or TCPIP
Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a dump that hasn't been redacted, for example - to obtain the private > keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS > are operating with clear key, but "we can do better." And we do: > Crypto Express facilitates protected key and secure key operations. > Get them, use them, love them. :-) > > But let's leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you're actually seeing longer transaction times - if you've got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference - then there are likely one or two basic reasons why. One likely reason is that you're not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn't exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that's less than ideal for CPACF exploitation. Generally you should "encourage" (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer
Re: Encryption and decryption - processor or TCPIP
Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: Peter wrote: I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? I’ve seen some of the follow-up messages, and it seems like you’re trying to troubleshoot a performance/throughput-related issue. Or at least you’d like to understand what changed, why you may be observing an elongation in your transaction times from CICS’s perspective. “Crypto processor” could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that’s on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF’s full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. IBM Crypto Express HSMs are optional (but strongly recommended!) features that are installed as cards in your IBM Z or IBM LinuxONE server’s PCI slots. In recent models there are two variants of the IBM Crypto Express cards: “single port” and “dual port.” Dual port means that there are two physical HSMs per card. It’s simply a higher density card that allows you to support more HSM domains and modes within a smaller physical space, analogous to the difference between a fully populated processor drawer and a partially populated one. Whether you get the single port or dual port variant (or some of both), their role is to protect secrets, especially private encryption keys. They have their own onboard processors to execute cryptographic operations, and you need them to move beyond “clear key” cryptography. Clear key cryptography means your private encryption keys inhabit main memory, the same memory that the operating system, middleware, and applications inhabit. Conceivably that memory could be accessed — via a dump that hasn’t been redacted, for example — to obtain the private keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS are operating with clear key, but “we can do better.” And we do: Crypto Express facilitates protected key and secure key operations. Get them, use them, love them. :-) But let’s leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you’re actually seeing longer transaction times — if you’ve got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference — then there are likely one or two basic reasons why. One likely reason is that you’re not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn’t exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that’s less than ideal for CPACF exploitation. Generally you should “encourage” (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you’re getting. Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there’s an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you’re comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the “cost of doing business” when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if
Re: Encryption and decryption - processor or TCPIP
My case was before AT-TLS, when I believe it was up to each application to handle the encryption themselves, so we saw a big spike and delay in the SSHD task each time someone logged on. That timing contributed to my theory about the prime number generation or similar initial encryption processing. There was no spike in TCPIP which I believe had no part in the encryption processing prior to AT-TLS. After AT-TLS? I don't have experience. On 1/23/2024 10:49 PM, Peter wrote: Ok so TCPIP as a started task when it does encryption and decryption so it directly overloads the General CP ? On Wed, Jan 24, 2024, 9:59 AM Tom Brennan wrote: Even though you don't have a crypto processor, do you have CPACF on the box? Most machines I've seen do, because it's a no-charge feature. I don't know for sure, but I thought I heard that you can start ICSF without a crypto card and it will use CPACF for some of the heavier encryption processing (maybe like generating prime numbers) and save individual tasks some CP time. That's just my old theory though, from back in 2015 when I saw a situation similar to what you describe. But it was a client machine where I didn't have the ability to try things out. I'd sure like to hear more from someone more experienced in this area. On 1/23/2024 9:10 PM, Peter wrote: After implementing ATTLS there is some delay in our CICS transaction but I was suspecting if sn absence of crypto processor can overload the general processor to cause this delay ? On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: Peter wrote: I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? The TCPIP started task is just code and runs on the general processor, so your question doesn't make much sense. AT-TLS is managed by the Policy Agent started task, and it appears that the actual encryption takes place in the TCPIP started task, but that's a conclusion-I've never wondered. Why do you ask? What problem are you trying to solve? We'd like to know more! -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
It would be worth looking at the RMF report on the crypto processing and seeing if they are running hot. Does the PAGENT address space a lot of CPU - is it delayed? The code may execute on your CICS TCB - executing cross memory (via PC) in the TCPIP address space(s).I don't recall seeing anything about tuning the number of threads in TCPIP for crypto work. There are some counts for crypto activity in the SMF 30 records. Colin On Wed, 24 Jan 2024 at 05:10, Peter wrote: > After implementing ATTLS there is some delay in our CICS transaction but I > was suspecting if sn absence of crypto processor can overload the general > processor to cause this delay ? > > On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: > > > Peter wrote: > > >I have a general question here. When you don't have crypto processor, So > > >when a ATTLS traffic is enabled does the encryption and decryption > handled > > >by Started task TCPIP or the general processor? > > > > The TCPIP started task is just code and runs on the general processor, so > > your question doesn't make much sense. AT-TLS is managed > > by the Policy Agent started task, and it appears that the actual > > encryption takes place in the TCPIP started task, but that's a > > conclusion-I've never wondered. > > > > Why do you ask? What problem are you trying to solve? We'd like to know > > more! > > > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >I have a general question here. When you don't have crypto processor, So >when a ATTLS traffic is enabled does the encryption and decryption handled >by Started task TCPIP or the general processor? I’ve seen some of the follow-up messages, and it seems like you’re trying to troubleshoot a performance/throughput-related issue. Or at least you’d like to understand what changed, why you may be observing an elongation in your transaction times from CICS’s perspective. “Crypto processor” could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that’s on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF’s full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. IBM Crypto Express HSMs are optional (but strongly recommended!) features that are installed as cards in your IBM Z or IBM LinuxONE server’s PCI slots. In recent models there are two variants of the IBM Crypto Express cards: “single port” and “dual port.” Dual port means that there are two physical HSMs per card. It’s simply a higher density card that allows you to support more HSM domains and modes within a smaller physical space, analogous to the difference between a fully populated processor drawer and a partially populated one. Whether you get the single port or dual port variant (or some of both), their role is to protect secrets, especially private encryption keys. They have their own onboard processors to execute cryptographic operations, and you need them to move beyond “clear key” cryptography. Clear key cryptography means your private encryption keys inhabit main memory, the same memory that the operating system, middleware, and applications inhabit. Conceivably that memory could be accessed — via a dump that hasn’t been redacted, for example — to obtain the private keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS are operating with clear key, but “we can do better.” And we do: Crypto Express facilitates protected key and secure key operations. Get them, use them, love them. :-) But let’s leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you’re actually seeing longer transaction times — if you’ve got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference — then there are likely one or two basic reasons why. One likely reason is that you’re not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn’t exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that’s less than ideal for CPACF exploitation. Generally you should “encourage” (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you’re getting. Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there’s an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you’re comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the “cost of doing business” when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if you’ve got CPACF instructions exploited well, but it may be a latency concern. Greater latency, in turn, could have some secondary processor utilization effects. If you’re concerned about the extra network roundtrips that TLS handshaking requires then you can check whether you can establish persistent connections instead. And a persistent connection could be TLS, IPSec/IKEv2, or a SSH
Re: So Long, and Thanks for All the Fish*
Cheryl, Thank you for all the knowledge, experience, and guidance over the years. I appreciate all you've done for the mainframe ecosystem, from the Tuning Letters to Cheryl's Hot Flashes, the Road Shows and everything in between. I've learned from your questions here on IBM-MAIN as much as your answers. I look forward to seeing you once more at SHARE in Orlando in March. As you travel the globe, make sure you pack your Guide, your electronic thumb, and always have your towel with you! Art Gutowski Huntington National Bank On Mon, 22 Jan 2024 23:33:20 -0500, Cheryl Watson wrote: >* For those too young to remember, check out Wiki > >Hi all, > >I’m retiring, but first want to send out a thank you to all the IBM-Mainers >still posting, as well as those who are no longer active. IBM-Main has >provided a life-line to me at times when I had nowhere else to turn. (I >remember one night at 3 am, where I was stuck on a problem, and found someone >who could help me here.) > >I’ve found IBM-Main a wonderful place to learn new tricks, ponder the pros and >cons of different approaches, and learn from some of the brightest in the >industry. (I have to admit that I tend to ignore the posts that delve into the >far annals of time, because I’m more focused on what is happening now.) > >I haven’t been too active recently because Frank Kyne, our outstanding Editor >and President has been more involved in the technical side of things. But I >want you all to know how valuable this group has been to me since it started. >(Yes, I was one of those at the very beginning.) > >For more info on our retirement, please see our blog post at >https://watsonwalker.com/were-retiring/. > >Thanks from the bottom of my heart! > >All my best, >Cheryl Watson >== >Cheryl Watson Walker, CEO >Watson & Walker, Inc. >Sarasota, FL USA >www.watsonwalker.com >Cell/Text: 941-266-6609 >== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
