Re: IBM KC "The request cannot be fulfilled by the server"
Sorry, all. Whatever the problem was, it's apparently resolved now. -Sue Shumway On 8/6/2019 12:51 PM, Carmen Vitullo wrote: I don't think you are doing anything wrong unless the link was changed/moved/updated/or deleted I get the same message, :( Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 6, 2019 11:44:56 AM Subject: IBM KC "The request cannot be fulfilled by the server" I attempt to go to https://www.ibm.com/support/knowledgecenter/ and get the indicated message. Am I doing something wrong? 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 -- Sue Shumway z/OS Product Documentation Lead IBM Poughkeepsie chale...@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: FAST PATH (IEWBFDAT) SQ CALL Fail 10800029
On 2019-08-07 5:37 AM, Joseph Reichman wrote: The program is not a program object, anomalies were found in its structure, or the program is PO1 (program object, version 1) and the program contains overlay structures. The request was rejected So, would you swear on a stack of PLMs that MYMOD is neither a load module from a PDS nor a segment overlay program object? If so, then it is time to post the entire parameter list passed to IEWBFDAT. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
On 2019-08-07 5:08 AM, Carmen Vitullo wrote: I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Well, DYNALLOC is certainly doing more that the job step initiation when it comes to allocation. Device allocation at step-start time is a largely CPU-bound affair with the only I/O usually being for catalog look-ups. That is why something like //MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1 will get a S213-04 at OPEN time when FRED does not exist. DYNALLOC will check that FRED exists on the volume - yes! it does "lots" of I/O to the data set's volume which batch device allocation does not perform. Data set name enqueue is done before device allocation, and most of it is done at job start time for data sets mentioned in JCL. DYNALLOC has to do the ENQ when it is called before looking at devices. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Destination z - Of Elephants and Mainframes
Good news: the article has been updated based on input from Gabe and IBM-MAIN. See http://destinationz.org/Mainframe-Solution/Trends/elephants-and-mainframes for the revised version. Thanks, all! Reg Harbeck +1.403.605.7986 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Reg Harbeck Sent: August 1, 2019 14:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Destination z - Of Elephants and Mainframes Thank you, Gabe. I'm honoured that you read my writing so closely, and I take your correction seriously. I'll be more careful how I phrase such things in future articles. FWIW, I am aware that Fortran and other pre-COBOL languages already existed, so perhaps I should have said "much of this stuff" instead. (And to those who have made other suggestions on IBM-MAIN that I should have caught, but missed, in the past, my apologies: still getting into good habits of keeping up with this important part of the mainframe ecosystem.) Reg Harbeck +1.403.605.7986 P.S. Looking forward to seeing many of you in Pittsburgh next week. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gabe Goldberg Sent: August 1, 2019 13:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Destination z - Of Elephants and Mainframes Think back… think way back, possibly to before you were born. Think of the reasons why SHARE was founded in 1955, and the main activities of SHARE. Once upon a time, when electronic computing technology was still being figured out, each new machine was so different from its predecessors that it was necessary to rewrite a whole new set of utilities and drivers and applications for it. Even Assembly language wasn’t available until 1957 (and the first COBOL compiler didn’t come out until 1960) so most of this stuff had to be manually entered in machine language. http://destinationz.org/Mainframe-Solution/Trends/elephants-and-mainframes Um, no. ACM SIGPLAN History of Programming Languages Conference 1978 article on FORTRAN says: Page 166 1.3 Programming Systems in 1954 Most "automatic programming" systems were either assembly programs, or subroutine-fixing programs, or, most popularly, interpretive systems to provide floating point and indexing operations. --- That's far beyond machine language three years before article claims anything more advanced than that was used. -- 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
has anyone debugged a C DLL using Debug Tool Please share thanks
-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Google Chrome to open IBM z/OS 2.4 Library Index ???
Chrome is not open source. From the behavior, I don't believe MIME is involved. Remove the file type extension (e.g. jpg or pdf) and specify the file in the chrome address bar. I think chrome looks for eye catchers in file data to determine how to open the file. This does not rule out some of the concepts involved with mime (e.g. use PHP or some other SSI to include a header with the file content information). I don't know if Chrome ignores or honors this information. Jon. On Tuesday, August 6, 2019, 11:03:02 AM PDT, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 6 Aug 2019 04:55:50 +, Jon Perryman wrote: > ... >For security reasons, Chrome does not support Windows file extensions. This is >a huge security exposure with other browsers (e.g. MS Word autorun script). >There are very few extensions that chrome supports (e.g. PDF) and they use >very specific low risk programs (not acrobat) to reduce the risk. It's very >unlikely they will support file extensions. ... > Does it support and even require (a subset of) MIME (RFC 1521) Content-types? What does it do if a (standard) Content-type differs from the (customary) file extension? What about the somewhat deprecated Flash? -- gil -- 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: COBOL for z/OS V6R2M0
What I have determined is that when I use IGYWDOPT, or at least a version that I had, my overrides are not present. If I use the non-SMPE install, I get the requested overrides. I'm in the process of trying to understand why my usermod is causing the problem. I'll probably RESTORE the usermod, and rebuild my usermod using the skeleton JCL in IGY620.SIGYSAMP. If this does not produce the correct results, I'll post to the forum again. At least, I can get the options I want by running a non-smpe ASM/Link. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Ross Sent: Tuesday, August 6, 2019 4:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL for z/OS V6R2M0 [External Email] >I have updated the COBOL options using IGY620.SIGYSAMP(IGYWDOPT), SMP/E >usermod to update the COBOL options. IGY620.SIGYCOMP is in the system >link list, and the usermod updates IGYCDOPT in that load library. >After updatin g the module I refresh LLA with F LLA,REFRESH. > >I have used ISRDDN to search both the system link list and LPA for >module IGYCDOPT. It only appears in the link listed load library >IGY620.SIGYLOAD. > >I have changed ARCH=3D7 to ARCH=3D12, OPT=3D0 to OPT=3D2, and NOBLOCK0 >to BLOCK0. The changes I have made do not show up when I run a COBOL >compile after applying the usermod, and refreshing LLA. I have tried >RESTORING the usermod, refreshing LLA, and APPLY'ing the usermod again. >Still the same results. Very strange! Have you confirmed that your updated IGYCDOPT is actually in SIGYCOMP? Checked the 'compile date' etc? Have you confirmed that you got RC=0 from the assemble of igycdopt? One thing to try and make some sense of would be to put your new IGYCDTOP in a different dataset and STEPLIB that ahead of your SIGYCOMP dataset and see if you still get the old options. Soemthing is definitely not right here...maybe some restrictions with z/PDT? Cheers, TomR, AKA Captain COBOL >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN EXCITING NEWS! Beginning this fall, First Tennessee will become First Horizon. Learn more: thenewfirsthorizon.com Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL for z/OS V6R2M0
>I have updated the COBOL options using IGY620.SIGYSAMP(IGYWDOPT), SMP/E >usermod to update the COBOL options. IGY620.SIGYCOMP is in the system link >list, and the usermod updates IGYCDOPT in that load library. After updatin >g the >module I refresh LLA with F LLA,REFRESH. > >I have used ISRDDN to search both the system link list and LPA for module >IGYCDOPT. It only appears in the link listed load library IGY620.SIGYLOAD. > >I have changed ARCH=3D7 to ARCH=3D12, OPT=3D0 to OPT=3D2, and NOBLOCK0 >to BLOCK0. The changes I have made do not show up when I run a COBOL >compile after applying the usermod, and refreshing LLA. I have tried >RESTORING the usermod, refreshing LLA, and APPLY'ing the usermod >again. Still the same results. Very strange! Have you confirmed that your updated IGYCDOPT is actually in SIGYCOMP? Checked the 'compile date' etc? Have you confirmed that you got RC=0 from the assemble of igycdopt? One thing to try and make some sense of would be to put your new IGYCDTOP in a different dataset and STEPLIB that ahead of your SIGYCOMP dataset and see if you still get the old options. Soemthing is definitely not right here...maybe some restrictions with z/PDT? Cheers, TomR, AKA Captain COBOL >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
For the SVC 99, the time as reported by the C library function clock(), documented as Approximates the processor time used by the program, since the beginning of an implementation-defined time period that is related to the program invocation. In other words, it is the CPU time used so far by the program. I suspect it calls TIMEUSED under the covers. For IEF032I IEF032I STEP/BR14/STOP 2019218.1435 CPU: 0 HR 00 MIN 00.00 SECSRB: 0 HR 00 MIN 00.00 SEC VIRT: 4K SYS: 252K EXT:0K SYS:10576K ATB- REAL:20K SLOTS: 0K VIRT- ALLOC: 10M SHRD: 0M Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, August 6, 2019 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Charles Mills wrote: >I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. >The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU >seconds. What type of CPU time? SMF30CPT - TCB? SMF30CPS - SRB? SMF30ISB – SRB CPU time for initiator work? SMF30RCT – Region control task CPU time? SMF30ICU_STEP_INIT – Initiator TCB time? ... etc ... Please clarify your observation. Groete / Greetings Elardus Engelbrecht -- 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: CPU time cost of dynamic allocation
Charles Mills wrote: >I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. >The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU >seconds. What type of CPU time? SMF30CPT - TCB? SMF30CPS - SRB? SMF30ISB – SRB CPU time for initiator work? SMF30RCT – Region control task CPU time? SMF30ICU_STEP_INIT – Initiator TCB time? ... etc ... Please clarify your observation. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
SMF type 30 has a lot more granularity than the message. If you submit an RFE, I advise that you not ask to have all of those data in the message. OTOH, a ew more fileds wouldn't hurt. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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: CPU time cost of dynamic allocation
Got it. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Yes, allocations in your JCL are done in the Initiator. The IEF032I message n your job has CPU time for your jobstep. There may also be an IEF032I for the Initiator, but the CPU time would be for all of the jobs that the Initiator had handled before shutting down. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM KC "The request cannot be fulfilled by the server"
A profound question. My vastly oversimplified answer: The Watsons are dead, Bezos is not. sas On Tue, Aug 6, 2019 at 3:03 PM Charles Mills wrote: > Sigh. > > Amazon keeps their Web site up 99.9% of the time; why can't IBM? > > Charles > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 also) step. No difference in the step CPU time -- still 0.00 seconds. Of course, one could play guessing games all day. Is the Initiator smart enough to know the whole job is one big no-op? I would guess not, but who knows. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FAST PATH (IEWBFDAT) SQ CALL Fail 10800029
Hi I am trying to get the link map of a module First I load it into core LOAD EP=MYMOD The I do CSVQUERY INEPNAME=MYMOD, OUTEPTKN=MODTOKEN I get a zero return code and what looks to be a valid token However trying to start a session I fail LOAD EP=IEWBFDAT STR0,FASTPATH L R15,FASTHPATH CALL (15),(SQ,MTOKEN,MODTOKEN),VL R15 = X'000C' R0=X'10800029' SQ DC C'SQ',X'0001' MODTOKEN DS CL8 MOTOKEN DS F The program is not a program object, anomalies were found in its structure, or the program is PO1 (program object, version 1) and the program contains overlay structures. The request was rejected -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
Paul Gilmartin wrote, re FPE being ASCII-EBCDIC transparent: >I'm astonished that's possible (but it can't be proven impossible). Suppose I >change >x'C1' to x'41' in the clear text (in fact, only a single bit change). With >strong encryption >that must change numerous bits in the encrypted text (ideally about half). >But IIRC >you've said elsewhere that performing an EBCDIC=>ASCII translation, >byte-by-byte, >on the encrypted text does the same for the decrypted text. >(Can you cite an example? Format-preserving data protection uses specific alphabets. So if "Paul" protects to "Abcd" in ASCII, "Paul" in EBCDIC protects to "Abcd" in EBCDIC. Thus you can translate "Abcd" from one encoding to the other and decrypt. So obviously this means that a given FPE operation has to have an alphabet associated with it, and convert internally to a common format. For 7-bit US-ASCII and code page 1047, this is trivial. For other code pages, it's doable but requires a bit more work. The excitement comes if you have a complex alphabet defined in UTF-8 land: say, a mixture of Cyrillic and Greek characters. In UTF-8, that works fine. But those are different EBCDIC code pages, sharing the same 256-byte space, so you *cannot* use such a format in EBCDIC-land. If you have an alphabet comprising *just* Cyrillic or *just* Greek, you can happily use that: convert EBCDIC input (which you of course must tell the system is the right Cyrillic or Greek code page) to UTF-8, encrypt or decrypt, convert back. Since a user cannot really have mixed Cyrillic and Greek data in a single EBCDIC field (at least, not without something VERY strange, with additional metadata), this works fine. >(How about, e.g. IBM-1154<=>UTF-8?) That's a Cyrillic page, yes? If ICONV/ICU handles the conversion, it's trivial. If not, then it's harder. But since any EBCDIC code page surely maps to UTF-8, I think it should work; it's only the other way that causes problems (10lb in 5lb sack dept). I haven't mentioned DBCS, because I think it's pretty well dead. But I think ICONV and/or ICU on z/OS handle it; if so, it should also Just Work. Obviously I haven't tried it. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Yes, allocations in your JCL are done in the Initiator. The IEF032I message n your job has CPU time for your jobstep. There may also be an IEF032I for the Initiator, but the CPU time would be for all of the jobs that the Initiator had handled before shutting down. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 3:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Are you saying -- I am trying to clarify; I don't doubt you -- that the JCL allocations are done by the Initiator, and that time is not included in IEF032I? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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: CPU time cost of dynamic allocation
I would have to dig before I can provide a detailed answer. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO
Re: CPU time cost of dynamic allocation
Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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 KC "The request cannot be fulfilled by the server"
Amazon has to support a lot more hackers. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 12:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBM KC "The request cannot be fulfilled by the server" Sigh. Amazon keeps their Web site up 99.9% of the time; why can't IBM? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM KC "The request cannot be fulfilled by the server" Repeating my refrain! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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
Re: CPU time cost of dynamic allocation
all of those timings, from the jeslog or syslog you see are from the SMF type 30 subtype 4 the IEF032I is prolly, without checking from the IEFACTRT SMF exit, which uses the same SMF record and sub type. I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 6, 2019 2:02:25 PM Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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 KC "The request cannot be fulfilled by the server"
Sigh. Amazon keeps their Web site up 99.9% of the time; why can't IBM? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM KC "The request cannot be fulfilled by the server" Repeating my refrain! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Are you saying -- I am trying to clarify; I don't doubt you -- that the JCL allocations are done by the Initiator, and that time is not included in IEF032I? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Google Chrome to open IBM z/OS 2.4 Library Index ???
On Tue, 6 Aug 2019 04:55:50 +, Jon Perryman wrote: > ... >For security reasons, Chrome does not support Windows file extensions. This is >a huge security exposure with other browsers (e.g. MS Word autorun script). >There are very few extensions that chrome supports (e.g. PDF) and they use >very specific low risk programs (not acrobat) to reduce the risk. It's very >unlikely they will support file extensions. ... > Does it support and even require (a subset of) MIME (RFC 1521) Content-types? What does it do if a (standard) Content-type differs from the (customary) file extension? What about the somewhat deprecated Flash? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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
Re: IBM KC "The request cannot be fulfilled by the server"
I don't think you are doing anything wrong unless the link was changed/moved/updated/or deleted I get the same message, :( Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 6, 2019 11:44:56 AM Subject: IBM KC "The request cannot be fulfilled by the server" I attempt to go to https://www.ibm.com/support/knowledgecenter/ and get the indicated message. Am I doing something wrong? 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: CPU time cost of dynamic allocation
Except when it is: //DD1 DD DSN=,...,DISP=(,PASS) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 6, 2019 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- 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 KC "The request cannot be fulfilled by the server"
Repeating my refrain! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM KC "The request cannot be fulfilled by the server" I attempt to go to https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C2bbeb4ca2f4b42ac699b08d71a8d78ab%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637007067251005215sdata=T7K2n21rMM73lnmBjL4rjsELQ8UBHuN6uLyQlbPuyS4%3Dreserved=0 and get the indicated message. Am I doing something wrong? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::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
Re: CPU time cost of dynamic allocation
On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM KC "The request cannot be fulfilled by the server"
I attempt to go to https://www.ibm.com/support/knowledgecenter/ and get the indicated message. Am I doing something wrong? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? 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
CPU time cost of dynamic allocation
I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
On Tue, 6 Aug 2019 00:42:48 -0400, Phil Smith III wrote: > >...; but more significantly, consider normal data flows: data moves between >ASCII and EBCDIC worlds, gets translated in the process. With whole-file, >non-format-preserving encryption, that means you have to decrypt, translate, >re-encrypt; with format-preserving, you don't have to add anything to that >flow. That's a big win when adding encryption to existing systems. For a new >system, of course, you'd design it differently. > I'm astonished that's possible (but it can't be proven impossible). Suppose I change x'C1' to x'41' in the clear text (in fact, only a single bit change). With strong encryption that must change numerous bits in the encrypted text (ideally about half). But IIRC you've said elsewhere that performing an EBCDIC=>ASCII translation, byte-by-byte, on the encrypted text does the same for the decrypted text. (Can you cite an example?) (How about, e.g. IBM-1154<=>UTF-8?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
Joel C. Ewing pointed out that FPEd data won't compress quite as well as un-FPEd since repeated characters will not be repeated in the ciphertext. This is no doubt true, although some number of random repeats will occur in the ciphertext as well. He wrote: >Unless by format-preserving data protection you mean an encryption >technique that preserves repeated characters (like blanks) and repeated >combinations of characters, then NO, it will not compress well after >encryption. You're thinking whole-data set again, though; format-preserving data protection is not used on whole data sets, it's used on fields in structured data. So while yes, it will compress slightly less well, repeated occurrences of the same field will certainly match, and blanks are not usually part of the protected character set. (I'm talking about NIST-approved modes like FF1, BTW.) So in your described case, compression will take a big hit; in an actual use case, not as much, although there will likely be some loss of compressibility. Format-preserving data protection really involves a different way of thinking about data and data protection. I hate having to say that, as it sounds like marketing BS, but after more than eleven years of working with it, I have come to accept it. .phsiii P.S. This is a great discussion! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
On 8/6/19 8:38 AM, Phil Smith III wrote: > Ron Hawkins wrote: > >> One area where PE encryption, as implemented on z is where it is used >> together with compression. > > >> The horse must go in front of the cart, meaning compression must happen >> before encryption, because it will be ineffective if you do it after. > > > Not true with format-preserving data protection. Since the protected data has > the same format as the original, it should compress just as well. With other > forms of encryption, sure. > > > > And yes, this is a well-integrated feature of PE encryption! > Unless by format-preserving data protection you mean an encryption technique that preserves repeated characters (like blanks) and repeated combinations of characters, then NO, it will not compress well after encryption. An encryption technique that preserves repeated patterns is basically a substitution cipher, which is highly insecure. The meaning of format-preserving is that it preserves the length and the text/numeric attributes of a field, not that it preserves patterns of repetition within or among fields. Compression techniques work by recognizing repeated sequences within a file and substituting a shorter value for a frequently occurring longer sequences. A good encryption algorithm of necessity must obfuscate repeated sequences. Compression adds control fields, so if applied to a file that has no or very few repeated sequences can even result in a larger data file rather than a smaller one (try zipping a zipped file). So, the compression step must be an integral front-end to the encryption process, or it must be separately performed prior to encryption. Joel C Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
Andrew, Yes, from that same z/OS LPAR (or another in the same Sysplex), access to the keys via a RACF resource is also needed. In order to access those keys one would need to use ICSF and the Crypto Express devices that hold the master keys for that domain/LPAR. So if another operating system (such as Linux) can work the interfaces to the Crypto Express and access the VSAM CKDS then they could gain access to the same services that ICSF uses. It would need to be IPLed into the exact same configuration as the z/OS system. It would need some work, but I guess it is possible in theory. Access to the ICSF CKDS would not be enough, as the keys held there are encrypted (wrapped) using the master key. The master key is held in the Crypto Express domain corresponding to the LPAR in question. There is no interface to extract the master key from the Crypto Express device. The Crypto Express device is a FIPS 140-2 level 4 device so it will resist all sorts of attempts to get at the master keys. It will destroy those keys before you can get them out. So the only thing that can be done is to use the interfaces the Crypto Express supplies to perform decryption of the data. The simplest way to achieve all this is to have another z/OS system which can be IPLed into that LPAR which has a rather more open set of RACF controls. So I think physical access to the z processor would be required. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: 06 August 2019 12:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Pervasive Encryption - why? On 5/08/2019 3:08 pm, Timothy Sipples wrote: > Lennie Dymoke-Bradshaw wrote: >> My first reason for PE for data sets is that encryption protects the >> data when it is accessed outside of its normal environment (i.e. not >> via the data's normal RACF environment). > Some other examples, in no particular order: anything IPL'ed on the > system (or that could be) that isn't z/OS with its security manager > fully operating (e.g. ZZSA, standalone dump, Linux raw track access > mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the > stuff Innovation Data Processing can do for backups, or a > misconfigured program properties table (NOPASS). RACF is excellent, > but you cannot assume it'll always be fully on guard. Isn't RACF also required to protect the keys? What stops something else IPLed on the system from accessing the keys using the same interfaces z/OS uses? Andrew Rowley -- 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: Pervasive Encryption - why?
Timothy Sipples >Phil, I don't think your assertion is true, but, regardless, what's the >problem with granting another vendor the courtesy of referring to its >products and offerings by the names they give them? If you're referring to >z/OS Data Set Encryption, then use the name z/OS Data Set Encryption. >Otherwise you're just trying to cause confusion, not reduce it. Not my intention. I feel that IBM inadvertently caused the confusion by calling the data set encryption "PE" at first: the fact that this thread refers to it as such actually supports that, no? My intention was to reduce confusion, not cause it. Hmm,, some Googling actually finds remarkably few hits for either: "z/os" "data set encryption" or "z/os" "pervasive encryption" - fewer than 100 for either! That seems.weird and unexplainable; I'd've guessed that SHARE pages alone would have produced more than that?! >As it happens, IBM includes application-level encryption as part of its >Pervasive Encryption strategy. See, for example, Section 1.4.2 in this >redbook (the "pyramid"): >http://www.redbooks.ibm.com/redbooks/pdfs/sg248410.pdf >Obviously IBM is not opposed to application-level encryption! It's right >there, at the top of the pyramid. Shouldn't you be happy with that? I have seen that. I'm happy that IBM says that; I'd be happier if z/OS Data Set Encryption wasn't being touted as providing much more protection than it actually does. Doing so is not helping customers or IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
Ron Hawkins wrote: >One area where PE encryption, as implemented on z is where it is used >together with compression. >The horse must go in front of the cart, meaning compression must happen >before encryption, because it will be ineffective if you do it after. Not true with format-preserving data protection. Since the protected data has the same format as the original, it should compress just as well. With other forms of encryption, sure. And yes, this is a well-integrated feature of PE encryption! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Db2 maintenance and zOSMF Workflows
I am applying Db2 maintenance and have never used zOSMF workflows. In order to setup and use workflows, do I need to run the Db2 install/migration clist to generate the workflows? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ABEND reason code from attached subtask
Has all IBM code that issues an ABEND documented to give a reason code been updated to use the REASON keyword rather than just loading R15 before the ABEND? I'd assume "no" (the "subtle difference" is not one that causes enough grief to warrant the cost). A different approach to that question is whether the documentation properly differentiates between "reason" on the abend and "value in R15" on the abend. I suspect that some does and some does not. By the way, for CALLRTM TYPE=ABTERM, the reason is not in R15. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
On 5/08/2019 3:08 pm, Timothy Sipples wrote: Lennie Dymoke-Bradshaw wrote: My first reason for PE for data sets is that encryption protects the data when it is accessed outside of its normal environment (i.e. not via the data's normal RACF environment). Some other examples, in no particular order: anything IPL'ed on the system (or that could be) that isn't z/OS with its security manager fully operating (e.g. ZZSA, standalone dump, Linux raw track access mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the stuff Innovation Data Processing can do for backups, or a misconfigured program properties table (NOPASS). RACF is excellent, but you cannot assume it'll always be fully on guard. Isn't RACF also required to protect the keys? What stops something else IPLed on the system from accessing the keys using the same interfaces z/OS uses? Andrew Rowley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
