Re: Encryption and decryption - processor or TCPIP
You are correct. It's on the same piece of silicon NOW. My original point is still good. I don't understand why there is a focus on a minor detail of the physical layout of the chip. Correcting my original statement. "The CPACF is a PIECE OF THE CP 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." Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Thursday, January 25, 2024 10:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP If I'm interpreting the z16 materials right it's within the core's area. -- 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
> Actually, every processor core includes its own CPACF coprocessor section. > In other words, CPACF is "on core." It's a fine distinction. My background is in HW so I describe it as separate from the "CP" proper, even though it is on the same chip. 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
> > 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
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
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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
We don't have to encourage incorrect usage. We should fight back against such inanity. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, January 17, 2024 3:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? Radoslaw Skorupka wrote, in part: >"security by obscurity" means just the key under the mat. I'd agree that it perhaps SHOULD mean that, but that isn't how people use the term. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
I think you underestimate the difficulty in "hacking" the software and that "single spit" of data is much more protected than you let on. As for an IBMer "admitt[ing] that [you were] correct," I strongly suspect that you read WAY more into such a statement than was actually there. Your PS wasn't terribly worrisome either. Of course someone knows all the key part holders to be able to bring them in. That's standard security practice. The risk isn't that someone knows the people. The risk is of collusion. If you have 3 key parts, you need 3 different people to all agree to act nefariously. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Leonard D Woren Sent: Monday, January 15, 2024 9:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? OK. So we've established that the key is set via software. Software can be hacked. And now there's only a single spit of data to focus all the effort on. Years ago at a SHARE presentation, I caught an IBMer after the session and they admitted that I was correct. /Leonard P.S. Someone has to know all the security officers in order to contact them when necessary to input the keys. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
I really like ICSF (having worked on it for over 25 years), but I will say this right now: address-space-switch PCs are not cheap. Trying to shave a handful of instructions to call ICSF is not going to save enough cycles (or elapsed time) to be worthwhile. As Colin points out, storage management will help quite a bit usually. I would suggest that you focus on your application and find the hot spots in it first and see if the pain of trying to rework your crypto calls is worth it. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Sunday, January 14, 2024 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Direct branch entry to ICSF routines Is this to reduce the elapsed time, or that you are doing this a million times a second and want to save CPU? I expect any elapsed time impact is going to be at the sub microsecond level. I would have thought that there are other areas which you might address which might give you a bigger improvement. When I worked for IBM on a z/OS product, we had lots of PC requests. These never really showed up as hot spots. We got improvements from better storage management (avoid getmains/freemains) data arrangement and alignment (and on a 4KB page boundary), elimination of thread interaction at the cache block level Colin On Sun, 14 Jan 2024 at 17:13, Binyamin Dissen wrote: > On Sun, 14 Jan 2024 15:57:47 + Peter Relson > <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > :>Binyamin wrote does that means that the CSFDLL functions do > not create a :>linkage stack entry before calling the true > routines/ :>Could you share why it matters to you if there is a > linkage stack entry (whether before or after getting to the "true > routine", even if my guess is right about what you think of as the > "true routines")? > > Performance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Answering a number of comments in order, in one message. First: I don't think being able to encrypt load libraries is worth it. Encrypted executables, in general, are not going to increase security. Jousma, David: > Encrypt everything with the same HLQ, with the same key > that's a big exposure if the key gets accidentally deleted. > Not sure what the rule of thumb is either, as one key per > dataset turns into a key management nightmare. We had a number of long discussions about this topic and we ended up deciding that there isn't a one-size-fits-all answer, so my guidance would be to do what makes sense in your environment. Whenever I speak on this, I always say that one key for all data sets is too few (as is zero), but so is one key per data set (unless you have a really unusual environment. In general, one key for data sets containing "related data" (however you defined that in your environment) is usually a good guideline. > Additionally, I think IBM dropped the ball a bit in that > nothing stops a permitted user to copy that data to an > un-encrypted dataset. Another topic we discussed. Here's the rub: How would you implement that? What would prevent one application from opening a data set and reading, then closing it and opening a new data set to write out. How would IBM detect that? I get that we could have prevented it for IDCAMS REPRO or similar programs but it would impossible to do it reliably for all possible programs. > The technology that I see as beneficial is one that I think > is in the works with ibm in that data will never be decrypted > including during execution. I forget the term used for that. Homomorphic encryption. Phil Smith III: > If the rational is "Encryption is good because encryption", > that's dangerous, because you're not really protecting very > much. Right. I've been in crypto for a pretty long time and this is the kind of message I keep trying to share. While I want everyone to use cryptography, I want them to use for the right reasons, and not just for everything in the world. I had an issue with the "Everything is encrypted" mantra we had for one of our sales pitches for a previous z model. I get the reason behind it but it set the wrong picture in executives' heads. Rick Troth: > Many people use encryption like it was fairy dust: just > sprinkle it liberally and everything is safer. I love your description. Cryptography, when used properly and consistently, does make things safer, but as you said, the emphasis is on both properly AND consistently. > FPE is brilliant. But like everything else, it's not a be-all > and end-all. Agreed. FPE solves a specific problem and does a great job of it, just like data set encryption. Radoslaw Skorupka: > STGADMIN profiles mitigate the problem, but there is also DASD > access from another LPAR and another security rules. This, to me, is the main reason behind data set encryption. The folks who have authority to the key (and the data set) have access to the data. Those who only have access to the key or to the raw encrypted data have nothing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Tony Harminc wrote: > IBM has been quite mixed in its documentation for the various > "new" callable services that ship with stub routines. Perhaps IBM as a whole but ICSF has documented our interfaces in the same way for at least 20 years. > there is no requirement ... to re-bind with new stubs upon > every z/OS release. Correct. ICSF's stubs (and LE interfaces) are forward compatible, so once you BIND (or link), you don't need to do it again, in general. > I find the whole "bind it with a stub" scheme causes all > kinds of packaging issues For non-LE, I agree with you. > and IMHO IBM should just document > all the calls (as UNIX and RACF do) and perhaps even provide > their own CSRCALL-type macro. As much as I think it's a good idea, it's not very high on our list because there's not been much demand and, as far I know, there has never been a formal requirement for this. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
There is no documentation because this is not a supported interface. It has been suggested in passing but has never been put forward as an official requirement. All LE-capable applications have access to the CSFDLLxx (where xx is 31,3X,64) libraries and the csfbext.h C/C++ header to call directly All non-LE applications have the CSN* and CSN*6 (plus CSF*/CSF*6) assembler stubs. Eric Rossman ICSF Architect -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Friday, January 12, 2024 3:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Direct branch entry to ICSF routines I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. Further research shows that the several routine that I am interested all branch to the same EP, but the stub loads a different value into R0. Don't ask me why there aren't a list of equated values for the various functions and a parameter with the function code. At any rate, high level language routines cannot set R0 but assembler routines certainly can. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSNBENC in LPA?
This was an old requirement that RACF had. It should never have been required (in my opinion) and I got on their (RACF's) case so that it was no longer required. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Wednesday, December 20, 2023 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: CSNBENC in LPA? Sri, I think there is some mess here. You quoted documentation, which is relevant to z/OS 2.3, not 2.5. Yes, the chapter was changed. In other words: z/OS 2.3 and older mention CSNBENC, but z/OS 2.4 and newer does not mention this name at all. However I have found the same text in OMEGAMON 5.5 and I do have it. However I'm not sure whether is it no longer valid due to changes in ICSF and/or RACF. Unfortunately I did not found any clue in Summary of changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBS's "60 Minutes": Quantum Computing
A lot of the "hand-waving" that is done is done for the same reason that we describe the atom using the planetary model to high school students, as the cloud model to undergraduate college students, and then using the probabilistic model to graduate physics students. There is a lot of "stuff" behind quantum calculations that need time to sink in. My responses are all vastly simplified: 1. It's not phrased well in the show. Each qubit is both 0 and 1 simultaneously with the probability of each value being determined by the wave function by which it was programmed. 2. Same problem as #1. Basically, a problem that is solvable by a quantum computer (kind of) assigns probabilities to each bit being zero or one. When the qubits are read back, the quantum wave function (which set those probabilities) collapses so that each is read as either zero or one. 3. Qubits are not at all like transistors. Each classical bit doubles the range of possible values but doesn't double the available calculations. Each qubit actually doubles the number of available calculations. 4. Yes, very much so. Error correction is going to be critical. That's why getting more qubits in a single calculation is not just incrementally harder but polynomially harder (at least for now) as errors compound as more qubits are introduced. (this is the part I know the least about the math behind) 5. I think that was a "hopeful" statement. It's not entirely wrong but not entirely correct either. Quantum computers are great at solving problems involving a large number of probabilities (like factoring large composite numbers into their prime number components, as can be used to attack RSA). So, the shift in thinking will be not so much the programming aspect itself, but the fact that a programmer will have to describe the problem in a probabilistic way instead of a step-by-step way. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Tuesday, December 5, 2023 5:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: CBS's "60 Minutes": Quantum Computing Ok, I watched it. I learned some things, but I still don't get it: 1) Scott Pelley describes the possible states of a bit (0 or 1), and then says "Quantum encodes information on electrons ... [which] behave in a way so that they are heads AND tails and everything in between. You've gone from handling one bit of information to exponentially more data". Omitting the unfortunate misuse of "exponentially", if an electron can be in all states at once, how can a programmer, or the program, determine what data is recorded on it? I don't see how that can be true; they must be using impressive language to gloss over the details. 2) Michi Okaku likens the difference to calculating a path through a maze. A "classical" computer (his word) must check all possible turnings one at a time. But a quantum computer (he claims) "scans all possible routes simultaneously". I can't picture that, and therefore I'm doubtful; again, I suspect him of blathering about something that he really does understand but cannot describe accurately for a 60-Minutes audience. 3) We're shown a diagram of five Q-bits, and the voiceover says "Unlike transistors, each additional Q-bit doubles the computer's power". That is ~not~ "unlike transistors"; it's exactly what traditional bits do. "It's exponential", continues the voiceover, which, again, is exactly what classical bits are. "So, while 20 transistors are 20 times more powerful than one, twenty Q-bits are a ~million~ times more powerful...". Somebody should have vetted this sequence. 4) Karina Chou (sp?) of Google says their quantum computer is making an error about every 100 steps; they're aiming for one every million or so. Even at that target rate they surely need a lot of self-checking and self-correcting, no? 5) Dario Gill, when the interviewer asked whether programmers have to learn a new way of programming, responds "I think that's what's really nice, that you actually just use a regular laptop, and you write a program - very much like you would write a traditional program - but when you click on 'Go', it just happens to run on a very different kind of computer". I cannot reconcile this with the above nor with other statements being made about quantum computing. It's occurred to me that the whole quantum-computing mania might be no more than a huge hoax. I don't believe it, no. But so far I'm utterly clueless how to understand the claims about it. Regardless, thanks, Mr Sipples. Very interesting. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Silence promotes the presence of God, prevents many harsh and proud words, and suppresses many dangers in the way of ridiculing or harshly judging our neighborsIf you are faithful in keeping silence when it is not necessary to speak, God will preserve you from evil when it is right for you
Re: IBM APAR Names
So, VERY old. Interesting. I started with OS/390. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, November 5, 2023 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM APAR Names IBM System/360 Operating System: Concepts and Facilities, GC28-6535-7, Section 2: Program Design, Service Aids, p. 25: "To aid in the diagnosis of problems, seven service aid programs are provided with the operating system: IMAPTFLE (used to create job control statements for applying a Product Temporary Fix -- PTF -- to a system library);" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM APAR Names
I'll admit that we have some alternate expansions of SPE internally. I've heard "significant" or "staggering." I've also heard "Surprise! PE" (PTF in error) From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Sunday, November 5, 2023 12:48:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM APAR Names An aside re SPEs: back in the early 80s, IBM released an SPE for a CMS utility. The original code was on the order of 500 lines; the SPE was something like 3500. Melinda Varian (whom some of you may recall) posted to VMSHARE-the VM-oriented BBS of the era-a review of the change, which had a number of significant problems, concluding: "This is small? This is programming?? This is an enhancement???" I was just starting out, but it solidly cemented the meaning of "SPE" for me! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM APAR Names
I'm not going to claim that I know the whole history of IBM Service (specifically in z), but I will say that Anthony and Seymour are the closest to accurate. I can say that I have 20+ years of experience in ICSF Level 2 (the main debuggers near the start of my career) and Level 3 (the ones who write the fix) and was (for a time) the Level 3 lead. We no longer have PMRs (now Cases) but the concept is the same. A customer reports a problem. L2 looks it over, trying to see if this is (usually in this order): 1. usage question (how do I use ...?) 2. customer mistake (crypto [ICSF, System SSL, etc.] and security [SAF, RACF, etc.], in particular, are very complicated and easy to "oopsie") 3. known problem (customers failing to apply service in a timely happens more than we would like to see) 4. a new problem If it looks like a new problem, L2 works with L3 to decide and open an APAR (Authorized Problem Analysis Report) ["Authorised" if you are not in the US ] Honestly, until today, I had never heard the phrase "APAR Fix". We always call them ++APARs and they are how we (internally) test our fixes. Back when ICSF was a web deliverable, our naming was all over the place for ++APARs. Now, we have a system that we stick to. I cannot guarantee that all z/OS components use the same system, but there is never a chance of a collision in naming. At some point in the past, I know that each rebuild would assign the next letter, (AAn for the first ++APAR, regardless of release) which would lead to collisions in naming. Nowadays, at least in my experiences, any ++APARs that we build replace the O with another letter (usually in the range A-J, but occasionally Z [at least for ICSF]) and that letter will be used for ALL ++APARs at a given release. For example, all ICSF HCR77D1 ++APARs will be DAn. Then, if we rebuild a ++APAR, the name stays the same but it acquires a REWORK() date. For example, a recent fix I shipped for HCR77D1 had its last ++APAR as: ++APAR(DAn) REWORK(2023271). ++APARs are not commonly given out, as we do it only if we want feedback on the fix from reporting customers. This is most common when the problem is really hard to reproduce EXACTLY (such as storage leaks that depend on some interactions of different workloads where we can get close but not exactly the same results as reported). It can also happen when we want confirmation that there is no side effect from a fix (very uncommon but sometimes we want the extra comfort when providing very complicated fixes). I've never seen PTF stand for anything other than "Program Temporary Fix." Our tooling always makes a PTF SUP its corresponding ++APAR, even if we never shipped the ++APAR to customers, just in case. An APAR doesn't fix anything. It's just the "wrapper" for the fixes. For what it's worth, ++APARs are built using the same tooling as PTFs in order for our internal testing to be as close as possible to the PTFs that we ship. As for "current practice," what specifically are you referring to? The vast majority of z/OS-related APARs would be OAn. Most vendor products that I've seen just use a different first letter. I cannot speak to how they name ++APARs or PTFs. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Saturday, November 4, 2023 7:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM APAR Names Like "SPF", what "PTF" stands for depends on the year, but whether problem, product or program temporary fix, its role remains the same. Both an APAR and any resolving PTFs may exist for reasons other than defects, e.g., documentation, Small Program Enhancement (SPE). Is there an edition of the packaging guide that reflects IBMs current practice? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of Anthony Fletcher Sent: Saturday, November 4, 2023 7:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM APAR Names This chain has an interesting range of opinions that I am not going to comment on specifically, other than to point out that APAR started out being the acronym for Authorised Problem Analysis Report which would be outcome of a verified problem, NOT yet a fix. Likewise PTF stands for Problem Temporary Fix. The final fix goes into the next release. The use of ++APAR is really a mechanism to relate an early bypass before the formal fix comes out as a ++PTF. But the bottom line is that any vendor that is using SMP/E has to follow the rules of SMP/E but their naming conventions are theirs as long as they don't conflict with other vendors rules and generate chaos in the SMP/E database,. Vendors don't have to use SMP/E but in my experience the knowledgebase covering problems and solutions is better using SMP/E than any other method. Anthony -Original Message- From: IBM
Re: AMODE was: Why do all entry points have to be in the same class?
I'm not sure what you are saying. I can see in my ASM: xx02 RSECT xx02 AMODE 31 xx02 RMODE ANY And the entry prolog clearly expects to be running AMODE(31) Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Monday, October 23, 2023 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: AMODE was: Why do all entry points have to be in the same class? On Mon, 23 Oct 2023 12:37:30 +, Eric D Rossman wrote: >MEMBER NAME: xx01 MAIN ENTRY POINT: >LIBRARY: LIBIN AMODE OF MAIN ENTRY POINT: 31 >** ALIASES ** ENTRY POINTAMODE > xx02 00x031 > xx03 00x064 > xx04 00x031 Nice they allow this but I suspect that all CSECTs must specify AMODE 64. Since running AMODE 64 has overhead than AMODE 32, it would make sense that IBM would give us an easy method to select an AMODE. -- 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: AMODE was: Why do all entry points have to be in the same class?
I was avoiding wading into this conversation because I'm not quite sure how the binder actually works but something I did want to point out is that entry points in different CSECTs (as shown by the ALIASES below) CAN have different AMODEs. For example, running an AMBLIST against a load module I maintain: MEMBER NAME: xx01 MAIN ENTRY POINT: LIBRARY: LIBIN AMODE OF MAIN ENTRY POINT: 31 ** ALIASES ** ENTRY POINTAMODE xx02 00x031 xx03 00x064 xx04 00x031 Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Sunday, October 22, 2023 4:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: AMODE was: Why do all entry points have to be in the same class? On Sun, 22 Oct 2023 14:55:20 +, Peter Relson wrote: >>Jon P wrote >> Mixed AMODE load modules is a bad thing and very rarely needed. > >I disagree. It's not a "bad thing". There's nothing wrong with switching >AMODE when needed. AMODE switching is not being discussed. The OP is complaining about IBM's choice of having 1 and only 1 AMODE when binding a single load module. He thinks it makes more sense to have a unique AMODE for each ALIAS. The bad thing I'm referring to is having AMODE 24 csects included in a load module linked AMODE 31. You always link a module to it's lowest csect AMODE. > it might well have to switch out of AMODE 64 to call something. Switching AMODEs is essential and I would never say it's bad. To the contrary, I've written programs using AMODE switching. For this discussion, we are discussing the AMODE that is used when a program starts. >> I don't think that AMODE 24 in assembler does anything more useful >> than tell the binder the program must be linked AMODE 24 (not 31/64) >It does two things that come to mind: AMODE specified in the assembler source does not affect the assembly. The value is passed to the binder whereas you say, is used to set the default load module AMODE however technically the binder simply validates AMODE compatibility and that all CSECTs are compatible with the load module AMODE. -- 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: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity
In the very first message with this new subject line, Clem Clarke said "We know that C searches for a byte with a binary zero to find how long a string is." which is what I was responding to. PL/X is good for many things. C is good for many things. So are Java, and Python and Go and Rust, etc. I'm fluent in many languages and none of them is right for every use. Heck, even REXX is great for quick API testing. PL/X and C (and arguably assembler) are not the best at higher level interfaces mostly because they were not designed for that, but they excel at OS-level interfaces because they force the developer to think more concretely (in my experience). Java and Python, on the other hand, were clearly designed with a more abstract approach which leads to better UI. To my original point, even if IBM had released it many years ago, I don't know if PL/X would be dominating. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Tuesday, October 3, 2023 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity PL/X, on the average, is not really better than C in terms of what you describe except when the string's length is known in advance (which is hard or impossible in many circumstances I didn't see stated in any post on this topic the explicit mention of zero-delimited strings. That is what the discussion seems to be talking about. Not all "character areas" are zero-delimited. PL/X has no support for a zero-delimited string. When z/OS interfaces are used within C, there are rarely (if ever) zero-delimited strings. A C program could/would use MEMCPY to copy a string for which the length is known. And there are analogs of that for "compare". That makes it a less natural language construct within C than a zero-delimited string. PL/X does have the concept of a variable-length string (with the length being in a separate variable, or in a preceding halfword). Manipulation of a variable-length string is going to be very different than manipulation of a zero-delimited string. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity
I would say that "inertia" is PL/X's raison d'etre (even though that statement is probably controversial within the internal IBM Z development community). I will acknowledge that PL/X is excellent at integrating HLASM code. GCC style inlining isn't terrible for including HLASM code but it is more painful. I think the reason that PL/X was initially used is because it was the best we had at the time. The reason it is STILL used is because it's too dangerous/difficult to switch. I really don't know why it was never truly externalized (that decision predates my time at IBM) but I could speculate that someone thought it gave IBM some competitive advantage. I don't see it that way, but again, just speculation. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Monday, October 2, 2023 2:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity Eric, I'm curious - wouldn't you say that PL/X integration with assembler and assembler macros is it's raison d'etre? Even though I've done all sorts of integration of assembler with C/C++ (the GCC-style inlining, xplink assembler leaf routines, EDCDSECT conversion of DSECTs, etc, etc), which all work, they are still painful compared with PL/X and assembler. Kirk Wolf Dovetailed Technologies http:// <http://dovetail.com >coztoolkit.com On Mon, Oct 2, 2023, at 12:02 PM, Eric D Rossman wrote: > I write PL/X daily. PL/X, on the average, is not really better than C > in terms of what you describe except when the string's length is known > in advance (which is hard or impossible in many circumstances > > Don't get me wrong, it has a number of strengths as compared to C, but it > also is too close to "the metal" in some ways which would hamper it. > > As for copying byte at a time, that is not a function of C (i.e. not > specified in the standard). It's usually a function of the complier > (sometimes deferred to the runtime libraries) and many of them can use > benefits of the instructions built into the hardware to speed things up as > well as general purpose things like copying DWORDs at a time with small > unrolled loops on either end to handle "extra" > > Eric Rossman > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Clem Clarke > Sent: Monday, October 2, 2023 9:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save > the world and cut CPU Cycles and electricity > > What would it take for IBM to Open Source the Windows and Linux version of > PL/I and PL/X? > > Why? To potentially make the Internet faster and safer. How? > > We know that C searches for a byte with a binary zero to find how long a > string is. This takes time. And then it take time to copy a string > elsewhere, especially if it is done a byte at a time (often true, depending > on the C compiler - some do a word at a time). > > PL/I, Pascal and even Assembler know how long a string is. They don't have > to waste cycle looking for the length of a string. Most of the time, they > know how long the receiving string is, and won't go past the end, as C will. > > IBM still has the "authority" to do this. And it morally should. > > Just do it, IBM. Help save the planet. > > Clem Clarke > > > > > > Wayne Bickerdike wrote: > > So many acronyms. > > I've Been Married > > I've Been Moved > > It's Better Manual > > I Broke Microcode > > > > etc.. > > > > On Mon, Oct 2, 2023 at 4:17 AM David Spiegel < > > 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > > >> Hi Peter, > >> I was generalizing the problem. Allowing access to PL/ wouyld > >> also solve the lack of PDFs. > >> > >> This reminds me of a joke. > >> Q: What does IBM Stand for? > >> A: Ich Bin M'shugoh > >> > >> Regards, > >> David > >> > >> On 2023-09-30 08:18, Peter Relson wrote: > >>>> There is another solution > >>> What are you thinking the "problem" is for which you mention a > >> "solution"? The first post I saw was asking about PDF's, not about > >> access to PL/X. Was there a post that did not show up in the daily > >> digest? The "access-to-PL/X ship" sailed long ago. > >>> Peter Relson > >>> z/OS Core Technology Design > >>> > >>> > >>> -- > >>> -- > >>
Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity
I write PL/X daily. PL/X, on the average, is not really better than C in terms of what you describe except when the string's length is known in advance (which is hard or impossible in many circumstances Don't get me wrong, it has a number of strengths as compared to C, but it also is too close to "the metal" in some ways which would hamper it. As for copying byte at a time, that is not a function of C (i.e. not specified in the standard). It's usually a function of the complier (sometimes deferred to the runtime libraries) and many of them can use benefits of the instructions built into the hardware to speed things up as well as general purpose things like copying DWORDs at a time with small unrolled loops on either end to handle "extra" Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Clem Clarke Sent: Monday, October 2, 2023 9:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity What would it take for IBM to Open Source the Windows and Linux version of PL/I and PL/X? Why? To potentially make the Internet faster and safer. How? We know that C searches for a byte with a binary zero to find how long a string is. This takes time. And then it take time to copy a string elsewhere, especially if it is done a byte at a time (often true, depending on the C compiler - some do a word at a time). PL/I, Pascal and even Assembler know how long a string is. They don't have to waste cycle looking for the length of a string. Most of the time, they know how long the receiving string is, and won't go past the end, as C will. IBM still has the "authority" to do this. And it morally should. Just do it, IBM. Help save the planet. Clem Clarke Wayne Bickerdike wrote: > So many acronyms. > I've Been Married > I've Been Moved > It's Better Manual > I Broke Microcode > > etc.. > > On Mon, Oct 2, 2023 at 4:17 AM David Spiegel < > 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > >> Hi Peter, >> I was generalizing the problem. Allowing access to PL/ wouyld >> also solve the lack of PDFs. >> >> This reminds me of a joke. >> Q: What does IBM Stand for? >> A: Ich Bin M'shugoh >> >> Regards, >> David >> >> On 2023-09-30 08:18, Peter Relson wrote: There is another solution >>> What are you thinking the "problem" is for which you mention a >> "solution"? The first post I saw was asking about PDF's, not about >> access to PL/X. Was there a post that did not show up in the daily >> digest? The "access-to-PL/X ship" sailed long ago. >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> - >> - 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: z13s going EOS anytime soon?
Called it! Unfortunately, it was my worst case scenario. > Subject: Re: IBM Z13 and Z13s EOL > From: Eric D Rossman > Date: Thu, 18 Aug 2022 19:44:39 + > > Long ago, the time from GA to EOS was shorter (like 9 years or so), > then it slowly increased to 12-13 years (and even 14 for the z900 > GA1), but recent models has been slightly less (10-11 years), so my > thinking (again I don't have any OFFICIAL insight): > > worst case: EOY 2024 > best case: EOY 2026 Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Monday, August 28, 2023 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: z13s going EOS anytime soon? https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.13%20-%20July%2011%202023.pdf - slide 4 z13s is EOS on 12/31/2024. Joe On Mon, Aug 28, 2023 at 1:58 PM Claude Richbourg < claude.richbo...@myfloridacfo.com> wrote: > Good afternoon, > > We are currently running on a z13s -2965 and I just started the > planning process of going to a newer processor sometime soon. > > Has anyone heard when the official IBM EOS will be for the z13s? > I have seen different dates 06-30-2026 and now 12-31-2024, so I am not > sure what the real EOS is. > > If anyone knows what IBMs official stance is on the 2965, I would > surely like to know. > > Thanks up front. > > > Best Regards, > Claude > > -- > 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: A question about CPU usage on z/OS
Very true (about MVS and z/OS not limiting address spaces). I recall using CPU affinity back in CMOS days when there were only 1 or 2 CCFs that were physically bound to a given CPU, but that was nearly 2 decades ago now. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, July 13, 2023 12:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: A question about CPU usage on z/OS A task can only use one CPU at a time, but MVS has never limited an address space to a single CPU except for the case of CPU affinity, which I have never seen used. However, many batch jobs do not exploit multitasking and thus cannot exploit multiple CPUs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: regex always returns 1
You used REG_NOSUB on the regcomp, which just verifies the syntax. You want
REG_EXTENDED since you have an extended regex.
Eric Rossman
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Friday, June 30, 2023 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: regex always returns 1
I don't understand. A ^ at the beginning of a character class is a Not. The
regex should match a string of invalid characters, or fail if there are none.
From: IBM Mainframe Discussion List on behalf of
Eric Erickson
Sent: Friday, June 30, 2023 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: regex always returns 1
I'm having an issue with trying to use a regular expression to validate an z/OS
Dataset Name Qualifier. I traverse the DSN using strtok to extract a pointer to
each qualifier. I built a regular expression that works using a web tool to
identify any invalid characters. The string I build using the web tool is
"[^A-Z0-9@#\$\}\-]+" which when I bring that up the mainframe I change to
"[^A-Z0-9@#\\$\\}\\-]+" as I have to double the escape (\) otherwise the
compiler issues a message.
Even when I shorted the regex to ""[^A-Z0-9]+" is returns a 1 for both strings
(SCHEMA or SCH!MA) where I would expect the first to return 1 and second to
return 0.
Basically I'm trying to validate that a string does not contain any lower case
characters or any of the symbols except ($, @, #, -, or }).
Here is a subset of the code.
if (regcomp(, pszDsnPattern, REG_NOSUB) == 0) {
printf("ZDP2999T: RegEx compiled %s.\n", pszDsnPattern);
/*
** Regular Expression compiled, make a copy of the buffer, as strtok
** is going to destroy it during tokenization.
*/
strcpy(cBuffer, pszKeyValue);
/*
** Get the first token in the string.
*/
pszToken = strtok(cBuffer, ".");
/*
** And loop through the string processing each returned string.
*/
do
{
/*
** Perform z/OS Dataset Name Validation. Check the qualifier length
** and first character for validity.
*/
printf("ZDP2999T: Qualifier \"%s\".\n", pszToken);
if (strlen(pszToken) <= 8 & (isupper(pszToken[0]) || pszToken[0] ==
'$' ||
pszToken[0] == '@' || pszToken[0] == '#'))
{
printf("ZDP2999T: Valid first char %c.\n", pszToken[0]);
if ((iRc = regexec(, pszToken, 0, NULL, 0)) == 0)
{
bValidDbHlq = FALSE;
}
}
else{
bValidDbHlq = FALSE;
}
} while ((pszToken = strtok(NULL, ".")) & bValidDbHlq);
/*
** Free the regex allocated storage.
*/
regfree();
Note: I do handle the special case of the first character via a separate test,
but don't want to iterate through the remaining characters in a loop.
This is all under XL C under z/OS 2.5.
--
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: Question on the SLIP command
Normally, you would use the RANGE= option to have the SLIP hit on certain PSWs. Are you trying to see if a particular instruction is present at the PSW? Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Hardee Sent: Tuesday, June 20, 2023 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Question on the SLIP command Hello All, I have a question regarding the SLIP command. In my DA= parameter I have used things like 2r? to reference register 2, etc. Is there a symbol for the PSW? I have tried DA=(PSW?+0,EQ,*myvalue*) and it tells me the DA parm is bad. Thanks, Chuck -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Are you serious about wanting a better IBM doc RCF-type process?
To be clear, that might be IBM's response, but it is certainly not individual IBMers' response. I, for one, appreciate feedback on the ICSF publications. I have personally taken over 20 updates from fine folks like you for our publications. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, May 23, 2023 9:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Are you serious about wanting a better IBM doc RCF-type process? I find it kind of amazing. Here is a bunch of dedicated people, many of us with 40 or more years of experience, willing to help IBM make their documentation better AT NO CHARGE TO IBM. And what is IBM's response? Take a hike. You know, there are many things that have made this platform successful over the years. Certainly, high on the list are the business and the engineering or technical features. But also there is the thoroughness and accuracy of the documentation, and the enthusiastic user community. IBM might want to think twice before messing with the goose that laid the golden egg. Charles -- 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: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall
Phil Smith III said:
> It's also quite possible that someone released something with the "wrong"
> name and got a pass, because it was too late to make all the changes...
I'm not going to give a definitive answer (since I don’t have one), but I will
say "That sounds very plausible."
> P.S. re:
> >("PL/X on System z" is my best take)
>
> That'd be "PL/X on IBM zSystems" now, yes?
You're not wrong about what it should be. Things that get publicly documented
get a LOT more attention from IP lawyers so they are (usually) a lot more
consistent.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall
Branding is very tricky. (hardware branding
https://www.ibm.com/downloads/cas/ROXKD4JV, Red Hat/IBM cobranding
https://www.redhat.com/en/about/brand/standards/red-hat-and-ibm-logos, etc)
BTW, despite posting this using my IBM email, I'm posting this using only
externally visible documentation. I like my job.
It is not a secret that IBM called it "PL/X," nor is it a secret that it is now
called "zPLX." (That name is in several redpapers.)
While it usually implies "hardware" when we leave out the slash, that is not
always the case. zPLX is classified as software ("PL/X on System z" is my best
take). "IBM z Systems Advanced Workload Analysis Reporter" (IBM zAware) is
definitely classified as software. I don't see anywhere IBM is classifying
either otherwise.
Phil Smith III wrote:
>No, but if it's "zPLX", that means IBM considers it hardware. Software would
>be "z/PLX".
>
>Besides being pedantic, this is an interesting distinction here: some stuff,
>e.g., zAware, that seems like it's software is classed as hardware.
>
>Michael Schmitt wrote:
>>Anyone have an idea of what the actual name of zPLX is?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z15 EOM
First, let me say that I have NO inside knowledge. While it doesn't directly answer the question, the official IBM page for "IBM Z mainframe hardware product marketing and service life cycle history since 1994." can be found at https://www.ibm.com/support/pages/ibm-mainframe-life-cycle-history Pages 3 and 4 are pretty good (3 is pretty, 4 is good) So, if the averages hold (I have NO inside knowledge about marketing), HW WDFM would be Oct 2023. Again, let me be 100% clear: I have NO inside knowledge. This is just based on an official IBM publication. Did I mention that I have NO inside knowledge, only an educated guess? As for z17, such a beast does not exist, but I hear that the z16 is quite excellent. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tommy Tsui Sent: Thursday, March 2, 2023 2:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Z15 EOM Hi all Anyone know when ibm will issue the withdrawal letter for z15. Anyone planning to upgrade z17? It seems a bit late due to COVID-19? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx function STORAGE with weird behavior on Netview
That's the expected behavior. STORAGE is documented that the first arg is a string containing the hexadecimal address. A decimal number will be converted to a string in this case but treated as hexadecimal. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Monday, December 19, 2022 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Rexx function STORAGE with weird behavior on Netview Yes they all returned the appropriate values ... But unexpected since 10+0 should have been passed as a decimal number and not a string ... maybe this is IBM REXX v ooREXX ... don't know... 10+4 is 14 decimal and storage treated it as 14 hex just not the behavior I have seen with other REXX implementations... more experimenting -- 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: Rexx function STORAGE with weird behavior on Netview
The first argument to STORAGE is a string. 16 would be wrong.
While it's possible that this won't fix it, the correct syntax would be:
CVT = C2d(Storage('10',4))/* point to CVT */
From the TSO/E REXX Reference:
STORAGE returns length bytes of data from the specified address in storage. The
address is a character
string containing the hexadecimal representation of the storage address from
which data is retrieved.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gorlinsky
Sent: Monday, December 19, 2022 8:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Rexx function STORAGE with weird behavior on Netview
If you are trying to get the cut the address is x10 not 10 try 16 instead of
10… boundary issue if you use 10…
--
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: TKE and USB filesystem
TKE is a closed appliance and only an IBM SSR is allowed to install updates on a TKE. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Wednesday, December 7, 2022 3:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] TKE and USB filesystem I need to update microcode in my TKE. Unfortunately I used USB pendrive formatted as ext-FAT and it was unrecognized. Q: what filesystems/formats are supported by TKE v9? Due to some reasons I'd like to avoid Linux ext2 or ext3, because I copy microcode from Windows 10 machine. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need info
Actually, that isn't relevant to my point. My point was that the wording was intended to mean "body" where it says "message." I wouldn't even start to disagree about the wording needing to be clearer since I agree. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, November 7, 2022 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Need info Actually, "Message content includes the message header section and the possibly structured message body.". The footer inserted by listserv is improperly worded. From: IBM Mainframe Discussion List on behalf of Eric D Rossman Sent: Monday, November 7, 2022 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need info If you look at the footer: > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Terminology has changed somewhat, but "message" means "body". It will not work if you put it only in the subject. You will get a message back: > Subject: Invalid request received from you > > Your message is being returned to you unprocessed because no command > was found in the message body. LISTSERV expects commands in the body > of the message rather than in the message subject because some users > have no control over the contents of the "Subject:" field on outgoing > messages. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, November 7, 2022 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Need info AFAIK, it still works, but you have to send it to the listserv, not to the list. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Sunday, November 6, 2022 11:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need info Not sure if that goes in subject and or body? try both. I think it is not working for several years. On Sun, Nov 6, 2022 at 9:54 AM William J Bishop wrote: > > INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Need info
If you look at the footer: > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Terminology has changed somewhat, but "message" means "body". It will not work if you put it only in the subject. You will get a message back: > Subject: Invalid request received from you > > Your message is being returned to you unprocessed because no command > was found in the message body. LISTSERV expects commands in the body > of the message rather than in the message subject because some users > have no control over the contents of the "Subject:" field on outgoing > messages. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, November 7, 2022 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Need info AFAIK, it still works, but you have to send it to the listserv, not to the list. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Sunday, November 6, 2022 11:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need info Not sure if that goes in subject and or body? try both. I think it is not working for several years. On Sun, Nov 6, 2022 at 9:54 AM William J Bishop wrote: > > INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Crypto Express question
You had me at first and I was very happy. Then you said that you didn't want to work with crypto and you lost me. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Sunday, October 30, 2022 11:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Crypto Express question I do think that having an internal crypto card is quite a benefit, and CCA/ICSF is generally quite nice to work with. That being said, not having to work with any crypto processing at all is even nicer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crypto Express question
The answer is that it depends. If you have a crypto express, you can use it as a clear key RSA accelerator (as mentioned by some folks already) without any consideration of master keys. You can use it as a coprocessor without master keys for a small subset of functions (random number generation first comes to mind, but there are others). Also, regardless of having crypto express, CPACF is useful. Clear key ECDHE (used with TLS) works great with z15 where we added the KDSA instruction. Also used with TLS (1.3 especially likes it) is AES GCM which became a new hardware instruction (KMA) and new function codes for another (PCC) on z14. Eric ICSF design and development -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, October 28, 2022 12:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Crypto Express question We are pushing our "host security module" processing off our mainframe back to our card issuer processor, and I have a couple of questions. If we use ICSF just for TLS and the like, does this still require the DES and RSA keys to be loaded? We already don't have AES or ECC master keys, so I am thinking we wouldn't need DES or RSA keys either. But someone who should know seems to think we still need master keys, even if we're not using it as a crypto coprocessor. Other question is, can TLS encryption processes that use ICSF services work at all if there is no crypto card at all? -- 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: CSNBENC rc=8 rsn=X'271C'
What gave you the impression that this was related to KDFAES? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, October 11, 2022 6:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: CSNBENC rc=8 rsn=X'271C' Pierre, I think you need to understand that KDFAES is not just basic AES encryption. There are other parts of the process designed to slow down dictionary attacks. https://www.ibm.com/docs/en/zos/2.5.0?topic=des-racf-kdfaes-algorithm Lennie Dymoke-Bradshaw ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pierre Fichaud Sent: 11 October 2022 20:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CSNBENC rc=8 rsn=X'271C' I used the ICSF panels. I'll switch to CSNBSAE call. Thanks, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSNBENC rc=8 rsn=X'271C'
How did you use the ICSF panels to create the key? If you used KGUP, you will need to refresh the CKDS to see the updates. Also, once you get that sorted, the call is going to fail anyway. CSNBENC uses DES/TDES keys. It doesn't support AES keys. You will need to switch to CSNBSAE for AES key support. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pierre Fichaud Sent: Tuesday, October 11, 2022 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] CSNBENC rc=8 rsn=X'271C' Using the ICSF panels, I created an AES DATA key (128 bits) called MY.DATA.KEY I fed this into a CSNBENC call and got rc=8 rsn=x'271C'. I'm not sure what I am doing wrong. key-identifier (or label) is MY.DATA.KEY padded with blanks to 64 bytes init-vector is XL8'00' rule array is IPS,INITIAL,TOKEN each 8-bytes and padded with blanks. Regards, Pierre. 271C (10012) A key label was supplied for a key identifier parameter. This label is the label of a key in the in-storage CKDS or PKDS. A key record with that label (and the specific type if required by the ICSF callable service) could not be found. For a retained key label, this error code is also returned if the key is not found in the CCA coprocessor specified in the PKDS record. User action: Check with your administrator if you believe that this key should be in the in-storage CKDS or the PKDS. The administrator may be able to bring it into storage. If this key cannot be in storage, use a different label. REASONCODES: TSS 01E (030) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PSP for Crypto Express 8s
That's unfortunate (that you don't get any access to the IBM support center). That sounds like a hole in our zPDT support to me. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Monday, September 19, 2022 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: PSP for Crypto Express 8s Eric, Many thanks for taking the trouble to post this. I was hoping there was a PSP for the Crypto Express 8 itself (or possibly for 4769Device), but I cannot find that. I have an ADCD system running on a zPDT machine. As such I am not allowed access to the IBM support centre, so I have to research things elsewhere. ADCD does give me access to PTFs but I only have those up to PUT2207. The ADCD is at level ZOS25B but this does not include support for the Crypto Express 8 (although it does include FMID HCR77D2). I was hoping the PSP would guide me to the necessary maintenance. However, I discovered that the latest ICSF manuals include details I need. I need the PTF for APAR OA61609. So I have used that as a base and installed fixes to allow Crypto Express 8 to be installed. At the moment my ICSF is working with the Crypto devices recognised as CEX8s devices. There is a PSP for "Upgrade ZOSV2R5, Subset ICSF77D2" but this does not tell me what I need. Regards Lennie Dymoke-Bradshaw -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PSP for Crypto Express 8s
I'm asking around but perhaps this is what you want: https://esupport.ibm.com/customercare/psearch/search?domain=psp and you search for 3931DEVICE. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Saturday, September 17, 2022 3:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] PSP for Crypto Express 8s I see that IBM are publishing PSP buckets online. For example I found the following, https://www.ibm.com/support/pages/upgrade-zosv2r5-subset-icsf77d2 I am looking to see if there is one for the Crypto Express 8s. Does anyone know how to see a list of PSP buckets, or how to find a specific one? Thanks in advance, Lennie Dymoke-Bradshaw -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Utilities
Are you referring to Encryption Facility? https://www.ibm.com/docs/en/zos/2.5.0?topic=customizing-overview-encryption-facility-zos It is a separate product from ICSF but uses ICSF services for functionality. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, September 9, 2022 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] ICSF Utilites Classification: Confidential Long long ago, in a land far far away... IBM supplied some simple batch utilities w/ICSF that would input a file and output and encrypted version of that file (and vice versa). I can't seem to find any references to these utilities in the current doc. Does anyone remember the name of these fine utilities? TIA, ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- 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: IBM Z13 and Z13s EOL
That was pretty much going to be my thinking too. I don't have any insight into the decision. Long ago, the time from GA to EOS was shorter (like 9 years or so), then it slowly increased to 12-13 years (and even 14 for the z900 GA1), but recent models has been slightly less (10-11 years), so my thinking (again I don't have any OFFICIAL insight): worst case: EOY 2024 best case: EOY 2026 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, August 18, 2022 3:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] IBM Z13 and Z13s EOL Hi Carmen, Just taking a SWAG based on prior history, I would guess you're looking at the end of 2026 for the z13 or z13s to fall off support. https://www.ibm.com/support/pages/ibm-mainframe-life-cycle-history Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Thursday, August 18, 2022 2:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] IBM Z13 and Z13s EOL I understand IBM has not officially published the EOL for the z13 processors but I'm wondering if anyone knows in advance when that date 'may be'? we're looking at some hardware options, and pricing some software, and if we had an idea when our z13 was EOL that would help us make some decisions on HW/SW thanks Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: Encrypted datasets - question about key (pervasive encryption)
The KVV (as Ceci called it) is based on attributes of the dataset (from the catalog) and the key label (from the catalog). If we come up with the same KVV as is stored, we decide that we have the right key (with an error factor of roughly 1 in 2^256... no crypto person every says anything is 100%) Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Monday, June 27, 2022 11:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encrypted datasets - question about key (pervasive encryption) How, in the most general case, perhaps unblocked, binary data, do you know you've got valid data? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encrypted datasets - question about key (pervasive encryption)
It looks like she was using the term KVV to mean the same thing I was referring to. I had just never heard it called that. I think your understanding was fairly close. I was getting hung up on the terminology. Sorry for that. The check is on the OPEN. I'm not from DFSMS but this is my understanding: We use the label from the catalog to retrieve the dataset encryption key and then use the returned key to check that we get back valid data. If anything goes wrong (label isn't found, using the key doesn't return valid data, etc.), we stop the OPEN and fail the operation. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Saturday, June 25, 2022 5:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encrypted datasets - question about key (pervasive encryption) Well, I found the information about KVV in some IBM presentations, like IBM Client Center Montpellier - September 19-22, 2017 IBM Z Security Conference or Pervasive Encryption Overview - z/OS Data Set Encryption, November 15, 2018 both authored by Cecilia Carranza Lewis. Maybe I misunderstood something. Regarding the issue - obviously authors know better than user. :-) I tried to read shared dataset with no key present and with key present, same label, different value. Now the question: how the system knows the key is different? Does it happen before open? My understanding (it seems, wrong one) was quite simple: first check is key label. Next check is key hash or other way allowing to compare key values without knowing them. -- Radoslaw Skorupka Lodz, Poland W dniu 24.06.2022 o 22:03, Eric D Rossman pisze: > While it is true that you can use different CKDS, the label must refer to the > same key (even under different master keys) or you won't be able to open the > dataset. > > There is no KVV anywhere. The value in the catalog for each encrypted dataset > is unique to that dataset and is not directly related to the key. You will > know if you have the correct keys by trying to open the dataset. > > Eric Rossman, CISSP > ICSF Cryptographic Security Development > z/OS Enabling Technologies > edros...@us.ibm.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Radoslaw Skorupka > Sent: Friday, June 24, 2022 3:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Encrypted datasets - question about key (pervasive > encryption) > > Well, labels are unique within ICSF realm or more precisely - CKDS. > However it is possible to share dataset between systems, non-sysplexed to > simplify the considerations. And it is possible (by mistake) to have same > labels but different key values. Or just replace the key by mistake. > > KVV - I meant Key Verification Value. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 24.06.2022 o 20:08, Eric D Rossman pisze: >> Labels for dataset encryption keys (DATA or CIPHER) are unique. You cannot >> have the same label with different types where one of the types is DATA or >> CIPHER. What "KVV" are you referring to? >> >> Eric Rossman, CISSP >> ICSF Cryptographic Security Development >> z/OS Enabling Technologies >> edros...@us.ibm.com >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Radoslaw Skorupka >> Sent: Friday, June 24, 2022 9:14 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [EXTERNAL] Encrypted datasets - question about key (pervasive >> encryption) >> >> Encrypted dataset can be easily recognized using ISPF/PDF 3.4 - I line >> commands. >> However "Encrypted - YES" does not contain some important details. >> Next step could be IDCAMS LISTCAT ENT(dataset) - it shows key label. >> However in some cases it is possible to have two different keys with same >> label. I guess that's why KVV is recorded in VVDS. >> Now the question: how to get information about the KVV without digging in >> VVDS structures? >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> -- 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: Encrypted datasets - question about key (pervasive encryption)
While it is true that you can use different CKDS, the label must refer to the same key (even under different master keys) or you won't be able to open the dataset. There is no KVV anywhere. The value in the catalog for each encrypted dataset is unique to that dataset and is not directly related to the key. You will know if you have the correct keys by trying to open the dataset. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Friday, June 24, 2022 3:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encrypted datasets - question about key (pervasive encryption) Well, labels are unique within ICSF realm or more precisely - CKDS. However it is possible to share dataset between systems, non-sysplexed to simplify the considerations. And it is possible (by mistake) to have same labels but different key values. Or just replace the key by mistake. KVV - I meant Key Verification Value. -- Radoslaw Skorupka Lodz, Poland W dniu 24.06.2022 o 20:08, Eric D Rossman pisze: > Labels for dataset encryption keys (DATA or CIPHER) are unique. You cannot > have the same label with different types where one of the types is DATA or > CIPHER. What "KVV" are you referring to? > > Eric Rossman, CISSP > ICSF Cryptographic Security Development > z/OS Enabling Technologies > edros...@us.ibm.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Radoslaw Skorupka > Sent: Friday, June 24, 2022 9:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Encrypted datasets - question about key (pervasive > encryption) > > Encrypted dataset can be easily recognized using ISPF/PDF 3.4 - I line > commands. > However "Encrypted - YES" does not contain some important details. > Next step could be IDCAMS LISTCAT ENT(dataset) - it shows key label. > However in some cases it is possible to have two different keys with same > label. I guess that's why KVV is recorded in VVDS. > Now the question: how to get information about the KVV without digging in > VVDS structures? > > -- > Radoslaw Skorupka > Lodz, Poland > -- 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: Encrypted datasets - question about key (pervasive encryption)
Labels for dataset encryption keys (DATA or CIPHER) are unique. You cannot have the same label with different types where one of the types is DATA or CIPHER. What "KVV" are you referring to? Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Friday, June 24, 2022 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Encrypted datasets - question about key (pervasive encryption) Encrypted dataset can be easily recognized using ISPF/PDF 3.4 - I line commands. However "Encrypted - YES" does not contain some important details. Next step could be IDCAMS LISTCAT ENT(dataset) - it shows key label. However in some cases it is possible to have two different keys with same label. I guess that's why KVV is recorded in VVDS. Now the question: how to get information about the KVV without digging in VVDS structures? -- Radoslaw Skorupka Lodz, Poland -- 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: Encrypted dataset - any eye catcher?
The service used is CSNBKRR2 with rule PROTKEY (and rule BYPAUTH [older z/OSes] or DSENC [newer z/OSes]). It is in fetch-protected storage for use by PCC(PCC-Compute-XTS-Parameter-Using-Encrypted-AES-256) and KM(KM-XTS-Encrypted-AES-256). Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Friday, June 10, 2022 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encrypted dataset - any eye catcher? Radoslaw, There is an ICSF call used during data set encryption which extracts the secure key from the CKDS and stores it in an encrypted form in "non-addressable" memory for use by the CPACF instructions (e.g. KMC) which process data using protected keys. That ICSF service (I think it is CSNBSYE with KEYIDENT in the rule-array ) uses the Crypto Express device. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: 10 June 2022 12:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encrypted dataset - any eye catcher? This is up to the user. IBM *strongly recommends* the key should be kept as secure. However for non-production environments it is possible to use Pervasive Encryption without CryptoExpress cards. It's fine that you don't have to buy yet another CEXC. BTW: Pervasive Encryption is never serviced by CryptoExpress cards and secure keys. Due to performance reasons it is serviced by CPACF and protected key. CryptoExpress CCA Coprocessor is needed only to keep the dataset key safe (encrypted using MK) in CKDS. Note: Protected key is neither secure key nor clear key. Technically it is not clear, but the way of protection the key is not certified by authorities and standards. -- Radoslaw Skorupka Lodz, Poland W dniu 09.06.2022 o 13:35, Lennie Dymoke-Bradshaw pisze: > I was under the impression that there is no technical requirement for the key > to be a secure key. So data encryption can be used with clear keys in the > CKDS when a Crypto Express is not available. > > Lennie Dymoke-Bradshaw > https://rsclweb.com > FaQ=jf_iaSHvJObTbx-siA1ZOg=wEsRU4BkZTx52MkXPw-33mJ5knyu8ArPRIY8sH7 > icVs=cood93YS6XOkb7_jP41C1bDD0h0Y2c4Z7mDhgJy_1EAWvtIyvBZsIHNCEM1CNe4 > F=yMz-Hw18wFEl8Qx3vWaOjSNAj9qRcLG5b5iO3ElLSM0= > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mark Jacobs > Sent: 09 June 2022 01:48 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Encrypted dataset - any eye catcher? > > I found this in a 2017 IBM Security presentation. So it looks like it's > XTS-AES. > > Key label: 64-byte label of an existing key in the ICSF CKDS used for > access method encryption/decryption. Encryption type: AES-256 bit data > key (XTS, protected key). Note: AES-256 key must be generated as a > secure key (i.e. protected by crypto express AES Master Key) > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > INVALID URI REMOVED > _pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ > =jf_iaSHvJObTbx-siA1ZOg=wEsRU4BkZTx52MkXPw-33mJ5knyu8ArPRIY8sH7icV > s=cood93YS6XOkb7_jP41C1bDD0h0Y2c4Z7mDhgJy_1EAWvtIyvBZsIHNCEM1CNe4F > =-9NFjWxxeIVE7RkH2IVy24xn04vDWeq36ToscpBQAsg= > > > --- Original Message --- > On Wednesday, June 8th, 2022 at 8:38 PM, Phil Smith III > wrote: > > >> Radoslaw's question makes me ask a pure curiosity question: what AES >> mode is used by z/OS data set encryption? I Googled but all I found >> was "256-bit AES", which doesn't answer the question. >> >> >> -- 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: Encrypted dataset - any eye catcher?
Howdy. I'm the author of the core functions used for dataset encryption, in ICSF (CSNBKRR2), BCF (BCFXCRYP/BCFCRYPT), and SAF (the ICSF segment). Confirming: AES-256 XTS mode It uses protected key exclusively for dataset encryption. There is a SAF (CSFKEYS) part of the setup. Caveats: 1. I explicitly coded to support starting with clear keys and converting to protected keys, but we documented only the secure key case in the Redbooks to make that the preferred (and documented) method. 2. BCFCRYPT (the core routine used by dataset encryption) does ship an executable macro BCFXCRYP to allow other exploiters (though I don't know of any outside of IBM). It currently supports both clear and protected keys (only protected keys are used by dataset encryption) as well as XTS and CBC mode (only XTS mode is used by dataset encryption). So, clear keys under a label in the CKDS are supported but we strongly recommend secure keys. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Thursday, June 9, 2022 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encrypted dataset - any eye catcher? I was under the impression that there is no technical requirement for the key to be a secure key. So data encryption can be used with clear keys in the CKDS when a Crypto Express is not available. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: 09 June 2022 01:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encrypted dataset - any eye catcher? I found this in a 2017 IBM Security presentation. So it looks like it's XTS-AES. Key label: 64-byte label of an existing key in the ICSF CKDS used for access method encryption/decryption. Encryption type: AES-256 bit data key (XTS, protected key). Note: AES-256 key must be generated as a secure key (i.e. protected by crypto express AES Master Key) Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Wednesday, June 8th, 2022 at 8:38 PM, Phil Smith III wrote: > Radoslaw's question makes me ask a pure curiosity question: what AES > mode is used by z/OS data set encryption? I Googled but all I found > was "256-bit AES", which doesn't answer the question. > > > > > -- > 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: New IBM Community Blog - ISPF List/Log Viewing
That's only the first half of the link. I'm splitting it across 3 lines to make it clearer (in case your mail program is trying to rewrite URLs. https:// community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck 2/2022/06/02/ispf-list-and-log-improved-access Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Horacio Luis Villa Sent: Friday, June 3, 2022 5:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: New IBM Community Blog - ISPF List/Log Viewing I did that. It leads me to this page: https://community.ibm.com/community/user/blogs/lionel-dyck and I get "page not found" De: IBM Mainframe Discussion List en nombre de Eric D Rossman Enviado: viernes, 3 de junio de 2022 14:48 Para: IBM-MAIN@LISTSERV.UA.EDU Asunto: [EXTERNAL] Re: New IBM Community Blog - ISPF List/Log Viewing It was split across lines. Join the two lines and it works. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Horacio Luis Villa Sent: Friday, June 3, 2022 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: New IBM Community Blog - ISPF List/Log Viewing The link gives me Page not found. De: IBM Mainframe Discussion List en nombre de Lionel B. Dyck Enviado: viernes, 3 de junio de 2022 08:20 Para: IBM-MAIN@LISTSERV.UA.EDU Asunto: [EXTERNAL] New IBM Community Blog - ISPF List/Log Viewing I think y'all will enjoy this new blog https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck 2/2022/06/02/ispf-list-and-log-improved-access Lionel B. Dyck <>< Website: https://www.lbdsoftware.com Github: https://github.com/lbdyck "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - - - John Wooden -- 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: New IBM Community Blog - ISPF List/Log Viewing
It was split across lines. Join the two lines and it works. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Horacio Luis Villa Sent: Friday, June 3, 2022 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: New IBM Community Blog - ISPF List/Log Viewing The link gives me Page not found. De: IBM Mainframe Discussion List en nombre de Lionel B. Dyck Enviado: viernes, 3 de junio de 2022 08:20 Para: IBM-MAIN@LISTSERV.UA.EDU Asunto: [EXTERNAL] New IBM Community Blog - ISPF List/Log Viewing I think y'all will enjoy this new blog https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck 2/2022/06/02/ispf-list-and-log-improved-access Lionel B. Dyck <>< Website: https://www.lbdsoftware.com Github: https://github.com/lbdyck "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - - - John Wooden -- 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: Trouble getting new mainframe staff?
Take responsibility for your own posts, Bill. No one makes you respond. The same thing I tell my kids: I don't care who started it. Anyone has the ability to end it. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Monday, March 21, 2022 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Trouble getting new mainframe staff? Tell that to the person who started it and lay off always blaming me. Sent from Yahoo Mail for iPhone On Monday, March 21, 2022, 1:14 PM, Eric D Rossman wrote: Enough Bill. Why are we allowing politics on the list? Don't we have any moderators? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trouble getting new mainframe staff?
Enough Bill. Why are we allowing politics on the list? Don't we have any moderators? Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR closures
There are a few other APAR resolution codes that I have found defined in various public documents but I have never seen them: ADM: Partially closed APAR; admin info; technical info to follow MCH: Machine / microcode error REQ: Requirement for future development STD: Open Systems Standards deficiency Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR closures
I was actually just about to say FIN is really Fixed IF Next when your message came in. I've never seen a RET, DU*, or USE. In general, our service folks don't actually open an APAR until we understand the issue. If we accidentally open one (or change our mind), we usually CANcel the APAR with an explanation that the APAR was opened in error. Now that I think about it, I have seen SUG but never actually used it myself. Eric Rossman, CISSP ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Tuesday, March 1, 2022 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: APAR closures Ah, RET sounds like what I was (mis?)remembering as IDOC: RET - Returned to the user for more documentation Note that the page is not 100% correct (and yes, I saw its disclaimer), as it says: FIN - Fixed in next release and we all know that's "Fixed IF next release" because IBM does not preannounce! (Yeah, that's probably sorta dead, but I remember IBM being VERY VERY clear about that in the years immediately after the consent decree.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS file level encryption for Nacha Requirements
I'll pile onto Lennie and Timothy's messages. I'm the author of the ICSF and SAF parts of dataset encryption and one of the authors of the mentioned redbook and I know that some of the other authors are on the list, so we will happily get you answers. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF - crypto # to PCHID relationship
Radoslaw Skorupka wrote on 02/11/2022 at 06:21 AM: > Every CryptoExpress engine has two identifiers: PCHID and number used in > ICSF panels. > Both identifiers can be seen in SE. > PCHID number is not available in ICSF (why???) > > However I'm wondering how the crypto numbers are assigned. > PCHID - it is determined by location of the card, as well as FICON or OSA. > However I observed two machines with same number of CryptoExpress cards, > same PCHID numbers for the cards, but different crypto number > assignments. Both machines are z15, ordered, delivered and installed > together. No difference in model, microcode, features like FC 3863... > Any clue? I did a bunch of asking around, combined all the answers, and then paraphrased: The IDs are assigned during the 1st power up, starting with the lowest available ID. If I add cards via HOT plug, I can pick and choose IDs. It depends on the exact hw that was plugged and in what order. FC 898 is 2 cryptos per card vs FC899 1 crypto per card Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rocket Vim fileencoding (was: ... ASCII ...)
"David Crayford" wrote: > On 10/2/22 8:29 pm, Seymour J Metz wrote: > > I couldn't imagine voluntarily using an editor that didn't have a > > good macro language. The ubiquity of vi is certainly a good reason > > to learn it, but not to use it routinely. > > Huh? I use nvim (neovim) which has the full force of Lua for writing > plugins, and that includes customizing the UI. I can't even write a > custom syntax highlighter for ISPF! > > I take it you don't know much about Vim? I'll second the vote for Vim (I use Gvim most of the time). Powerful and simple. Much better than emacs Eric Rossman, CISSP® -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does this make no sense or is it just me?
"Seymour J Metz" wrote: > Redundancy is only part of the cost. Historically, when they > replicate information on syntax for other components, they get it wrong. > > The ISPF Edit Ref. does give REXX examples, but there are issues > with some of them. > > The lack of synchronization would have been easy to fix had IBM > continued using BookManager markup instead of WYSIAYG word processors. I'm not going to air any dirty laundry but I definitely got the impression that many of the pubs writers would agree with you regarding BookManager. Given how long we were a web deliverable (instead of tied to a z/OS release), ICSF tried very hard to NOT embed any explanations, examples, etc for other products. Instead, we tried to link/point to other pubs where the real experts could describe their own product. The only things related to other products in our pubs were actual samples we shipped (like dataset allocation samples, ICSF started proc, etc) Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTSERV Noise?
"Grant Taylor" wrote: > On 1/27/22 7:05 AM, Eric D Rossman wrote: > > Yeah, yeah. Semantics. :) > > In some ways it's not /just/ semantics. True. I was trying to add a little levity there. > > Bottom line is that this is a well-established convention. It is NOT > > a defined standard anywhere. Heck, RFCs aren't standards at all anyway. > > Actually, many RFCs are considered standards track and are the > definitive source for some things. Oh, I completely agree. I was pointing out that the RFCs always state that they are not standards, even when they really are. I certainly use RFCs in my work and have to adhere. (Look at how many of the PKCS are also RFCs) > > It was never codified anywhere that I can find. My best guess is that > > it was a handshake agreement on some early email support and just > > "stuck." > > Maybe ~> probably. > > I would actually be quite happy to find an RFC that has a SHOULD or MUST > for the "-- " standard. If for not other reason than to print out, roll > up, and bop some people about the head / shoulders with. ;-) Works for me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTSERV Noise?
"Grant Taylor" wrote: > On 1/26/22 7:24 PM, Seymour J Metz wrote: > > See RFC 3676, The Text/Plain Format and DelSp Parameters: > > 4.3. Usenet Signature Convention > > RFC 3676 § 4.3 seems to be documenting an existing convention. > (IM(ns)HO) It does not /define/ nor /specify/ the convention. > > At most it is an acknowledgement ~> acceptance of an existing convention > defined / specified elsewhere. Yeah, yeah. Semantics. :) Bottom line is that this is a well-established convention. It is NOT a defined standard anywhere. Heck, RFCs aren't standards at all anyway. It was never codified anywhere that I can find. My best guess is that it was a handshake agreement on some early email support and just "stuck." -- Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTSERV Noise?
Paul Gilmartin wrote: > On Tue, 25 Jan 2022 17:48:30 -0500, Phil Smith III wrote: > > >There is an old standard that a line comprising: > > > >hyphen hyphen space linend > > Cite? RFC? https://www.ietf.org/rfc/rfc2646.txt Section 4.3 Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and domain sharing
"Dave Jousma" wrote: > You have to be careful though, because the MK for the domain is the > same on both adapters, That is true only if both adapters are on the same LPAR. If they are on different LPARs, there is no requirement that they be the same. However, I would recommend it because it makes the documentation easy (and you have 85 domains that you can use, so why not?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and domain sharing
Radoslaw Skorupka wrote on 01/06/2022 10:04:59 AM: > Thank you for the clarification and excuse me for next question: are you > sure one can have i.e. LPARX using Crypto01 in domain 10 (no other > crypto cards) *and* LPARY using Crypto02 in domain 10 both activated? > As I said my memory is poor, however I vaguely remember such combination > was impossible as well as plain domain & cryptocard sharing - that mean > several LPARs using same domain ID and same card(s). > I know such restriction is, let's say, unreasonable but AFAIR that was > in effect . Unfortunately I cannot simply check it. I can confirm this works. The only restriction is that no crypto and domain combination is in more than one LPAR on a given CEC. Having LPARX using Crypto01 on domain 10 and LPARY using Crypto02 on domain 10 is 100% allowed. Having both LPARX and LPARY using Crypto01 on domain 10 will not be allowed. Whichever is activated first will be fine and the other LPAR will not be allowed to start. Now, one point of confusion is that this is for a given CEC. If you have two CECs, domains and crypto indices are not cross checked, only within a CEC. Eric -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and Z EOD (and Pervasive Encryption)
I see it. Discussing with the team now. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com > From: "Dave Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> > > RFE submitted: > > Headline: Add ICSF Flush command > ID:153608 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and Z EOD (and Pervasive Encryption)
It sounds like a "SETICSF FLUSH" command or similar is what you are
suggesting. ("don't turn off any options, but ensure that everything up to
that point is flushed/handled").
I would ask you to open an RFE and post back here so others can vote for
it. That will make it easier for me to push for it.
As always, I cannot promise anything, but I think this is a good idea.
Eric Rossman, CISSP®
ICSF Cryptographic Security Development
z/OS Enabling Technologies
edros...@us.ibm.com
Dave Jousma wrote on 01/03/2022 at 03:31 PM:
> Thanks again Eric. I'd like to see IBM "clean up" that last little
> bit of housekeeping and really make ICSF task a "hands off" task
> with regards to starting/stopping. Its going to get more difficult
> to run without anyway. For me, losing those last few SMF records
> or last used updates on key records is less of an issue than not
> being able to serve the encrypt/decrypt request at all.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and Z EOD (and Pervasive Encryption)
Dave Jousma wrote on 01/03/2022 at 02:43 PM: > On Sat, 1 Jan 2022 21:01:06 -0400, Eric D Rossman wrote: > > >I think you have the right idea. > > > >You want ICSF started as early as possible and ended as late as possible. > > > >You likely want to use early ICSF which will run ICSF under the MASTER > >address space instead of JES (either via the ICSFPROC and ICSF system > >parameters [preferred] or via COMMNDxx using S CSF,SUB=MSTR) and configure > >ARM to restart ICSF. I don't recall the details but I believe that ARM > >will not work for system address spaces (like ICSF when started under > >MASTER) on older z/OS releases. I know for sure that it works for system > >address spaces on V2R5. > > > >Ensure that the P CSF is done after all exploiters are stopped (definitely > >after Z EOD). > > Eric, thanks for responding from IBM. We run with early ICSF > started under master from IEASYS00 settings. Is it even necessary > to shutdown CSF on system shutdown? I ask because with so many > things using encryption now, including CF structures, etc, there is > likely a window for problems? That's a really good question (and a complicated one). While the recommendation is to terminate ICSF to allow for a clean shutdown of tasks, I think a STOP ICSF can be (mostly) safely avoided. There are a few asynchronous tasks that ICSF cleans up when it terminates. What comes to mind as being most relevant is data related to key usage/key lifecycle and reference dates. Instead of recording every piece as it happens, we queue up and periodically record it, both to SMF records (usage/lifecycle) and in the CKDS/PKDS/TKDS records (reference dates, if using KDSR format). If SMF is already stopped, ICSF SMF records related to key usage and key lifecycle won't get recorded, so perhaps the best option would be to use the operator commands to tell ICSF to stop recording both key usage/lifecycle and reference dates and flush everything it has cached for both categories. If you do that, both the SMF records and ICSF KDS updates will happen immediately. Then, you can safely issue the Z EOD to harden the SMF records. I cannot say that it's perfect (obviously, none of the actively after the operator commands will get recorded), but at that point, you have already terminated just about everything anyway, so you are unlikely to miss much. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and Z EOD (and Pervasive Encryption)
I think you have the right idea. You want ICSF started as early as possible and ended as late as possible. You likely want to use early ICSF which will run ICSF under the MASTER address space instead of JES (either via the ICSFPROC and ICSF system parameters [preferred] or via COMMNDxx using S CSF,SUB=MSTR) and configure ARM to restart ICSF. I don't recall the details but I believe that ARM will not work for system address spaces (like ICSF when started under MASTER) on older z/OS releases. I know for sure that it works for system address spaces on V2R5. Ensure that the P CSF is done after all exploiters are stopped (definitely after Z EOD). As for PAGENT, I'm not an expert (so someone can correct me if I misspeak). Anything that calls ICSF directly would fail, but if past the handshake stage, it's quite possible that the the derived transport key would be able to used in a software provider or via CPACF directly (I don't recall all the details, but I do know that System SSL can fall back if ICSF is not available). One thing to note: you can bounce ICSF without failing requests by using the dynamic service functionality we introduced in HCR77D0 (SETICSF PAUSE). That will allow ICSF to finish requests in process, then suspend new callers. This is best paired with either ARM or some other automation to restart ICSF, at which point the suspended callers will be resumed and continue on processing. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 01/01/2022 06:25:31 PM: > From: "Radoslaw Skorupka" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/01/2022 06:25 PM > Subject: [EXTERNAL] ICSF and Z EOD (and Pervasive Encryption) > Sent by: "IBM Mainframe Discussion List" > > I have a question about recommended ICSF started task start and stop > sequence. > > In the old days I started is just before the application and ended after > the application was shut down. > Nowadays we can have encrypted spool so ICSF should (must?) be started > before JES2. > And before access to encrypted datasets. > However, as far as I know, also SMF records can be encrypted - so ICSF > should be active as long as SMF recording is active. That would mean "P > CSF" command should be issued after "Z EOD". > > Am I right with the above? > > > Another questions: what would happen with PAGENT when ICSF is > accidentally closed? All terminal connectivity (TLS/SSL) would be lost? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long time between IPLs a security risk? was Re: What is OVMSKERN?
I'll tell you the same thing I tell my children: I don't care who started it. End it. Act like a mature mainframer. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 12/23/2021 12:18:28 PM: > From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu> > > I didn’t start this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long time between IPLs a security risk? was Re: What is OVMSKERN?
Look, knock it off and take your pissing contest elsewhere. Can a moderator PLEASE remove these folks from the list or at least put them on moderation so we can actually enjoy the list? Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU and encrypted files
The secure solution is to set up your target environment ahead of time. Do you use a TKE? Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com Tieline: 295-6882 or (845) 435-6882 "Cameron Conacher" <03cfc59146bb-dmarc-requ...@listserv.ua.edu>: > Yeah, > Don't encrypt original, or provide Master Encryption Keys to new environment. > I was hoping for the magical incantation for ADRDSSU to do exactly > what I need without me actually doing anything. > > Thanks everyone, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fall back STP Adjustments
It falls back from 0100am to 1200am in your scenario, never switching days Sent from HCL Verse Gibney, Dave --- [EXTERNAL] Re: Fall back STP Adjustments --- From:"Gibney, Dave" <03b5261cfd78-dmarc-requ...@listserv.ua.edu>To:ibm-m...@listserv.ua.EDUDate:Mon, Nov 1, 2021 3:02 PMSubject:[EXTERNAL] Re: Fall back STP Adjustments A fallback from 2am to 1am local time would be correct, A fall back to yesterday, (1am to 12pm) would not be a good idea on many levels> -Original Message-> From: IBM Mainframe Discussion List On> Behalf Of Carmen Vitullo> Sent: Monday, November 01, 2021 11:32 AM> To: IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Fall back STP Adjustments> > my time variables for USS in etc/profile and cee parms have been a non issue> > new to me and my issue is when the STP timer actually falls back, 1am or> 2am based on the doc I have with automatic time adjustment being done> @7AM UTC time> > > Carmen> > On 11/1/2021 1:24 PM, Paul Gilmartin wrote:> > On Mon, 1 Nov 2021 12:59:43 -0500, Carmen Vitullo wrote:> >> >> I was mistaken yes 7am UTC> >>> > And do you have the correct setting in the various (too many) OMVS> > configuration files? For exampe:> > 526 $ tail -1 /usr/share/zoneinfo/America/Chicago> > CST6CDT,M3.2.0,M11.1.0> >> > (CST6CDT) should suffice. If so, OMVS processes should adjust> > automatically. Would that Classic MVS were so clever!> >> > Even better: zones__;!!JmPEgBY0HMszNaDT!-qT2O4u-> T4WtJM01qe0HGqiE_qx_VtEqz3EeCoCyXgxRcTlVy0-NzHPAyMeYnA$ >> > It's free! z/OS Java uses it.> >> >> >> On 11/1/2021 12:57 PM, Ramsey Hallman wrote:> >>> Central Daylight Time is 5 hours BEHIND UTC. As I write this, it's about> >>> 13:00 CDT. That's 18:00 UTC.> >>> Are you sure about the 7 *PM* time 7AM UTC would be 2AM CDT.> >>> On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo \wrote:> I hate to beat a dead horse as it relates to time change, but this year we> have a new z15 and the new HMC version. we're setup currently for> automatic> adjustment, my question is that's not in the doc I have; the time will> change @7PM UTC time according to the doc, so that means 2AM> Central time?> or 1AM central time> > -- gil> >> > --> > For IBM-MAIN subscribe / signoff / archive access instructions,> > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN> >> --> /I am not bound to win, but I am bound to be true. I am not bound to> succeed, but I am bound to live by the light that I have. I must stand> with anybody that stands right, and stand with him while he is right,> and part with him when he goes wrong. *Abraham Lincoln*/> > --> 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: Fall back STP Adjustments
It ticks from 015959 to 01. You get 01-015959 twice, but 02 just once Sent from HCL Verse Retired Mainframer --- [EXTERNAL] Re: Fall back STP Adjustments --- From:"Retired Mainframer" <03a485c129c3-dmarc-requ...@listserv.ua.edu>To:ibm-m...@listserv.ua.EDUDate:Mon, Nov 1, 2021 3:21 PMSubject:[EXTERNAL] Re: Fall back STP Adjustments I think the answer is both. AT 0700 UTC it will be 0200 CDT. After an infinitely small interval, it will still be 0700 UTC but will be 0100 CST. At the time of transition, either CST is correct (or maybe neither are). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, November 1, 2021 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fall back STP Adjustments I hate to beat a dead horse as it relates to time change, but this year we have a new z15 and the new HMC version. we're setup currently for automatic adjustment, my question is that's not in the doc I have; the time will change @7PM UTC time according to the doc, so that means 2AM Central time? or 1AM central time thanks Carmen (mostly confused) -- 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: Question about negative indexes
By the way, I just wanted to say that I REALLY ENJOY these sorts of conversations (technical ones) on this list. The obnoxious sniping we are seeing between some of our members needs to stop. I don't understand why the moderators let it continue. If it were me, the folks doing the sniping would be removed from the list fairly quickly. Anyway, a "thank you" to Joe for bringing up this interesting topic, and to all the folks who have chimed in (especially gil and Peter who both brought up some great points and some confusing phrasing in the pubs that IBM should fix). > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > > On Sun, 24 Oct 2021 08:55:00 -0400, Peter Relson wrote: > >For CPU table entries that are addressed by real or absolute addresses, it > >is unpredictable > >whether the address wraps or an addressing exception is recognized. > > Does "unpredictable whether the address wraps" imply that in AMODE 31 > the sign bit might be set to 1, or that in AMODE 24 the leftmost octet > might be set other than to x'00'? Given how we write the architecture on System z, it means exactly what it says: "unpredictable". It WOULD be deterministic for a given CPU but we make not promises across multiple generations of CPU. We (IBM) are constantly trying to improve performance for common cases, which is why PoPs claims unpredictability for cases that no reasonable program should generate. > Paul G wrote: > I stand by my assertion: > On Sat, 23 Oct 2021 20:32:41 -0500, Paul Gilmartin wrote: > >... > >An exception is *never* recognized on an LA instruction, even > though wraparound > >might occur or the value before truncation exceeds 24, 32, or 64 bits. I agree with this assertion but not your statement that: > >An interrupt condition is *never* recognized "during generation of [an] > >address." Sorry if that wasn't clear. I purposely snipped quite a bit of the documentation as I was trying to answer the original question about whether index registers are signed (they are not) and WHY using a 2s complement format in an unsigned 64-bit field actually works even though it's not really documented that way (address wraparound). > >(I don't know exactly what a "CPU table entry" is in this context.) > > > I readily suspect that the writer knew no better than you and merely > supplied the output off a Travesty Generator. I thing the Travesty Generator statement is a bit too much. My guess as to what happened: Our pubs writers tried really hard to make things clear but in trying to edit the technical details, they slightly mixed them up or left out some details that would have clarified. I do agree that you should submit an RCF to get that section cleared up. When none of the multiple technical folks reading a definitive source (Principles of Operations) don't understand what something means in a given context, that says it really needs to be made clearer. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about negative indexes
Yes, long (20-bit) displacements can be negative, while regular (12-bit) displacement can not. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "Hobart Spitz" : > AFAIK, RXY format instructions support negative offsets just fine. > > LHY 5,-1(0,12) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about negative indexes
I think I understand where you got confused. Quoting: "Addresses generated by the CPU that may be virtual addresses always wrap." The cases where interrupts can happen are not with virtual memory accesses (such as your example). Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>: > An exception is *never* recognized on an LA instruction, even thoughwraparound > might occur or the value before truncation exceeds 24, 32, or 64 bits. > > The sequence: > LHG R1,=H(-1) > L R2,0(,R1) > ... is pretty much guaranteed to recognize an exception, but not because of > wraparound or truncation to 24, 31, or 64 bits. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about negative indexes
You are welcome to submit an RCF. However, the interruption is not on accessing storage. It is on the address wrapping. I'm not involved in the architecture but I strongly doubt that the book is wrong. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>: > I'll disagree with that. An interrupt condition is *never* recognized > "during generation of [an] address." An addressing exception or a > protection exception may be recognized subsequently when that > address is used to access storage. And that is unrelated to whether > a carry out of the high-order bit position occurred. > > Address generation and storage access are two different topics. They > should be discussed separately. > > Should I submit an RCF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about negative indexes
By definition, base and index registers are treated as 64 bit binary values (unsigned), with only the relevant bits (24, 31, or 64) used. The relevant bits are simply added with overflow discarded. There is no sign bit to ignore. In Chapter 3 (Storage), section Address Wraparound: When, during the generation of the address, an address is obtained that exceeds the value allowed for the address size (2^24 - 1, 2^31 - 1, or 2^64 - 1), one of the following two actions is taken: 1. The carry out of the high-order bit position of the address is ignored. This handling of an address of excessive size is called wraparound. 2. An interruption condition is recognized. ... Addresses generated by the CPU that may be virtual addresses always wrap. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com On Sat, 23 Oct 2021 11:33:33 -0500 Joe Monk wrote: > Howdy, > > I know this will probably be an easy answer for somebody... but I dont deal > with AM64 much. > > If Im in AM64 and I load an index register with -1, does the machine ignore > the sign when using it in an RX instruction such as STC? > > I know it ignores the sign in AM24/31... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Modernization
What kind of "lies- smoke and mirrors" do you see that IBM should be pushing back on with our marketing? I'm just a highly technical crypto guy, so I don't write the marketing copy, but you have piqued my interest. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "Ron Wells" wrote on 10/21/2021 09:05:05 AM: > IBM needs to push back in Marketing , be more forceful stop the > lies- smoke and mirrors -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Hash with a certain seed (Key)
Gil wrote on 09/16/2021 04:13:24 PM: > You might make your code more robust (and easier to review) by coding" > Const.ASCII =XRANGE( '20'X, '7E'X')XRANGE( 'A0'X, 'FE'X') > and using CSNBXEA to compute Const.EBCDIC. (I added the top half > of ISO-Latin.) What about control characters, particularly newlines? Not relevant to what I was testing, so I didn't bother with characters out of range. > > CSNBXEA is very limited. z/OS provides real conversion APIs where > > you provide the source and destination code pages. > > E.g. iconv. Exactly. For some reason, my brain blanked on iconv. If you are hashing something, the best way is to convert the data to the target code page (assuming it is even text at all), hash, and then send both the message and the hash as binary. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Hash with a certain seed (Key)
That's a lot of questions but I will answer some of them. Gil wrote on 09/16/2021 03:52:06 PM: > What does a "HASH" have to do with a "seed"? Isn't a hash algorithm > such as SHA-1 deterministic, repeatable, so that (e.g.) CSNBOWH will > produce the same result for a given message every time? (I verified > the availability of CSNBOWH by passing it "Hello, World!' and > verifying the output.) In this case, the term seed was being misused. When you generate an HMAC, the key is part of the operation. Effectively, it "seeds" the operation, so the same message would result in two different HMAC values with different keys. The same kind of effect from hashing two strings with different prefixes prepended. > Does ICSF's random number generator support seeding? No. We prefer to get our random bytes from the CCA coprocesor ( https://csrc.nist.gov/projects/Cryptographic-Algorithm-Validation-Program/details?source=DRBG=2130 ) If that is not available, we will exploit the PRNO-TRNG (MSA Extension 7 on z14) with the PRNO-SHA-512-DRNG as a hybrid DRNG. > And the suggestion of translating the message to hex and hashing the > hex stream can fail depending on whether the hex is represented in > ASCII or EBCDIC. The message being hashed is a binary stream and technically has no encoding whatsoever. The only requirement is that the message being hashed (or HMACed) is unchanged (binary) between operations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Hash with a certain seed (Key)
'hmg_rc' 'hmg_rs' ,
> 'hmg_exit_length' 'hmg_exit_data',
> 'hmg_rule_count' 'hmg_rule_array' ,
> 'hmg_key_id_len' 'hmg_key_id' ,
> 'hmg_text_length' 'hmg_text' ,
> 'hmg_chain_vector_length' 'hmg_chain_vector' ,
> 'hmg_hmac_length' 'hmg_hmac' ;
> if (hmg_rc /= ''x) Then
> do;
> say 'HMG Failed (rc=' c2x(hmg_rc)' rs='c2x(hmg_rs)')' ;
> signal ExitScript;
> end;
> say "HMAC : " hmg_hmac
> sqy "HMAC hexa: " c2x(hmg_hmac);
> /*---*/
> /* CSNBXEA */
> /*---*/
> /* EBCDIC to ASCII */
> EBCDIC_to_ASCII:
> xea_return_code = ''x ;
> xea_reason_code = ''x ;
> xea_exit_data_length = ''x ;
> xea_exit_data = '';
> xea_text_length = text_EBCDIC_len ;
> xea_source_text = text_EBCDIC ;
> xea_target_text = copies('00'x,c2d(text_EBCDIC_len));
> xea_code_table = '';
> ADDRESS LINKPGM 'CSNBXEA' ,
> 'xea_return_code',
> 'xea_reason_code',
> 'xea_exit_data_length',
> 'xea_exit_data',
> 'xea_text_length',
> 'xea_source_text',
> 'xea_target_text',
> 'xea_code_table' ;
> text_ASCII = xea_target_text ;
> return;
> Exit;
>
> On Wed, Sep 15, 2021 at 3:24 PM Eric D Rossman
wrote:
>
> > Confirmed. When I treat both as ASCII, I get the same answer:
> >
> > /* "ABCabcAB12345678" */
> > Key =,
> > '41424361626341423132333435363738'X;
> >
> > /* "Hola Mundo" */
> > Msg =,
> > '486f6c61204d756e646f'X;
> >
> > expected_Mac =,
> > '7483f0f47d20c89256805b69936ebdc31e62d99a40f6640b334c6b5a8d83df5e'X;
> >
> > Eric Rossman, CISSP®
> > ICSF Cryptographic Security Development
> > z/OS Enabling Technologies
> > edros...@us.ibm.com
> >
> > "IBM Mainframe Discussion List" wrote on
> > 09/15/2021 02:18:25 PM:
> >
> > > From: "Charles Mills"
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date: 09/15/2021 02:18 PM
> > > Subject: [EXTERNAL] Re: ICSF Hash with a certain seed (Key)
> > > Sent by: "IBM Mainframe Discussion List"
> > >
> > > Actually, as I think more, perhaps the Web site is computing the
> > > hash on the ASCII value of ABCabcAB12345678 which would be
> > > X'41424361626341423132333435363738' while the mainframe tool is
> > > perhaps taking ABCabcAB12345678 as hex? Try taking the mainframe
> > > hash of the hex string above and see if it is the same as what the
> > > Web site gives you.
> > >
> > > Charles
> >
> >
> > --
> > 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: ICSF Hash with a certain seed (Key)
Confirmed. When I treat both as ASCII, I get the same answer: /* "ABCabcAB12345678" */ Key =, '41424361626341423132333435363738'X; /* "Hola Mundo" */ Msg =, '486f6c61204d756e646f'X; expected_Mac =, '7483f0f47d20c89256805b69936ebdc31e62d99a40f6640b334c6b5a8d83df5e'X; Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 09/15/2021 02:18:25 PM: > From: "Charles Mills" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/15/2021 02:18 PM > Subject: [EXTERNAL] Re: ICSF Hash with a certain seed (Key) > Sent by: "IBM Mainframe Discussion List" > > Actually, as I think more, perhaps the Web site is computing the > hash on the ASCII value of ABCabcAB12345678 which would be > X'41424361626341423132333435363738' while the mainframe tool is > perhaps taking ABCabcAB12345678 as hex? Try taking the mainframe > hash of the hex string above and see if it is the same as what the > Web site gives you. > > Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Programs that work right the first time.
Anyone who is writing something brand new and NOT referring to other working models (similar code chunks) is wasting their time. No one can keep everything in mind at once, especially once you start talking about truly complex beasts. NB: I'm assuming your question is not necessarily limited to standalone programs that are 100% of the function but should also include modules that can be plugged in (such as shared objects/DLLs and Linux kernel modules). For all of this, I'm only talking about fairly unique code, not small tweaks to existing code or rebuilding several chunks together to make a larger program. I've written a few dozen programs that are >1000 lines. I've never had one work perfectly the first time. With code of that size, the odds of having it work completely correctly the first time are astronomically small. I've probably written hundreds of new small (<50 LOC) programs. I would estimate 5% work correctly the first time (the benefit of experience with very similar programs). For the middle sized programs (on the order of 100s of lines), I would say that I've had maybe one or two out of hundreds that worked the first time. So, on the average, excluding code that is really just simple modifications of existing code, I would say 2-5% work correctly the first time, depending on how similar to something I have written before they are. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 08/21/2021 09:30:58 PM: > From: "Bob Bridges" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/21/2021 09:31 PM > Subject: [EXTERNAL] Programs that work right the first time. > Sent by: "IBM Mainframe Discussion List" > > This part of the thread got me thinking. How often do you write a > program that works right the first time, with no compile or > execution errors? I'm not talking about two-liners, of course, or > even ten-liners; let's say 30 or thereabouts. Please specify the > language, too, since it seems to me they vary in error-prone-ness. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Programs that work right the first time.
Bill, no need to get defensive. I have written z/OS and Linux (multiple platform) internals and also user-facing code. Guess which one is harder? Rhetorical question. Both are really hard to do well. z/OS internals are notoriously under-commented and under-understood (I wanted to make up a word). Users are notoriously bad at doing "normal" things. They often do really unexpected things. Anyone can write complex code. However, writing complex code that WORKS even when the user or application calling you is not also you (or written by you) is really hard. Whether it's a massive behemoth (like z/OS) or a short 40-line REXX program, one should be able to appreciate quality code. Claiming that writing in REXX isn't really programming is just rude and you should go think about what you have done, in my opinion. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com > From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu> > > No bee in my bonnet. Just don’t like braggarts. > What is more complex? The developers who wrote zOS or the > installation? The programs I wrote over my programming days were > much more complex than anything I’ve written in my SP days. And I’ve > written REXX & CLIST. Not all that hard. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Hash with a certain seed (Key)
The CKDS holds both clear or secure keys (same with both the PKDS and TKDS). Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com Allan Staller wrote on 08/13/2021 04:24:53 PM: > AFAIK, you do not want to use the CKDS. IIRC, the CKDS is "Clear Key" . > You most likely would use the PKDS or TKDS; > > Check the fine manuals. I may be all wet here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Hash with a certain seed (Key)
I've got questions. :) > Our scenario: > We are running z/OS 2.2, Crypto Express 5 and FMID=HCR77B0 This is a little out of service but I think we can make this work. > We want to calculate a hash using sha-256 with a certain secret key (or > seed) that is provided by someone external (and given to us). We are not > sure how to store that key in the CKDS Dataset. The length of the key is 32 > bits and has the form of n(1)n(2)n(32) where each n(i) is an > hexadecimal character (I don't know why...) I assume you mean 32 nibbles long (128 bits) because ICSF won't allow an HMAC key of less than 80 bits. Since you are on HCR77B0, you would convert it to binary and then use CSNBSKI2 to import clear key material as a secure key token. Doing this will require enabling SSM (special secure mode) in ICSF options dataset. Then, you can use CSNBKRC2 to put the token into the CKDS. > We already created and stored an AES master key in the cryptographic > hardware and we also changed the format of our CKDS in order to use HMAC. Perfect. > We tried different ways of putting this key in the CKDS using different > verbs, like using a REXX example from the web (HMAC Generation from a Clear > Key ) Do you have a link to that example? CSNBHMG doesn't allow clear key tokens until "Cryptographic Support for z/OS V2R2 - z/OS V2R4 (HCR77D1)" (five releases after the release you have). > In our mainframe we want to use the callable service (verb) CSNBHMG in a > Cobol program to calculate the hash using the key stored in the CKDS. This > output should be the same as the output using > (with the same key). To be clear, that page is treating the data as ASCII, so you will need to account for that in your COBOL (ensure that the data is kept as binary until it is HMACed. > Our biggest issue is how to put this secret key (or seed) in the CKDS > dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
I believe you are correct. It's one of those things that is a bad idea even if it does seem to work. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 08/12/2021 12:13:39 PM: > From: "Barry Lichtenstein" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/12/2021 12:13 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" > > Eric, > > To the best of my knowledge SYS1.SIEALNKE members are not intended > to be linked directly into programs. > SYS1.CSSLIB (or other component-specific libraries like LE's > CEE.SCEELKED) should have the stubs for their functions. > SYS1.SIEALNKE is one of the datasets which are by default part of > the LNKLST concatenation, specifically: SYS1.LINKLIB, SYS1.MIGLIB, > SYS1.CSSLIB, SYS1.SIEALNKE, and SYS1.SIEAMIGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
To be clear: I'm the author of CSFDLL31 (as well as much of the ICSF LE
libraries). I guarantee CSFDLL31 is just stubs (they are pretty much the
LE linkage equivalent to the OS linkage stubs in SCSFSTUB). The only
patches (so far) have been to add new callable service entry points.
I do agree with you that it is not always useful to bind CSFDLL31 in (it
would save the overhead of shared object loading but at the cost of a lot
of code).
While the linkage for stubs in SCSFSTUB is mostly the same for CSFDLL31,
for CSFDLL3X and CSFDLL64, you will almost certainly encounter trouble
(both use XPLINK).
Short summary: It is not a supported configuration to call a stub in
SCSFSTUB with LE linkage or call an entry points in CSFDLL* with OS
linkage. While it might work, it's not the right way and IBM does not
support it.
Eric Rossman, CISSP®
ICSF Cryptographic Security Development
z/OS Enabling Technologies
edros...@us.ibm.com
"IBM Mainframe Discussion List" wrote on
08/11/2021 04:02:03 PM:
> From: "Frank Swarbrick"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/11/2021 04:02 PM
> Subject: [EXTERNAL] Re: DLL linkage vs static linkage
> Sent by: "IBM Mainframe Discussion List"
>
> It appears you CAN explicitly link in the actual DLL ("INCLUDE
> SIEALNKE(CSFDLL31)"), but I believe that to be unwise for several
reasons
> 1) It acts as if you are simply trying to add your application to
> the DLL (with your new name), rather than simply utilizing the DLL.
> That is, your bind step creates a side deck that has all of the ICSF
> DLL's entry points mapped to your executable.
> 2) The DLL appears to not be "just stubs" but rather has the actual
> implementation of each routine. This causes your executable to be
> (IMO) excessively large. And I imagine that any patches to the
> actual DLL would not be picked up by your application until you
> rebind to the upgraded DLL.
>
> I don't think that OS linkage vs LE linkage makes any (useful)
> difference. LE languages can use OS linkage just fine, since from a
> caller perspective they are the same (as far as I can tell). I
> believe a subroutine only needs LE linkage if it itself requires LE
services.
>
> Frank
>
> On Wed, 11 Aug 2021 15:37:42 -0400, Eric D Rossman
> wrote:
>
> >I would like to point out that the stubs in SCSFSTUB use OS linkage and
> >the entry points in CSFDLL31 use LE linkage. You should use whichever
> >matches the linkage declared (or defaulted) for the ICSF callable
> >services.
> >
> >It is never correct to specify both SCSFSTUB and an ICSF side-deck in
the
> >same link operation. It might work but it might not.
> >
> >As to what I meant by static, I suspect that I might be using the wrong
> >terminology for this and perhaps I am misremembering how it works. I
> >thought you could directly linkedit a shared object [like
> >SIEALNKE(CSFDLL31)] into a load module and it would be treated as if it
> >were an archive (.a) instead of shared object/DLL (.so).
> >
> >Eric Rossman, CISSP�
> >ICSF Cryptographic Security Development
> >z/OS Enabling Technologies
> >edros...@us.ibm.com
> >Tieline: 295-6882 or (845) 435-6882
> >
> >"IBM Mainframe Discussion List" wrote on
> >08/11/2021 01:42:29 PM:
> >
> >> From: "Frank Swarbrick"
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Date: 08/11/2021 01:42 PM
> >> Subject: [EXTERNAL] Re: DLL linkage vs static linkage
> >> Sent by: "IBM Mainframe Discussion List"
> >>
> >> I've now been successful in implementing your suggestion. Some
> >> comments follow.
> >>
> >> The following is successful for a static link. Cobol compiler
> >> options "NODYNAM NODLL" and the inclusion of SYS1.SCSFSTUB in the
> >> binder SYSLIB.
> >>
> >> //CSFLINK JOB NOTIFY=
> >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC)
> >> //COMPILE EXEC PROC=IGYWCL,
> >> // PARM.COBOL='NODYNAM NODLL',
> >> // PARM.LKED='LIST=NOIMP MAP XREF LET=0'
> >> //COBOL.SYSIN DD *
> >>id division.
> >>program-id. rngl.
> >>procedure division.
> >>call 'csnbrngl'
> >>goback.
> >>
> >>end program rngl.
> >> //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB
> >>
> >> Results:
> >> A8 CSFRNGL * CSECT 1D0 SYSLIB01
> >CSNBRNGL
> >> 0 A8 CSNBRNGL LABEL
> >>
> >>
> >> Next
Re: DLL linkage vs static linkage
I would like to point out that the stubs in SCSFSTUB use OS linkage and the entry points in CSFDLL31 use LE linkage. You should use whichever matches the linkage declared (or defaulted) for the ICSF callable services. It is never correct to specify both SCSFSTUB and an ICSF side-deck in the same link operation. It might work but it might not. As to what I meant by static, I suspect that I might be using the wrong terminology for this and perhaps I am misremembering how it works. I thought you could directly linkedit a shared object [like SIEALNKE(CSFDLL31)] into a load module and it would be treated as if it were an archive (.a) instead of shared object/DLL (.so). Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com Tieline: 295-6882 or (845) 435-6882 "IBM Mainframe Discussion List" wrote on 08/11/2021 01:42:29 PM: > From: "Frank Swarbrick" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/11/2021 01:42 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" > > I've now been successful in implementing your suggestion. Some > comments follow. > > The following is successful for a static link. Cobol compiler > options "NODYNAM NODLL" and the inclusion of SYS1.SCSFSTUB in the > binder SYSLIB. > > //CSFLINK JOB NOTIFY= > // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > //COMPILE EXEC PROC=IGYWCL, > // PARM.COBOL='NODYNAM NODLL', > // PARM.LKED='LIST=NOIMP MAP XREF LET=0' > //COBOL.SYSIN DD * >id division. >program-id. rngl. >procedure division. >call 'csnbrngl' >goback. > >end program rngl. > //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > > Results: > A8 CSFRNGL * CSECT 1D0 SYSLIB01 CSNBRNGL > 0 A8 CSNBRNGL LABEL > > > Next is a successful "DLL link". Cobol compiler options "NODYNAM > DLL". Added "DYNAM=DLL CASE=MIXED" to the binder parameters. The > CSFDLL31 side file is included "in place" of SCSFSTUB. > > //CSFLINK JOB NOTIFY= > // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > //COMPILE EXEC PROC=IGYWCL, > // PARM.COBOL='NODYNAM DLL', > // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > //COBOL.SYSIN DD * >id division. >program-id. rngl. >procedure division. >call 'csnbrngl' >goback. > >end program rngl. > //LKED.SYSIN DD DISP=SHR,DSN=SYS1.SIEASID(CSFDLL31) > > Results: > > --- SOURCE > IMPORT/EXPORT TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31 > SYSLIN02 CSFDLL31 > > > Now, if we take the previous example (DLL resolution) and add back > SYSLIB with SYS1.SCSFSTUB, the static resolution takes precedence > over DLL resolution, which is what I don't want. > > //CSFLINK JOB NOTIFY= > // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > //COMPILE EXEC PROC=IGYWCL, > // PARM.COBOL='NODYNAM DLL', > // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > //COBOL.SYSIN DD * >id division. >program-id. rngl. >procedure division. >call 'csnbrngl' >goback. > >end program rngl. > //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > //LKED.SYSIN DD DISP=SHR,DSN=SYS1.SIEASID(CSFDLL31) > > Results: > 1A8 CSFRNGL * CSECT 1D0 SYSLIB01 CSNBRNGL > 0 1A8 CSNBRNGL LABEL > > > --- SOURCE > IMPORT/EXPORT TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - > *** NO SYMBOLS IMPORTED *** > > Next let's try Barry's suggestion: > > //CSFLINK JOB NOTIFY= > // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > //COMPILE EXEC PROC=IGYWCL, > // PARM.COBOL='NODYNAM DLL', > // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > //COBOL.SYSIN DD * >id division. >program-id. rngl. >procedure division. >call 'csnbrngl' >goback. > >end program rngl. > //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > //LKED.SYSIN DD * > INCLUDE SIEASID(CSFDLL31) > LIBRARY (CSNBRNGL) > //LKED.SIEASID DD DISP=SHR,DSN=SYS1.SIEASID > > Unlike my attempt to do this with our standard compile proc, this > does seem to work as designed. > It does put out the following warning, which causes an RC of 4 > instead of 0, which is annoying. > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. > > But in the end it succeeds with the DLL import to resolve it. > > *** I M P O R T E D A N D E X P O R T > E D S Y M B O L
Re: DLL linkage vs static linkage
Just to be clear, there is no case to ever include SYS1.SCSFMOD0. That dataset should never be in any since HCR77D0 (z/OS V2R4) because it is not a programming interface. Everything that was in there that was intended as a programming interface is now in SYS1.SCSFSTUB. ASM programs should be using SYS1.SCSFSTUB (static) or LOAD/LINK (dynamic) LE programs (such as C) should be using SYS1.SIEASID (dynamic) or SYS1.SIEALNKE (static). I'd love to help. Do you have a simple test (source and link job) that replicates this error? Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 08/10/2021 05:41:46 PM: > From: "Frank Swarbrick" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/10/2021 05:42 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" > > Hi Barry, > > Interesting. But I can't quite get it to work. What's bizarre is > that the DLL linkage seems to get resolved: > > IMPORT/EXPORT TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31 > SIEASID 01 CSFDLL31 > > But the binder is still giving me an error: > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL > SPECIFIED. > IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND > CANNOT BE REPLACED BY THE NON-EXECUTABLE MODULE JUST > CREATED. > > Very odd! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS SYSVAR looks weird
As of V2R2 (HRF77A0), SYSLRACF is frozen at 7791. https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/anthony-giorgio2/2020/04/02/sharing-some-changes-in-zos-v2r2-before-you-find-it-from-professor-kimura Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com IBM Mainframe Discussion List wrote on 06/21/2021 12:42:30 PM: > From: "Pommier, Rex" > > Hey all, > > Running z/OS 2.4 with RACF 2.4 - FMID HRF77C0. When I do a SYSVAR > of SYSLRACF, I get a result of RACF version is 7791. Is this right > or is the SYSVAR giving me outdated information? It just doesn't > look correct. It's also giving me a SYSTSOE version of 4040 which > looks suspiciously like spaces, but my primary question is about the > RACF version. > > Thanks, > > Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coding for the future
My take on this as a programmer with only 23 years on z/OS, and only 10 years before that: My use of variable names and comments varies with the target audience but not that much. Whether I'm writing a sample that will have folks of nearly every skill level look at OR I'm writing code that I will need to maintain, I tend to have comments that describe the WHAT or WHY but use the instruction itself to describe the HOW. LA R3,encdata Output encrypted data LLGTRR3,R3 64-bit clean STG R3,CRYPV_OUTPUT_ADDRAnd stored into CRYPV It might not be obvious why I cannot just LA/STG (yes, I KNOW I could use LAE but I was young and naive when I wrote this 4 years ago :) ) but the comments will explain the WHAT and WHY. As far as I am concerned, it's more important for the source code to be understandable than the listing. The listing will help in cases where the source might be relying on USINGs that rely on other USINGs and the assembler can straighten things out. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crypto
Seems like a good place to me. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com IBM Mainframe Discussion List wrote on 05/24/2021 02:22:37 PM: > From: "Nai, Dean" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/24/2021 02:22 PM > Subject: [EXTERNAL] Crypto > Sent by: IBM Mainframe Discussion List > > Would this be a good place to ask some Z14 crypto questions I'm > having a problem with? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 emulator / telnet with encryption
I'm probably the odd one out, but I say "SEE-pack-eff" and "kicks" for CPACF and CICS and I'm on the east coast of the US. And, yes, we (ICSF) do exploit the new z15 CPACF functions available with MSAE9 (Compute Digital Signature Authentication (KDSA)) for EC key pair generation, digital signature generate/verify, and key agreement for curves P-256, P-384, P-521, Ed25519, and Ed448. Since System SSL calls us for those curves, they get the performance benefit as well. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com IBM Mainframe Discussion List wrote on 05/07/2021 12:57:01 PM: > From: Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> > > Tom, > > CPACF is considered part of weaponry by the US government and so it > has to be capable of being disabled for those countries where > exportation of encryption is restricted by US Govt arms rules. This > is why it has to be explicitly selected. > > CPACF is actually a pre-requisite for enabling a Crypto Express > device. CPACF is used extensively in TLS. TLS uses clear key > encryption for data transport and this is where the majority of > encryption work is performed in TLS. However, I see the latest CPACF > on Z15s have some new asymmetric functions, so maybe CPACF can be > used in the TLS handshake as well now. > > Lennie Dymoke-Bradshaw > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Brennan > Sent: 07 May 2021 16:55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 3270 emulator / telnet with encryption > > On 5/7/2021 6:19 AM, Phil Smith III wrote: > > > It's a reasonably safe bet that any machine today has CPACF; that was > > not always true, of course. > > When IBM or a business partner configures a new machine, there's a > checkmark for CPACF (zero charge), but it defaults to unchecked. So > when ordering a new machine I'd suggest the customer ask to make > sure that free feature code is supplied. > > If the machine comes with a crypto card, CPACF is automatically > selected and required. No need to ask in that case. > > Side subject - so how do you pronounce CPACF? I always say each > letter, but some IBM crypto folks say C-Pack-F -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Dynamic service update and MIGLIB
Hello, Mike. I'm the author of the APAR/PTF in question as well as some of the wording the canned DYNACT hold text. I can try to explain. DYNACT is intended to provide for non-disruptively reloading modules used by the ICSF address space (CSFINPVT, CSFINPV2) and the ICSF LPA modules should they be impacted by service. MIGLIB is used only for IPCS formatters and models, which are not involved in DYNACT. The same is true for load modules in SCSFSTUB (where the ICSF callable service stubs exist) and ICSF dialog modules (which happen to live in SCSFMOD0 as well). All these load modules would be brought in using the normal service method (at the next IPL or via dynamic LNKLST). I understand the confusion about this and we are working on making the wording clearer. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com Mike Martin wrote: > I'm a little surprised that IBM's HOLD(DYNACT) doesn't speak to MIGLIB. > Hi all, > > We need additional ICSF capability (CVN18) so we are applying a PTF (UJ03312) to our z/OS V2.4 ISCF (HCR77D0). > > There is an SMP/E HOLD(DYNACT) which tells us how to dynamically update the ICSF code from libraries CSFMOD0 and IEALNKE. > > But, we noticed that SYS1.MIGLIB was also updated during the SMP/E apply. We don't apply to a running system, so I'm wondering how we handle the updates to MIGLIB as there is no mention of it in the ISCF doc for dynamic service update. > > Mike Martin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
