Re: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's
W dniu 2015-02-19 o 07:45, Sheldon Davis pisze: Hi I am out of ideas. We converted a set of sequential files to be extended and changed the ACS routine to put the files on model 54's The following is what happened: 1. Jobs that allocated the files took more CPU and ran much longer. 2. The catalog address space used about four times more CPU than usual and did a huge amount of I/O on the disks that the batch job used to allocate and update the files. Thanks for any input Check SMS compression. Check blocksize, leave it to default. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.840.228 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - Is your toaster a silent recruit in a 'thingbot' army?
Mike Schwab wrote: Printing on bread. http://dornob.com/serial-toasters-and-creative-toast-printing-gadgets/ Not bad, Now I want to write these on my toast 'Please don't eat/toast me!' or 'S0C4 Abend', or 'JCL error in Toaster!' or 'I'm burned!' something like that for us bored Sysprogs... ;-D However, that toast must be edible with honey and syrup or egg/bacon on the top anyways. ;-) It must be more or less Friday today... last time I looked... ;-D 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
Seperate Password for OMVS
Hi Group, Apology for asking a dummy question. Is it possible to keep a seperate Password for OMVS alone ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RCF vs. COMMENT (was: IGW01595E message ...)
I forwarded this on to the C compiler team, who retrieved your PMR from the dusty archives and determined it was a Language Environment problem. Apparently it got passed to them and they do see a problem, but then...well...you know what happened in the end, and I think the contributing factors aren't really important here in IBM-MAIN. In any event, the Language Environment guys are a bit horrified that this happened. I see from the agenda you'll be at SHARE. Can you track me, Tom Petrolino, or Nigel Li down in Seattle so we can try to get this back on track? li...@akphs.com (Phil Smith III) wrote: snip Hey, at least you got that muchI opened a SEV2 against a math function in C that was returning incorrout on true 64-bit values (i.e., values where the top bit was non-zero) in October, got no real response for three months, then they decided to FIN it. Seemed kind of blasé for such a nasty bug; definitely not your fathers IBM! phsiii (who is kind of disgusted at this response) -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@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: Seperate Password for OMVS
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Hi Group, Apology for asking a dummy question. Is it possible to keep a seperate Password for OMVS alone ? Not out of the box, but so long as RACF supports password and password phrase as separate entities, you could design your login interactions such that, for example, all of your traditional z/OS applications would use the 8-character or shorter password, and your OMVS applications would use the 14-character[1] or longer password phrase. -jc- [1] With the ICHPWX11 exit you can decrease the minimum length of a password phrase to as few as 9 characters. ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Seperate Password for OMVS
Peter wrote: Apology for asking a dummy question. Is it possible to keep a separate Password for OMVS alone ? Do you mean you want to logon to a OMVS session (say via OMVS, ISHELL, FTP, etc.) with id but without a password? If so, answer is NO. If it is YES, then I'm sure the RACF people at IBM will pick it up pretty soon. PS: I'm not sure whether you can authenticate yourself to OMVS with say, certificates or something else which can identify yourself. What are you trying to solve by that question? Groete / Greetins Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Seperate Password for OMVS
I am not sure I understand your question. Could you provide an example of what you mean? What password, what function, what in OMVS would need a separate password? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Thursday, February 19, 2015 6:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Seperate Password for OMVS Hi Group, Apology for asking a dummy question. Is it possible to keep a seperate Password for OMVS alone ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Seperate Password for OMVS
Paul Gilmartin wrote: PS: I'm not sure whether you can authenticate yourself to OMVS with say, certificates or something else which can identify yourself. ssh credentials work for that. Might need administrative assistance to set them up. Ah yes, thanks, Paul, for refreshing my decaying and rusty memory. I now remember SSH credentials and friends. This sounds like a variant of the question (recently less frequently asked): How do I prevent my users' (whom I must give OMVS segments so they can use FTP) using UNIX services? Hmmm, interesting. How do you do that? By giving in RACF, the user an invalid PROGRAM folder (as per Peter Hunkeler) in the OMVS segment? Or something else which I certainly overlooked? AFAIK - BPX.UNIQUE.USER is supposed to give you OMVS automagically if you don't have OMVS segment, thus you are getting access to UNIX services. You can use the PROGRAM trick to stop this. On the other side - many of my RESTRICTED users can FTP datasets without having access to UNIX services. I can imagine the complementary question: How can I allow users to use OMVS but not TSO. batch, etc. Not too difficult. Give the id OMVS segment and RESTRICTED attribute in RACF without TSO segment, throw away keys to JESINPUT/JESSPOOL, etc. Of course for all of this, you still need id/psw to use UNIX services for out of the box setup as per John Chase suggestion. 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: A possible bug in the IBM Runtimne C library
On Thu, 19 Feb 2015 08:18:05 -0600, Ze'ev Atlas zatl...@yahoo.com wrote: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. You can always use int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t and friends in /usr/include/stdint.h. ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Refreshing CAISSF for CA-7
I apologize my frequency in the forums lately :) I can't seem to find a way to refresh the permissions to the CA-7 PA@EL resources without rolling the CA-7 address space. Am I expecting too much? I was sure I remembered a way to refresh either in CA-7 or at the CAIRIM/CAISSF level. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ALL your SIM card encryption keys are belonging to NSA
https://firstlook.org/theintercept/2015/02/19/great-sim-heist/ -- 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
Re: ALL your SIM card encryption keys are belonging to NSA
Yes, and about the other things you think that are still private to you, you will be notified soon... George Orwell probably thought he had put the worst thinkable into the 1984 society. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: 20 February, 2015 7:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ALL your SIM card encryption keys are belonging to NSA https://firstlook.org/theintercept/2015/02/19/great-sim-heist/ -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Sure I could, but the geniuses who created the regex.h and friends did not deem that necessary, so the poor user has to go to the header file, read all the #if's and #else's and figure it our. Not an easy task when you are a COBOL poor user :( ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Seperate Password for OMVS
How do I prevent my users' (whom I must give OMVS segments so they can use FTP) using UNIX services? By what means? If you do not want them to be able to login into a shell, set the PROGRAM field in the OMVS segment to '/bin/true', or some such. If the users need to be able to use FTP and are also in need of login to TSO, you're out of luck, I guess. I can imagine the complementary question: How can I allow users to use OMVS but not TSO. batch, etc. Don't define a TSO segment for those users. OMVS and TSO are independent segments. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's
You may wish to engage IBM via an SR/PMR. They may be able to identify the issue. However, depending on your level of z/OS there may be fixes or suggestions 1) Did you recently install any fixes to the current z/OS or upgrade to a new z/OS? 2) Are you sharing with other LPARs. 3) By sequential - these are NON VSAM? a) Are they GDGs b) Are they IMS/DB2/ or other subsystem type files? 4) Did anything change in SMS recently other than the redirection of the files? a) Is the Dataclas the same as it was before the ACS changes? b) how did you change the SMS Code to point to MOD54s? Did you create a new pool? Or are these NONSMS volumes 5) Have you reset the performance statistics in the CATALOG address space, run the job, then display the statistics to see what may have changed? 6) Have you reviewed any RMF data from the time the job ran? 7) Do you have performance tools like Tivoli Omegamon or Strobe? If so, run it on the job and see where the time is spent. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sheldon Davis Sent: Wednesday, February 18, 2015 11:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's Hi I am out of ideas. We converted a set of sequential files to be extended and changed the ACS routine to put the files on model 54's The following is what happened: 1. Jobs that allocated the files took more CPU and ran much longer. 2. The catalog address space used about four times more CPU than usual and did a huge amount of I/O on the disks that the batch job used to allocate and update the files. Thanks for any input -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Seperate Password for OMVS
On Thu, 19 Feb 2015 15:39:00 +0100, Peter Hunkeler wrote: How do I prevent my users' (whom I must give OMVS segments so they can use FTP) using UNIX services? By what means? If you do not want them to be able to login into a shell, set the PROGRAM field in the OMVS segment to '/bin/true', or some such. If the users need to be able to use FTP and are also in need of login to TSO, you're out of luck, I guess. /bin/false feels more the proper spirit. Our shop uses something for the default user similar to /bin/OMVS-access-denied, which doesn't exist, but appears in (some) error messages. Regardless, they can circumvent much by Assembler BPX1* calls, by Rexx address SYSCALL 'spawn' or by BPXBATCH PARM='PGM ...'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Seperate Password for OMVS
On Thu, 19 Feb 2015 07:40:52 -0600, Elardus Engelbrecht wrote: Peter wrote: Apology for asking a dummy question. Is it possible to keep a separate Password for OMVS alone ? PS: I'm not sure whether you can authenticate yourself to OMVS with say, certificates or something else which can identify yourself. ssh credentials work for that. Might need administrative assistance to set them up. What are you trying to solve by that question? This sounds like a variant of the question (recently less frequently asked): How do I prevent my users' (whom I must give OMVS segments so they can use FTP) using UNIX services? I can imagine the complementary question: How can I allow users to use OMVS but not TSO. batch, etc. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
I am going back to the drawing board and I will have a hard look at the regex.h again and will do some tests with 64 bits compilations vs. 32 bits. It is extremely hard to deduce from the documentation what to expect and what structure is in effect when one compiles with any combination of pragma's/macros, etc. Than, when I know better, I'll still have the task of apply that knowledge to COBOL compilation combination. I assume now that COBOL and C when compiled under normal LE environment communicate somehow with the library to produce the correct structures in reality. If I am correct, I just have to trace the rules and translate them to appropriate copybooks. I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange C runtime library behavior
Thank you all I am going back to the drawing board as I've mentioned on another thread ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RCF vs. COMMENT (was: IGW01595E message ...)
On Thu, 19 Feb 2015 08:51:35 -0500, John Eells wrote: I forwarded this on to the C compiler team, who retrieved your PMR from the dusty archives and determined it was a Language Environment problem. ... In any event, the Language Environment guys are a bit horrified that this happened. Sounds like my experience when I observed a drastic misbehavior (IMO) of DFSORT and strcoll() for LC_CTYPE=En_US. My PMR went to LE (reasonably, I'll grant), which called it an ASCII vs. EBCDIC effect. I gave up in disgust. li...@akphs.com (Phil Smith III) wrote: snip definitely not your father�s IBM! That depends. Forty years ago, IBM could afford to be more arrogant. They felt they were entitled to define or ignore the standards. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Seperate Password for OMVS
In capikfhgi5onx3zswmuvplmsfmwrggephotwe9ektkporykx...@mail.gmail.com, on 02/19/2015 at 06:48 PM, Peter dbajava...@gmail.com said: Is it possible to keep a seperate Password for OMVS alone ? On the same LPAR? Not without a separate userid. Simiolarly, if you use a password phrase it's the same for every application. The best that you could do would be to have some applications require specific authentication methods that others don't accept, but that doesn't scale. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lenovo and Superfish
On Thu, 19 Feb 2015 17:32:53 -0600, Paul Gilmartin wrote: Here we go again: http://www.wired.com/2015/02/lenovo-superfish/ The gall of these people is unbelievable. Hop on a plane that uses gogo for onboard wifi with one of these, and *really* expose yourself to a man-in-the middle attack. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lenovo and Superfish
Here we go again: http://www.wired.com/2015/02/lenovo-superfish/ And, a classic (Ken Thompson ca. 1984): http://cm.bell-labs.com/who/ken/trust.html -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refreshing CAISSF for CA-7
Any help here? TEC428347 http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec428347.aspx Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Thursday, February 19, 2015 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Refreshing CAISSF for CA-7 I apologize my frequency in the forums lately :) I can't seem to find a way to refresh the permissions to the CA-7 PA@EL resources without rolling the CA-7 address space. Am I expecting too much? I was sure I remembered a way to refresh either in CA-7 or at the CAIRIM/CAISSF level. Dave Gibney Information Technology Services Washington State University -- 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 possible bug in the IBM Runtimne C library
In 1346088131080403.wa.zatlas1yahoo@listserv.ua.edu, on 02/19/2015 at 08:18 AM, Ze'ev Atlas 004b34e7c98a-dmarc-requ...@listserv.ua.edu said: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. It was appalling; a reversion to FORTRAN-speak after PL/I showed how it should[1] be done. But C is still the best PDP-7 specific language ever designed. [1] In general; I won't argue the Ada approach versus the PL/I approach, as both let the compiler figure out what storage unit is needed to hold the declared variable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refreshing CAISSF for CA-7
This is helpful. Not as immediately helpful as I had hoped, but helpful. I may be in business anyway. Truns out that I probably have the definitions I need already in my Production Lpar. This time it was development that was out of sync and it wasn't a big deal to roll CA-7 there. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neubert, Kevin Sent: Thursday, February 19, 2015 4:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Refreshing CAISSF for CA-7 Any help here? TEC428347 https://urldefense.proofpoint.com/v1/url?u=http://www.ca.com/us/support/c a-support-online/product-content/knowledgebase- articles/tec428347.aspxk=EWEYHnIvm0nsSxnW5y9VIw%3D%3D%0Ar=j6Xa 1Y0fbuP2mfgCQ5Zxhg%3D%3D%0Am=Euuc1HqggzGWKqnYyhlFx%2BSRlk4xS Omfr7iD92P0%2FLo%3D%0As=577acfd9a2a638eac07176a2ab36eddcf3624a 63c6ea7e597b23f1b48ad8133b Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Thursday, February 19, 2015 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Refreshing CAISSF for CA-7 I apologize my frequency in the forums lately :) I can't seem to find a way to refresh the permissions to the CA-7 PA@EL resources without rolling the CA-7 address space. Am I expecting too much? I was sure I remembered a way to refresh either in CA-7 or at the CAIRIM/CAISSF level. Dave Gibney Information Technology Services Washington State University -- 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
