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: COBOL v5.1 - PTF UI24300
Seems that UI24300 did not ship an updated SRC member (just the MOD member) for IGYCDOPT, so the resolution was to specify both PTFs in the PRE of the USERMOD. -jc- -Original Message- From: IBM Mainframe Discussion List On Behalf Of Chase, John Hi, All, On z/OS 1.13 I tried to re-apply our Installation Options USERMOD (IGYWD51) after APPLYing UI24300 to COBOL v5.1, but the re-apply failed because it did not PRE the previous PTF level (!). Among other fixes, UI24300 adds a new compiler option, so the options module IGYCDOPT gets updated. Normally, when IGYCDOPT gets updated, one must first RESTORE any Installation Options USERMOD, then update and re-APPLY it with the new PRE level. APPLY CHECK of UI24300 reminded me to RESTORE IGYWD51, after which APPLY CHECK and APPLY of UI24300 completed RC = 00. I then updated the USERMOD to increment the REWORK data and specify PRE(UI24300), and the re-APPLY failed because it did not PRE(UI23422), which was the previous level of IGYCDOPT. A quick browse of the CSI via the SMP/E ISPF dialog clearly showed the RMID of IGYCDOPT as UI24300. I've opened a PMR with COBOL support, but now I'm wondering if SMP/E somehow got sick. I ran the whole process twice just to make sure I didn't miss anything. Oh, I also RESTOREd UI24300 after all that. Anybody else ever seen anything like this? TIA, -jc- ** 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: Shipping Culture Is Hurting Us, or what's wrong with I.T. development
Sounds a lot like Agile. :-) But then Steve Jobs made a fortune building things people didn't know they wanted. :-) -jc- -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Too good not to pass to this group. Preach it, Brother! quote ... Quickly getting something in front of the people that will actually use it is a great idea. It means you waste less time building something they don’t actually want. But I look around the industry today and I get worried. Don’t get me wrong – I see brilliant people shipping brilliant, innovative software. But I also see a lot of us using half-baked technologies to shove half-assed software out the door. ... /quote -- Forwarded message -- From: Dave Jones d...@vsoft-software.com Date: Tue, Feb 17, 2015 at 9:20 AM Subject: Shipping Culture Is Hurting Us, or what's wrong with I.T. development To: ib...@listserv.uark.edu A good read, imho: http://bitbashing.io/2015/02/16/shipping-culture.html Have a good one, too. --- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544 -- He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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
COBOL v5.1 - PTF UI24300
Hi, All, On z/OS 1.13 I tried to re-apply our Installation Options USERMOD (IGYWD51) after APPLYing UI24300 to COBOL v5.1, but the re-apply failed because it did not PRE the previous PTF level (!). Among other fixes, UI24300 adds a new compiler option, so the options module IGYCDOPT gets updated. Normally, when IGYCDOPT gets updated, one must first RESTORE any Installation Options USERMOD, then update and re-APPLY it with the new PRE level. APPLY CHECK of UI24300 reminded me to RESTORE IGYWD51, after which APPLY CHECK and APPLY of UI24300 completed RC = 00. I then updated the USERMOD to increment the REWORK data and specify PRE(UI24300), and the re-APPLY failed because it did not PRE(UI23422), which was the previous level of IGYCDOPT. A quick browse of the CSI via the SMP/E ISPF dialog clearly showed the RMID of IGYCDOPT as UI24300. I've opened a PMR with COBOL support, but now I'm wondering if SMP/E somehow got sick. I ran the whole process twice just to make sure I didn't miss anything. Oh, I also RESTOREd UI24300 after all that. Anybody else ever seen anything like this? TIA, -jc- ** 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: How to identify program language from program object
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ken MacKenzie In the old days, as far as I remember though I can't prove it, you used to be able to look at a load library member, check for a certain string (e.g. C2 mm/dd/yy hh:mm:ss) and establish that the module - or even modules had been compiled as COBOL II. Wit the advent of program objects on PDSEs and Enterprise COBOL we don't appear to have that luxury. Does anyone know of any way to identify the language type of modules. We have File-AID at this site and it can identify the CSECTs within a module but it doesn't seem to be able to tell me what COBOL version was used As we prepare to establish Enterprise COBOL 5.1 as the default, I've been asked by developers if it is possible to give them a list of what programs were compiled with which compiler and given that our load libraries are now almost 100% PDSE it's proving tricky. Any thoughts? If you have the object decks, look at the END card. COBOL 5.x is 5655W3200, COBOL 4.x is 5655S7100, COBOL 3.x is 5655G5300, etc. We still have some elderly code here; one I looked at shows 5648A2500. I tried to look it up on IBMLink's Product Cross Reference page, but it seems to be broken: EVERY component ID or FMID I enter returns No matches found, even the COBOL 5.x ones. -jc- ** 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: How to identify program language from program object
CORRECTION: See below. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Chase, John -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ken MacKenzie In the old days, as far as I remember though I can't prove it, you used to be able to look at a load library member, check for a certain string (e.g. C2 mm/dd/yy hh:mm:ss) and establish that the module - or even modules had been compiled as COBOL II. Wit the advent of program objects on PDSEs and Enterprise COBOL we don't appear to have that luxury. Does anyone know of any way to identify the language type of modules. We have File-AID at this site and it can identify the CSECTs within a module but it doesn't seem to be able to tell me what COBOL version was used As we prepare to establish Enterprise COBOL 5.1 as the default, I've been asked by developers if it is possible to give them a list of what programs were compiled with which compiler and given that our load libraries are now almost 100% PDSE it's proving tricky. Any thoughts? If you have the object decks, look at the END card. COBOL 5.x is 5655W3200, COBOL 4.x is 5655S7100, COBOL 3.x is 5655G5300, etc. We still have some elderly code here; one I looked at shows 5648A2500. I tried to look it up on IBMLink's Product Cross Reference page, but it seems to be broken: EVERY component ID or FMID I enter returns No matches found, even the COBOL 5.x ones. -jc- CORRECTION: COBOL 5.x format has changed to show only the program number 5655W32, followed by what looks like vvrrdddhhmmssnnn where vvrr is version release and dddhhmmssnnn is Julian compile date/time and 3 digits which are all 0 in ours. -jc- ** 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: XREF Members of JCL libs and their datasets
You originally wrote complimentary, which in some contexts does mean free (of charge or cost). Perhaps you meant complEmentary instead? -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mitch Sent: Friday, February 13, 2015 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XREF Members of JCL libs and their datasets good one. Love your sense of humor! Mitch -Original Message- From: J R jayare...@hotmail.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, Feb 13, 2015 10:31 am Subject: Re: XREF Members of JCL libs and their datasets RES Suite is comprised of over 20 complimentary and synergistic products So, they're free! === Date: Fri, 13 Feb 2015 08:11:07 -0800 From: charl...@mcn.org Subject: Re: XREF Members of JCL libs and their datasets To: IBM-MAIN@LISTSERV.UA.EDU Someone should tell Tivoli LOL: http://www.tivoliassociates.com/education 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 ** 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: a bit of hope? What was old is new again.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant On Mon, 2 Feb 2015 18:37:12 +, Staller, Allan allan.stal...@kbmg.com wrote: We the willing, Are doing the impossible, I remember it as We the willing, led by the unknowing... Also We the willing, led by the ungrateful, doing the unnecessary for the uncaring, . -jc- ** 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: Strange comment in PTF.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Tue, 27 Jan 2015 15:31:14 -0800, Charles Mills wrote: I should add that in general in the US and most countries copyright notices are unnecessary. I compare them to a Private Property sign on your front lawn: it would still be private property without the sign, but the sign warns your neighbors that you might be serious about it. But beware of adverse possession! http://www.dailycamera.com/ci_13100029 Difficult to imagine a claim of copyright via adverse possession. Under current US copyright law and the Berne Convention, copyright inures to the author of a creative work upon the moment s/he fixes the work in a tangible medium (including, by statute, computer memory). So if you think up a story and recite it for your friends you do not own a copyright, but as soon as you write the story down or key it into your computer you do, notice or no. Are the airwaves a tangible medium? I'm inclined to think not, vis. The storyteller speaking a story does not own copyright until he commits the story to a tangible medium. For this consideration I'd expect the electromagnetic waves of a broadcast to be similar to the sound waves of a speech. (I assume tape and disk are). If a performer broadcasts a performance, never having recorded it, may I record it off the air without violating copyright? Who would know? Now, if you later attempt to enrich yourself by selling copies of such a recording, you might encounter resistance. -jc- [ snip ] ** 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: OT: Friday joke :-)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Fri, Jan 23, 2015 at 8:53 AM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Siegel The question of the day is, were the balls fully inflated our not? Precisely define fully inflated. Dig me up when everybody's satisfied with your definition. :-) -jc- I am not a football person, but listening on the radio this morning, NFL rules state what the psi of the air in the ball is supposed to be. The psi in the ball under discussion was less that what is allowed by the NFL rules, and thus the ball was not fully inflated. Or, better stated: the ball did not meet NFL inflation standards. If there is evidence, then let's go to trial. -jc- ** 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: OT: Friday joke :-)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Siegel The question of the day is, were the balls fully inflated our not? Precisely define fully inflated. Dig me up when everybody's satisfied with your definition. :-) -jc- On Jan 23, 2015 6:28 AM, Duffy Nightingale, SS du...@soundsoftware.us wrote: Good one! Thanks. Duffy Nightingale On Jan 23, 2015, at 4:32 AM, George Rodriguez george.rodrig...@palmbeachschools.org wrote: lol... Very funny... Thanks for stating my Friday morning with a smile! *George Rodriguez* *Specialist II - IT Solutions* *IT Enterprise Applications* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-251* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Eight Consecutive Years* On Fri, Jan 23, 2015 at 7:09 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: A pilot has to take about 20 crazy guys from Seattle to New York. Yes, you guessed correctly, they're micro$oft programmers. He is worried that they will cause trouble, so he asked an IBM engineer to watch them in the plane. After a few minutes the plane is shaking heavily. Up, down, banking left and right, etc. He asked his co-pilot to take over and rushed back. Hey, engineer! what are they doing? Oh, they're playing rugby. Just stop them please! The plane flew without problems and the pilot is getting worried that it is very silent back. He handed the plane to his co-pilot and went back. Engineer? Where are those programmers? Oh, I asked them to play outside! :-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 -- *Disclaimer: *Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- 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 ** 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: OT: Friday joke :-)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmeelk, Gregory P. Sent: Friday, January 23, 2015 9:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: Friday joke :-) At the point it bursts, it is fully inflated. ITYM was fully inflated. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Chase, John Sent: Friday, January 23, 2015 9:53 AM To: IBM-MAIN@listserv.ua.edu Subject: [EXTERNAL] Re: OT: Friday joke :-) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Siegel The question of the day is, were the balls fully inflated our not? Precisely define fully inflated. Dig me up when everybody's satisfied with your definition. :-) -jc- On Jan 23, 2015 6:28 AM, Duffy Nightingale, SS du...@soundsoftware.us wrote: Good one! Thanks. Duffy Nightingale On Jan 23, 2015, at 4:32 AM, George Rodriguez george.rodrig...@palmbeachschools.org wrote: lol... Very funny... Thanks for stating my Friday morning with a smile! *George Rodriguez* *Specialist II - IT Solutions* *IT Enterprise Applications* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-251* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Eight Consecutive Years* On Fri, Jan 23, 2015 at 7:09 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: A pilot has to take about 20 crazy guys from Seattle to New York. Yes, you guessed correctly, they're micro$oft programmers. He is worried that they will cause trouble, so he asked an IBM engineer to watch them in the plane. After a few minutes the plane is shaking heavily. Up, down, banking left and right, etc. He asked his co-pilot to take over and rushed back. Hey, engineer! what are they doing? Oh, they're playing rugby. Just stop them please! The plane flew without problems and the pilot is getting worried that it is very silent back. He handed the plane to his co-pilot and went back. Engineer? Where are those programmers? Oh, I asked them to play outside! :-D Groete / Greetings Elardus Engelbrecht - [ snip ] ** 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: Overlaid VCON in load module
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On 2015-01-21 15:12, Greg Dyck wrote: Normal (non-directed) LOAD processing serializes fetch processing for a module and only performs relocation of ACONs/VCONs once when the module is fetched. The only way I could see what you describe happen is if there were two RLD entries for the same VCON and it would happen with one load or 20. Does CICS still do its own implementation of LOAD as I understand it used to in order to circumvent such serialization Program Objects would present a challenge. There is still a CICS Loader which is used to load stuff from //DFHRPL. -jc- ** 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: SMF RDW
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Hunkeler Sent: Friday, January 16, 2015 12:33 AM I just want to understand ?how?. Why? I genrally say there is no stupid question, but this one is an exception. There is no use in asking why someone wants to understand how something works. The OP stated that he would like to get a deeper understanding. That should suffice to provide information if available instead tring trying to get justification on the why. No offence intended, Elardus, but you just did answer in a similar way to my query yesterday. I clearly stated that I'm curious to understand how OPEN works. I'm a curious guy. I can think of no detriment to anybody who seeks to understand how, or even why, something does as it does. Discerning the how should not be inordinately difficult, but sometimes the why might be best answered with Spock's At the time, it seemed the logical thing to do. -jc- ** 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: z13 unanswered question.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Thursday, January 15, 2015 10:41 AM [ snip ] How fast could a fully enabled machine mint bitcoins or other cryptocurrency? How much power would such a machine use while doing so? Inquiring minds want to know! Any speculations on what the z13 Jr will be called? The z9, z10 and z12 had EC and BC models, but the z196 had the z114 as its junior machine. Maybe z11 ? -jc- ** 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: z13 new(?) characteristics from RedBook
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Thursday, January 15, 2015 1:49 PM I'm reading the Redbook mentioned by Timothy Stipples on the z13. Some interesting things, to me. [ snip ] 10) Curious statement: quote If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR is not required, and we suggest that a Linux-only LPAR be used instead. /quote I believe that's because z/VM is significantly cheaper if run in an IFL-only LPAR. -jc- ** 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: Another z13 questions
-Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, January 15, 2015 1:32 PM W dniu 2015-01-15 o 20:08, zMan pisze: The other 5 LPARs are used by the NSA. Do you mean No Such Agency or I missed yet another overloaded acronym used here in mainframe context? 'Nonymous Spooks Agency (think Edward Snowden). :-) -jc- ** 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: z13 unanswered question.
Context plus smiley suggest he meant there is no BitCoin machine. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Thursday, January 15, 2015 1:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z13 unanswered question. There never is when to big one is announced. Are you implying knowledge that there won't be a future BC z13? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Thursday, January 15, 2015 9:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z13 unanswered question. There is no BC machine... :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://urldefense.proofpoint.com/v1/url?u=https://www.ibm.com/develop er works/mydeveloperworks/blogs/MartinPackerk=EWEYHnIvm0nsSxnW5y9VI w%3D%3D%0Ar=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0Am=sQpow6UtFUti KN7vBhJaJANh5gPiAYgyswhggfW4bRg%3D%0As=f16263b57387909d061a47 05a05c4311a9756236cf18675dc9feaf29662fe366 From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 15/01/2015 16:40 Subject:z13 unanswered question. Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I have really enjoyed reading about the z13 and some of the new nifties. And, of course, eventually IBM will give out some harder performance number. But I'll bet there is one geek question which will not be answered. How fast could a fully enabled machine mint bitcoins or other cryptocurrency? How much power would such a machine use while doing so? Inquiring minds want to know! -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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 ** 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: Boston - what a place
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony's Basement Computer Sent: Tuesday, January 13, 2015 10:26 AM The entry for Congerville, IL is incorrect. A farmer called it in using the C scale. I drove right by that morning and laughed at the radio. BFD: -36C = -32.8F, which is still frigid. -jc- ** 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: Boston - what a place
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Shannon Sent: Monday, January 12, 2015 8:04 AM When I was in Boston in August and walked up to Fenway, it was bloody hot. I mean seriously hot. And the footy was just played in sub-zero. I live outside of Boston and am used to it (and the sub-zero would have been wind chill, not temperature). When we lived in Minnesota in the mid-1990s my mother visited twice. The first time it was -15F and the second time +95F. That's a 110 degree difference. She couldn't believe it. Dad got assigned to Ladd AFB, Fairbanks, Alaska in the early 1950s. We arrived Fairbanks on July 4, 1953, and the temp was over +90F. Six months later, in January 1954 (don't remember exact date) it was -62F. I was in second grade and had to walk to school in the dark and walk home after school in the dark on that (and many another, similar) day. :-) -jc- ** 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: [IBMTCP-L] Logmode Setting - Screen Size for 3270
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Thursday, January 08, 2015 3:27 AM Cross Posted to IBM main Hello, I am using QWS emulator to connect mainframes. One of our LPAR i am able to logon using IBM DYNAMIC with the screen size 46x133(Model3) but for the other lpars I use the same terminal type but I get 43x80(Model4). Is there a VTAM definition which controls the the screen size for a particular LPAR session ? Is there anything from the VTAM side to modify so that I can pick the IBM DYNAMIC terminal type screen model3 ? With today's 3270 emulators almost universally supporting the 3270 Extended Data Stream (and thereby the QUERY structured field), you can use IBM-supplied logmode D4C32XX3 for everything. I have mine configured as a 3290 (62x160) on z/OS and as Mod3 (32x80) or Mod4 (43x80) on z/VM. Ensure that your TN3270 configuration includes a line like TELNETDEVICE DYNAMIC D4C32XX3,D4C32XX3; otherwise you'll need to specify LOGMODE(D4C32XX3) at LOGON time -jc- ** 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: [IBMTCP-L] Logmode Setting - Screen Size for 3270
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Thursday, January 08, 2015 7:38 AM My connection does not uses the TELNET service but I use Session managers to access the LPARS. So the effected LPAR connections are purely VTAM. So how do you connect to the session managers? -jc- On Thu, Jan 8, 2015 at 6:57 PM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Thursday, January 08, 2015 3:27 AM Cross Posted to IBM main Hello, I am using QWS emulator to connect mainframes. One of our LPAR i am able to logon using IBM DYNAMIC with the screen size 46x133(Model3) but for the other lpars I use the same terminal type but I get 43x80(Model4). Is there a VTAM definition which controls the the screen size for a particular LPAR session ? Is there anything from the VTAM side to modify so that I can pick the IBM DYNAMIC terminal type screen model3 ? With today's 3270 emulators almost universally supporting the 3270 Extended Data Stream (and thereby the QUERY structured field), you can use IBM-supplied logmode D4C32XX3 for everything. I have mine configured as a 3290 (62x160) on z/OS and as Mod3 (32x80) or Mod4 (43x80) on z/VM. Ensure that your TN3270 configuration includes a line like TELNETDEVICE DYNAMIC D4C32XX3,D4C32XX3; otherwise you'll need to specify LOGMODE(D4C32XX3) at LOGON time -jc- ** 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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: I want to add data of 30 VSAM files to one PS flat file.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Butler Sent: Thursday, December 18, 2014 8:19 AM I'd like to state that even after 30 years of MVS, I still use the term file when referring to mainframe datasets. In fact, if you look at the IBM COBOL manual, you will see File Organization, not Dataset Organization; PL/I refers to FILE Attributes, etc. And I think I can safely say I have never seen a DD NULLDATASET command ;-)) Don't be too hard on people just trying to learn. Q: What's the structural difference between a DB2 Table and a VSAM KSDS? A: The DB2 Table contains rows and columns. The VSAM KSDS contains records and fields. -jc- ** 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: I want to add data of 30 VSAM files to one PS flat file.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Thursday, December 18, 2014 9:03 AM On Thu, Dec 18, 2014 at 8:36 AM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Butler Sent: Thursday, December 18, 2014 8:19 AM I'd like to state that even after 30 years of MVS, I still use the term file when referring to mainframe datasets. In fact, if you look at the IBM COBOL manual, you will see File Organization, not Dataset Organization; PL/I refers to FILE Attributes, etc. And I think I can safely say I have never seen a DD NULLDATASET command ;-)) Don't be too hard on people just trying to learn. Q: What's the structural difference between a DB2 Table and a VSAM KSDS? A: The DB2 Table contains rows and columns. The VSAM KSDS contains records and fields. Hum, I might go a bit further. A VSAM KSDS is a disk data set which contains records. A KSDS does not contain fields known to the access method. Therefore a VSAM KSDS does not have any fields in it. The fields within a KSDS record are imposed by the program reading the data set by overlaying the buffer contain the record with a template (COBOL FD or equivalent). VSAM itself does not know anything about them. At most, VSAM knows the location and length of the key data. This key data could be a single field or a composite of multiple fields in some application. BTW, have you been reading some of Joe Celko's SQL books? That, in general, is one thing he is constantly emphasizing about the difference between files (he doesn't use data set) and databases. As he keeps drumming: A table IS NOT a file! A row is not a record. And a column is not a field. Yabbut The structure of a DB2 table is imposed by the table definition, just like the structure of a KSDS is imposed by the DSECT (or HLL equivalent). The access method in both cases is still VSAM (ignoring the difference between CI access for the LDS used by DB2 and the logical record access normally used for a KSDS); SQL is the API for DB2, while RYO applies for KSDS. At the lowest level, on DASD both are just strings of ones and zeroes. :-) -jc- ** 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: RECFM=VBS,LRECL=32767?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller limit. In a VSAM Control Interval (CI), the CIDF is 4 bytes (think BDW) but the RDF is three bytes (think RDW). So, with VSAM you get an extra byte of space. :-) -jc- ** 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: Regular Expressions in ISREDIT z/OS 2.01
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Alan Watthey Sent: Wednesday, December 10, 2014 11:45 PM David, Yes, this function works perfectly for me. You need to use R or RC in front of what you are finding or changing (first parameter). You have to learn regular expressions of course which can be a bit mind blowing but knowing PERL helps in my case. Although everyone seems to implement regular expressions differently enough to make you have to think. I love this new feature because I can now change lower case to lower case and upper case to upper case separately in files. Having a brain cramp If you change lower case to lower case, what gets changed? Same question for upper case to upper case. -jc- ** 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
SLIP SET vs DISPLAY SLIP
Hi, List, I set a SLIP IF trap that included DATA=(0R,EQ,0,AND,12R,EQ,25BD8),ID=ID01. The response to a D SLIP=ID01 command shows DATA=0,0R,EQ,,AND,12R,EQ,00025BD8 . Where did that leading zero immediately after the DATA= come from? I deleted and reset the SLIP, and the leading zero is still there on a D SLIP command. TIA, -jc- ** 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: SLIP SET vs DISPLAY SLIP
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chase, John Sent: Thursday, December 11, 2014 2:29 PM Hi, List, I set a SLIP IF trap that included DATA=(0R,EQ,0,AND,12R,EQ,25BD8),ID=ID01. The response to a D SLIP=ID01 command shows DATA=0,0R,EQ,,AND,12R,EQ,00025BD8 . Where did that leading zero immediately after the DATA= come from? I deleted and reset the SLIP, and the leading zero is still there on a D SLIP command. TIA, -jc- Sorry; it's on z/OS 1.13. -jc- ** 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: Regular Expressions in ISREDIT z/OS 2.01
-Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Thursday, December 11, 2014 10:08 PM On 12/12/2014 11:38 AM, David Speake wrote: I did a double DUH! when I saw the missing R reply. It wasn't quite that bad.I cannot cut/paste the brackets [] from/to or to/from my Reflections for IBM 3270 emulator session. Had to FTP them into my TSO/PDS and ofcourse key them into the question. The Find command in the macro did have the brackets. I still cannot find that C runtime that the Help facility says that I MUST have. Cross Posting to ISPF-L at Notre Dame. The non-XPLINK C runtime (/CEEEV003//)/ can be found in CEE.SCEERUN. At most sites that's in the linklist. It's also delivered in CEE.SCEELPA (z/OS 1.13), so it might be in the LPA also. -jc- ** 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: I want to add data of 30 VSAM files to one PS flat file.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of MURALI KANNAN Sent: Wednesday, December 10, 2014 4:13 AM I would sort the VSAM files using a key and then copy the data to flat file, to avoid duplication or merging of data. Correct me if I am wrong. The OP did not specify what type of VSAM datasets are involved. If KSDS, they are already sorted on a key value, and might be amenable to a MERGE operation (but what about duplicate keys?). Other considerations: 1) Are all the VSAM datasets the same type? 2) Do they all have the same RECFM and LRECL? 3) are there any alternate indices in the set? Based on the limited information given originally, the simplest means seems to be IDCAMS REPRO from each VSAM dataset in turn, to a VB flat file coded with DISP=MOD. Whether that output VB flat file might be useful is a separate problem. -jc- ** 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: Ancient IEFUSI
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane Ginnane Sent: Monday, December 08, 2014 6:54 PM On Mon, 8 Dec 2014 06:03:50 -0500, Mitch wrote: ... but why check when a job is submitted? Why not check before ... Wheww - tuff requirements. I've done some exits in my time, but none that get inside users head(s) - not real sure I want to go there. Does this mean you're giving up on the DWIM macro? :-) -jc- ** 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: RSU UNZIP space issue.
We have a full-volume zfs on a Mod-9 set aside for this kind of situation. Gives us about 8 GiB. Just hang it on a convenient mount point and point //SMPWKDIR at it, and away we go. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, December 09, 2014 8:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU UNZIP space issue. So the statement originalsize=5085091600 or 5,085,091,600 bytes. That is probably how big the file should be. However I would make it larger. What is the current size? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, December 09, 2014 7:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU UNZIP space issue. Hello Kurt, Thanks for response. I just checked this /u/SLE/RSU1410/GIMPAF.XML file and found below entry. ARCHDEF name=SMPPTFIN/S0001.SHOPZ.S2654303.SMPMCS.pax.Z type=SMPPTFIN originalsize=5085091600 size=2760339456 hash=1C69AA496915DB08EF19DBC53C0A0221D6EC7D39 /ARCHDEF By looking at this, can you please suggest, what should be the size of /u/SLE/RSU1410/temp for SMPWKDIR DD. On Tue, Dec 9, 2014 at 7:28 PM, Kurt Quackenbush ku...@us.ibm.com wrote: But my unzip still getting failed, with below error. I tried enough ways by having larger size but same issue. The space error occurs during the unpax operation. Therefore, the directory identified on the SMPWKDIR DD statement is where you need free space. In your case that is /u/SLE/RSU1410/temp. I suggest you check out file /u/SLE/RSU1410/GIMPAF.XML and look for the ARCHDEF statement that describes the SMPMCS file. On that statement is an originalsize attribute that identifies, in bytes, how big the uncompressed original SMPMCS file is. You will need at least this much free space in the SMPWKDIR directory. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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: LPAR IPL order within a Sysplex
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Ten Eyck Sent: Friday, December 05, 2014 10:10 AM Sorry for the confusion... these LPARs are in a Parallel Sysplex (using CF), but not utilizing many of the Parallel Sysplex features. Reading through the documentation... I guess it might fall under the description of BronzePlex. Ahh... Just enough sysplexing to qualify for PSLC. :-) -jc- ** 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: Setting up a sysplex and OMVS/zFS
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Chu Sent: Friday, December 05, 2014 2:10 PM Hi Doug, Ok, so I need to make the z2.1 dasd volumes that contains the datasets to be mounted available to the zOS 1.13 system. How would I catalog the z2.1 datasets in zOS1.13? I haven't found a way to catalog those zFS datasets. Any ideas? Shared catalog? -jc- ** 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: Death of spinning disk?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Friday, November 28, 2014 2:14 AM [ snip ] - smoke/vapor-based recording; I use the word recording here quite consciously. These recording systems could not be played back when they were invented and used. They were simply used for studying the general behavior and characteristics of sound waves. Now, thanks to digital processing -- high resolution digital scans of the smoke imprints combined with computer-based reconstruction of the audio that produced the imprints -- the information they contain can be recovered. That's how the world's oldest sound recordings are now being retrieved. Unfortunately Abraham Lincoln probably didn't speak into such a mechanism, or at least his recording was lost, so it's extremely unlikely a recording of his voice will ever be recoverable and playable. Might have been fun to hear Chopin and Liszt play Dueling Pianos :-) [ snip ] -jc- ** 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: Archive search problems
Google 'bit.listserv'. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dazzo, Matt Sent: Wednesday, November 26, 2014 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Archive search problems Dave, thanks that's awesome. Is there an index in google for all the listserv groups? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, November 26, 2014 10:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Archive search problems In the absence of that, you can see everything here: https://groups.google.com/forum/#!forum/bit.listserv.ibm-main I actually find it easier to use this than the archives. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dazzo, Matt Sent: Wednesday, November 26, 2014 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Archive search problems I am unable to search the archives because listserv.ua.edu keeps telling me to sign in, even though I am already signed in. I even changed my pw and confirmed it. But when I go to the archives and try to search I get the sign in screen and my pw is not accepted. The results are the same with Chrome and IE. Any help is appreciated, thanks. Thanks, Matt Dazzo Senior Systems Programmer Publishers Clearing House -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 ** 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: No surprise: Bloomberg report on no shortage of tech workers
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, November 25, 2014 8:01 AM Just a shortage of LOW COST workers who can do the job. quote The real issue, say Salzman and others, is the industry’s desire for lower-wage,more-exploitable guest workers, not a lack of available American staff. “It seems pretty clear that the industry just wants lower-cost labor,” Dean Baker, the co-director of the Center for Economic and Policy Research, wrote in an e-mail. /quote http://www.businessweek.com/articles/2014-11-24/the-tech-worker-shortage-doesnt-really-exist yawn So, when has an industry or business ever sought out higher-priced labor when qualified, competent lower-priced labor was available? Or was I asleep at the time? -jc- ** 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: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Tuesday, November 25, 2014 8:14 AM Peter Ten Eyck wrote: LE runtime is TERMTHDACT(UADUMP,,96) Ok. I will bite. I see in LE book, this: Under non-CICS, if the appropriate DD statement is used, you will get a system dump of your user address space. A$$suming you're not running CICS, did you used that DD statement? (Even after some RTFM, I think it is CEEDUMP, yes, I know you wrote you used CEEDUMP, but now I'm wondering?) I believe, but am not inclined to look it up at this moment, it is //SYSUDUMP or //SYSMDUMP, depending on whether you want a formatted dump or one you can examine with IPCS. -jc- ** 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: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Tuesday, November 25, 2014 8:42 AM Lizette Koehler wrote: Also these share presentations may be helpful http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/confer ence/share.html Ah, yes. I remember now. Thanks Lizette! Peter Ten Eyck, are you using a SLIP? According to that presentation, you should not use a SLIP on S0Cx abends. Please review your SLIP settings. Also I see there: 'LE environment has already been cleaned-up and therefore a dump at this point is useless.' Hmmm, very interesting. Indeed. We're currently working a PMR in which, to get an SVCDUMP of a S0C4 before LE's condition handlers got hold of it, we coded an LE override 'TRAP(OFF,NOSPIE)' in the PROC and set a SLIP trap for the 31 jobs (we used the default MATCHLIM=1 because we needed only one dump). We also had to disable Fault Analyzer's dump intercept with //IDIOFF DD DUMMY in the PROC. We also concurrently had a SLIP SA trap recording a GTF trace on the same 31 jobs. IBM Support now has all that doc; hopefully it will reveal the culprit. -jc- ** 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: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Sent: Tuesday, November 25, 2014 9:46 AM On 11/25/2014 8:19 AM, Chase, John wrote: [ snip ] Indeed. We're currently working a PMR in which, to get an SVCDUMP of a S0C4 before LE's condition handlers got hold of it, we coded an LE override 'TRAP(OFF,NOSPIE)' in the PROC and set a SLIP trap for the 31 jobs (we used the default MATCHLIM=1 because we needed only one dump). We also had to disable Fault Analyzer's dump intercept with //IDIOFF DD DUMMY in the PROC. We also concurrently had a SLIP SA trap recording a GTF trace on the same 31 jobs. IBM Support now has all that doc; hopefully it will reveal the culprit. -jc- If you want to see the environment before clean up, look at these LE runtime options for TERMTHDACT: UADUMP, UAONLY, UATRACE, UAIMM. Tried UAIMM; it dumped too late for the problem we're having. Thus the 'TRAP(OFF,NOSPIE)' and a SLIP trap. -jc- ** 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: z/OSMF audit (was Re: WLM in batch?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Sent: Tuesday, November 25, 2014 12:25 PM I was told that System Programming would be reduced to PARMLIB updates. Circa 1981. And.. In a previous job as a CSR for an ISV, we got a new boss. In his first intro meeting, he explained that our job was, essentially, to try to work ourselves out of a job. But fear not: New releases always introduced new bugs^H^H^H^Hfeatures. :-) -jc- ** 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: Getting ptfs for a specific FMID
-Original Message- From: IBM Mainframe Discussion List On Behalf Of ??? ?? ??? Sent: Monday, November 24, 2014 7:55 AM Hi, Is it possible to use RECEIVE ORDER for a specific FMID? I am running SMP/E 36.11 on z/OS 1.13. Yes, but only if the specific FMID is the only FMID in a specified Target Zone, or you specify CONTENT(PTFS(list_of_ptfs_applicable_to_specific_FMID)). -jc- ** 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: Getting ptfs for a specific FMID
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, November 24, 2014 10:01 AM On Mon, 24 Nov 2014 07:41:14 -0700, Lizette Koehler wrote: http://www-01.ibm.com/support/docview.wss?uid=swg21225816 You can order maintenance in the following ways: individual PTFs PTFs for individual APARs service for individual installed FMIDs --- - service for individual installed products (requires SMP/E 3.2) service for all installed products in one or more SMP/E zones service for all licensed products in one or more SRELs (new and improved - not a service only CBPDO) But consider: you might also need: o PTFs for cross-FMID (IF ...) REQs o Cross-FMID PTFs resolving HOLD ERRORs sort of a RECEIVE ORDER GROUPEXTEND. GROUPEXTEND seems to be in force when the IFREQ FMID(s) exist(s) in (one of) the target zone(s) specified on RECEIVE ORDER. I have ordered specific PTFs for (e.g.) the COBOL v5.1 compiler (HADB510), and IFREQ PTF(s) for Language Environment (LE) were also RECEIVEd when I specified FORTGTZONES(CBL510T,MVST100). We have LE (HLE7780) in the MVST100 zone -jc- ** 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: Tail of MVS SYSLOG
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Monday, November 17, 2014 8:08 AM One solution I saw was using a Screen Scrapper process. Have a PC setup that only has SYSLOG streaming to it. Then have the screen scrapper monitor. I'm pretty sure you meant scraper rather than scrapper. A bit of difference between the two, and chell specker won't catch it. :-) -jc- ** 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: RDz v9.0 and DIAGxx VSM USEZOSV1R9RULES(NO)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of nitz-...@gmx.net Is anybody out there running the RSE server on z/OS (1.13) with USEZOSV1R9RULES(NO) successfully? Anybody have any other idea why today the developers cannot authenticate to the RSE server as they did before the most recent IPL of the DEV lpar? We are running RSED8.5 with USEZOSV1R9RULES(NO) successfully. [ snip ] As for the second question: What else was changed with that IPL? Nothing. The USEZOSV1R9RULES(N0) was supposed to have been included in the previous weekend's IPL of RSU1409 maintenance (plus HIPERs, PE fixes, SECINTs and all available PTFs for COBOL compilers and LE) but got overlooked. Thus, a catch-up IPL was scheduled when normally we IPL that lpar monthly, on a maintenance weekend. -jc- ** 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: SMP/E APPLY output capture question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Hardee, Chuck No, at least not intentionally. When I run my usermod using no changes to the CSI and/or JCL, the output is directed, via the MSGCLASS parm on the JOB statement to class X, which is a hold queue. When I modify the output requirements to go to another class, class F in this case, it, too, is a held class that our Production Control personnel receive output in that has to be reviewed and then, if it passes muster, is filed into their source control system. In the off chance that that was the case, I added HOLD=YES on the DD statement for SYSPRINT, but whether that worked or not, I can't say as I never received any output on that DD when I ran my APPLY, which is another issue I had pointed out in previous replies. Frankly I am confused as to what is happening since what I am wanting to do should be very straight forward. Indeed, JCL overrides just work. Assuming you have DDDEFs for all required datasets, your APPLY job that works could be as simple as: //jobname JOB acctg.info,MSGCLASS=X,... //stepname EXEC PGM=GIMSMP[,REGION=0M[,...]] //SMPCSI DD DISP=SHR,DSN=my.smp.global.csi //SMPCNTL DD * SET BDY(tgtzone) . APPLY S(usermod) ASSEM REDO . /* Based on your descriptions, you get your //SYSPRINT output in class X. To get your //SYSPRINT output into class F, you need only add one JCL statement: //jobname JOB acctg.info,MSGCLASS=X,... //stepname EXEC PGM=GIMSMP[,REGION=0M[,...]] //SMPCSI DD DISP=SHR,DSN=my.smp.global.csi //SYSPRINT DD SYSOUT=F === add this statement //SMPCNTL DD * SET BDY(tgtzone) . APPLY S(usermod) ASSEM REDO . /* It really is that simple. -jc- ** 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: SMP/E APPLY output capture question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Hardee, Chuck See, that's the rub. As I understand SMP/E, if there is no DD in the JCL, then SMP/E will allocate based on the DDDEFs. If there is a DD in the JCL, then SMP/E will use it. The first attempt at capturing the output was to do exactly as you indicated. That didn't work for whatever reason, and I say it that way because not only did I get no output on SYSPRINT, I did not get any errors reported on the JES log, SYSMSGs, SMPOUT or SMPRPT. And, I'm using a usermod that APPLYs with a return code of 0 and an assembly listing as well as a link map. Are you perhaps trying to re-capture the //SYSPRINT by doing APPLY CHECK? With CHECK, you won't get any assembly or link-edit output. -jc- ** 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: SMP/E APPLY output capture question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Hardee, Chuck No, I have an APPLY CHECK step executing separately, ahead of, my APPLY. It's the APPLY step I'm trying to capture. To the extent you can do so without divulging any proprietary information, could you copy / paste the actual job you're running in its entirety? Something is obviously amiss. -jc- ** 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
RDz v9.0 and DIAGxx VSM USEZOSV1R9RULES(NO)
Hi, All, This past weekend we IPLed our DEV lpar with VSM USEZOSV1R9RULES(NO) for the first time. After a brief period (on Sunday), it was noticed that one subsystem failed to start (an ancient Oracle API of some kind). A fresh DIAGxx containing USEZOSV1R9R7LES(YES) was dynamically activated, and the recalcitrant subsystem started normally. Today, application developers using RDz are unable to authenticate to the host RSE (Remote System Explorer) server, getting error RSEC1002 Invalid password or User ID. On the off chance that the USEZOSV1R9RULES(NO) at IPL might have munged something, I bounced the RSE server on the host, but to no avail. Is anybody out there running the RSE server on z/OS (1.13) with USEZOSV1R9RULES(NO) successfully? Anybody have any other idea why today the developers cannot authenticate to the RSE server as they did before the most recent IPL of the DEV lpar? TIA, -jc- ** 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: What address space is using AUX slots?
Reaching 100% might make you SAD. :-\ -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (SPLXM) - KLM Sent: Monday, October 27, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What address space is using AUX slots? Rereading your answer, I wonder what it is that 'we should not get anywhere near'? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: 27 October, 2014 9:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What address space is using AUX slots? We should throw the 30% rule in the bin IM(NS)HO. Only relates to Continuous Slot Allocation Algorithm break down and we shouldn't get anywhere near it; The economics of memory (and a fortiori with Flash) make this near obsolete. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/10/2014 08:11 Subject:Re: What address space is using AUX slots? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU The 30% rule is a performance rule, not a capacity rule: 1. you should have enough space to accommodate a large page-out burst, when I occurs. 2. you should not fill this space over 30% to keep good performance on your page-outs. Although I think this rule is more important in a constantly paging system and less important for a one time page-out burst. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: 25 October, 2014 0:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What address space is using AUX slots? As long as he doesn't exceed 30% usage, he should be fine. Maybe automatically issue the command hourly to find the peak? On Fri, Oct 24, 2014 at 2:33 PM, Gibney, Dave gib...@wsu.edu wrote: Just because you are not paging due to lots of real/flash isn't a reason to not have sufficient page datasets in case you need them for dumping of some runaway memory gobbler. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, October 23, 2014 12:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What address space is using AUX slots? Peter Hunkeler wrote: It seems, we've got enough real storage and enough Flash Memory. There is hardly any paging. We've got two local page data sets mainly because VIO paging will not go to Flash Memory. We're starting to see local page data set usage at ~30%. I conclude that this must be VIO data being paged out. What let you arrive at that conclusion? Just curious if you don't mind please. I'm not very fluent in using neither RMF, nor MAINVIEW. I'd like to find out which AS is causing this AUX usage. Not that I'd currently think, we're in touble. Just curious. Does anyone have some hints where to start? Do you want 'snapshot' (with RMF II), interactive monitoring (RMF III) or some post-processing? Depending on what you want to do, you can use RMF batch using SMF records, RMF II or RMF III or RMF Spreadsheet Reporter. (Or you can go Martin Packer's entertaining way... :-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 -- 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 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-
Re: [ANN] Lua4z: the Lua programming language on z/OS, with batteries
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of David Crayford
On 24/10/2014 6:50 AM, Bernd Oppolzer wrote:
Doesn't the example in the benchmark show performance problems in
EXECIO instead of REXX? EXECIO, IMO, is not part of the REXX
interpreter, but instead it is a vehicle (an external function) to do
I/O from REXX on z/OS.
Other REXX implementations
(for example, on Linux or Windows) don't use EXECIO etc.; I/O there is
done with native REXX functions.
I don't want to be too disparaging about REXX but I've profiled it
extensively and it is not an effecient implementation. The variable
access routines are where it spends a lot of time so any address SUBCOM
interface is slow
when compared to fast scripting languages. Compiled REXX has a serious
flaw in it's memory management. I profiled it using IBM APA and it
appears to do a GETMAIN every time it wants a new stem varaible element.
It could be dramatically improved just be using a better storage
manager. I would want my money back if I paid for the REXX compiler.
So to be fair, the REXX interpreter functions should be compared with Lua
interpreter functions, for example: some loop control or arithmetic.
Compiled languages like C will always outperform interpreted languages
in this area, so such comparisons are only of academic interest.
Lua is written in C and the majority of it's libraries are too. In some
cases there is only 10% overhead for the Lua VM. I've got an SQL
bench-test where Lua is not too far off C. And much easier to code and
maintain.
OK, let's try simple matrix multiplication which should test both array
access and math.
/* REXX */
arg count
if count = then count = 100
start = sysvar(SYSCPU)
do i = 1 to count
a.i = i * i
end
say 'CPU time = 'sysvar(SYSCPU) - start
CPU time = 3.57
local t = require(timer)()
local count = arg[1] or 100
local a = {}
for i = 1, count do a[i] = a[i] * i end
t:print_elapsed()
elapsed time: 0.131965
That's a huge difference, two orders of magnitude.
But remember that IBM also sells hardware.. :-)
-jc-
Kind regards
Bernd
Am 24.10.2014 00:24, schrieb Shane Ginnane:
Good one Dave, glad you were able to convince your powers that be
to get this out the door.
Let's hope it gets some acceptance.
Now you have Lua installed why don't you bench-test it against REXX and
report if you get similar results to what I get on my machine
Now don't you go training everybody out there as to what a slug REXX
really is ... ;-)
Shane ...
--
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
**
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: ShopzSeries down?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. I get the same 'null'. I am trying to get a Security Integrity APAR (SIA) PTF for MQ. :-( Have you not configured a RECEIVE ORDER job for obtaining PTFs? Greatest thing since sliced bread. :-) -jc- ** 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: ShopzSeries down?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Beesley, Paul Oh for a mainframe with an internet connection ... sadly, not... customers say no. A RECEIVE ORDER capability here would be welcomed... Our sandbox system is allowed client only external access, and only to IBM and our ISVs. -jc- ** 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: Question about Enterprise COBOL 5.1 LE compatible level.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Yuhas I have been asked to install Enterprise COBOL 5.1 which went GA in October of 2013. We are currently running z/OS 1.13 with a current RSU Level of 1404. We have Enterprise COBOL 4.2 and the corresponding LE level that came with z/OS 1.3 in February of 2012. Correct me if I am wrong, but, I don't think our current level of LE can support COBOL 5.1. Is there some maintenance that will upgrade our LE level to be compatible with COBOL 5.1? There are a few PTFs for LE that are required to support Enterprise COBOL v5.1. The minimum are listed in the COBOL v5.1 Program Directory, but several more have been issued since then. The have been several PTFs issued for COBOL 5.1 as well, including a few roll-up PTFs you probably should consider essential. Each of those roll-ups, most recently issued in March, May, July and September 2014, addresses a dozen or more APARs. You might also consider a recent COBOL 4.2 PTF that introduces a new compile-time option FLAGMIG4, intended to identify existing source statements and compile-time options that might be unsupported or handled differently in COBOL 5.1. Unfortunately I don't have a list of all the PTFs handy at the moment. -jc- ** 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: QUESTION ABOUT VSAM / VSAM EXTENDED
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John Eells What is the maximum number of cyclinders that can be used to define a dsn that is not VSAM EXTENDED. I think it is 4400 cylinders. I was trying to allocate a dsn at 4500 4500 but I kept on abending with IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES Finally I was able to allocate the dsn at CYL(4350 4350). z/OS DFSMS Using Data Sets documents maximum data set sizes, including limits for both extended format and nonextended format VSAM data sets, in Topic 1.3.2.3. It says that nonextended VSAM data sets have a limit of 4GB*. (4GB* / 56664 / 15) = 5,053 cylinders (approximately) [ snip ] * I believe that is most likely GiB for the pedantic among us. IIRC, DASD capacities are expressed in decimal, rather than binary, quantities: 4KB = 4,000 bytes; 4MB = 4,000,000 bytes; 4GB = 4,000,000,000 bytes; Etc. -jc- ** 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: 64bit
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant On Fri, 17 Oct 2014 16:36:38 -0400, Don Poitras wrote: I guess it depends what you mean by I would like to use 64bit storage for some functions from Cobol. If the Cobol part is never going to directly use the memory, then there's no problem in a called program in another language using above the bar storage. Just remember to SAM 31 before you return to Cobol (unless you use one of the calls that automatically returns you in the correct amode.) If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. But see APAR PI17184 for an instance when BSM did not return correctly. -jc- ** 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: 64bit
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Chase, John wrote: But see APAR PI17184 for an instance when BSM did not return correctly. Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS? That was the situation when I opened the PMR for which the APAR was opened. Presumably it could have occurred in a batch program as well. With what LE version is that APAR? z/OS 1.13 (HLE7780) -jc- ** 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: HSM Recall process
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler z/OS V1.12 - Yes I know. Okay, I am sure this is in a very easy to locate part of the HSM Admin manual, but I just am not seeing it. This should be an easy question. I want to recall 5000 datasets. Do I still need to 1) List all datasets from an HLIST 2) Sort that list on the Migrate Volser 3) Send in the recalls based on the collection of datasets based on which migrate volume they are on? Or can I enter all of the requests and HSM is smart enough to know to recall all of the datasets from the same tape and not mount tapes as it reads the DSNs in FIFO? The helpful manual is not really helping. Our HSM guru cites this: Found this in the HSM Admin for Z/OS 1.11 - An exception to the order of processing is when doing recalls from tape, where DFSMShsm reduces the number of mounts by doing several recalls from a given tape while the tape is continuously mounted. If a recall task has just completed a recall from a tape, it processes the highest-priority request that is currently on the queue for that same tape, no matter where the request is positioned on the queue. DFSMShsm continues to process only recalls from this single tape for a duration of time that is specified by the TAPERECALLLIMITS parameter. After the time specified by the TAPERECALLLIMITS parameter is reached, DFSMShsm determines whether a higher-priority recall request that needs this tape exists on another DFSMShsm host. If so, it ends the recall processing on the tape by the current DFSMShsm host, freeing the tape for use by other hosts. If no higher-priority request exists, DFSMShsm continues to process any recalls requested from the tape. DFSMShsm checks after every recall for a higher-priority recall request from other hosts. -jc- ** 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: Performance in S9(08) COMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Arellanes You might want to read the COBOL Performance Tuning paper (for Enterprise COBOL 4.2) at: http://www-01.ibm.com/support/docview.wss?rs=203q=7018287uid=swg27018287 to see the performance implications of various compiler options, run-time options, data types, and other factors. Interesting. Is an update for Enterprise COBOL v5.1 planned, or in the works? Would such an update include data on the effects of the different ARCH(n) levels? -jc- ** 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: Performance in S9(08) COMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ron Thomas Sent: Wednesday, October 15, 2014 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Performance in S9(08) COMP Hi . In our cobol programs we have the variables declared as s9(09) COMP, now one of the experts in our area is proposing to use s9(08) COMP as this would give better performace . Could some one please let us know whether the change is going to provide good performance ? It depends. See the following two links (Enterprise COBOL v4.2, but probably valid back to VS COBOL II): http://www-01.ibm.com/support/knowledgecenter/#!/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlddecom.htm http://www-01.ibm.com/support/knowledgecenter/#!/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ui/up4060.htm -jc- ** 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: Upgrade to Enterprise COBOL v5.1
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Bernd Oppolzer I only had similar problems once in 2008 ca., but then subtasking was involved and APL etc., and there was some sort of race condition where one subtask ran too fast and the POST/WAIT protocol dit not work ... ABEND S201, IIRC ... the error was in IBM code, not in ours. The problem occured only on newer hardware with many processors, only every 5 hours or so, and only when there was heavy load by other concurrent jobs. IBM maintenance was not able to reproduce the error, because our machines were faster than theirs. Very hard to find ... I don't think that such problems may be involved here ... I'm inclined to think not, as well. GTF trace (we captured the last 15 seconds or so before dump invocation) showed that each alteration of the monitored storage was caused by the same LE module, and the only two values observed were x'' and the same non-zero value every time it was non-zero. another idea that comes to mind: areas of storage that are normally zero, but now due to opsys release changes etc. are non-zero, and the application (which by error doesn't initialize some automatic variables properly) now fails. That is: a programming error that was there all the time, but now shows up for the first time. Certainly possible, but we think very unlikely. The same source code, compiled with COBOL 4.2, runs without problem every time. The application program itself was first written in 1996, when we were using OS/VS COBOL and VS COBOL II. And we still run z/OS with VSM USEZOSV1R9RULES=YES defaulted in DIAGxx. -jc- ** 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: Upgrade to Enterprise COBOL v5.1
It appears that we captured relevant problem data via GTF tonight, so we shall
see what we shall see, when we see it.
-jc-
-Original Message-
From: Chase, John
Sent: Thursday, October 09, 2014 12:44 PM
To: 'IBM Mainframe Discussion List'
Subject: RE: Upgrade to Enterprise COBOL v5.1
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Keith Smith
Cut-n-past to the list maybe?
I s'pose:
something like
SLIP
SET,SA,RA=(25DCC,25DCF),ASIDSA=('JOBNA*'),A=TRACE,TD=(STD,REGS,25DCC,25DCF
),ID=OVLY,END
And I would go with a MODE=INT GTF trace, with SD=10M.
The SLIP dump of the U4087 abend should contain the most recent 10MB of GTF
trace.
The specific addresses in the SLIP are where the job has allocated the
storage that holds the pointer
that got corrupted in each previous dump, so we're gambling on it being at
the same virtual address
in each job next time we try to trap the corrupter. Note the generic job
name in ASIDSA.
-jc-
On Thu, Oct 9, 2014 at 11:00 AM, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jim Mulder
[ snip ]
I reviewed your PMR and dumps, and made some suggestions in the PMR.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Thank you, Sir. We'll run it by Change Control, and possibly try
your suggestions tonight.
-jc-
** 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
--
Keith Smith
Engineer-Enterprise Sys Sr.-IT Capacity Performance Shaw Industries Inc.
Subsidiary of Berkshire Hathaway
616 E Walnut Ave
Mail Drop 072-04
Dalton, GA 30721
Email: keith.sm...@shawinc.com Office: 706.532.3244
Please consider the environment before printing.
--
**
Privileged and/or confidential information may be contained in this
message. If you are not the addressee indicated in this message (or
are not responsible for delivery of this message to that
person) , you may not copy or deliver this message to anyone. In such
case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages
of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions
or other information in this message that do not relate to the official
business of the company or
its subsidiaries.
**
--
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: Upgrade to Enterprise COBOL v5.1
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder [ snip ] I reviewed your PMR and dumps, and made some suggestions in the PMR. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Thank you, Sir. We'll run it by Change Control, and possibly try your suggestions tonight. -jc- ** 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: Question on PER-SLIP and PRCNTLIM.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Hunkeler Jim, Peter Thanks a lot. I understand it is not some precise measurement. I understand this as a means to keep a badly written SLIP from negatively impacting the system. Out of curiosity: When SLIP SLIH code is active for a SLIP, what happens if another SLIP is triggered on another CP? Is the system in a non-dispatchable state? Is SPIN SLIH code serialized? --Peter Hunkeler Found this note in the doc for SLIP SET parameters: Between the instant matchlim is reached and when the trap is actually disabled, a small amount of time elapses. It is possible for the trap to match on another CPU during this small time interval. If this occurs, matchlim will actually be exceeded, with unexpected results. Therefore, use caution in setting a trap in a heavily used module as, for example, the dispatcher. Not sure if this would apply generally, though. -jc- ** 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: Upgrade to Enterprise COBOL v5.1
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Keith Smith
Cut-n-past to the list maybe?
I s'pose:
something like
SLIP
SET,SA,RA=(25DCC,25DCF),ASIDSA=('JOBNA*'),A=TRACE,TD=(STD,REGS,25DCC,25DCF
),ID=OVLY,END
And I would go with a MODE=INT GTF trace, with SD=10M.
The SLIP dump of the U4087 abend should contain the most recent 10MB of
GTF trace.
The specific addresses in the SLIP are where the job has allocated the storage
that holds the pointer that got corrupted in each previous dump, so we're
gambling on it being at the same virtual address in each job next time we try
to trap the corrupter. Note the generic job name in ASIDSA.
-jc-
On Thu, Oct 9, 2014 at 11:00 AM, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jim Mulder
[ snip ]
I reviewed your PMR and dumps, and made some suggestions in the PMR.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Thank you, Sir. We'll run it by Change Control, and possibly try your
suggestions tonight.
-jc-
**
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
--
Keith Smith
Engineer-Enterprise Sys Sr.-IT Capacity Performance Shaw Industries Inc.
Subsidiary of Berkshire Hathaway
616 E Walnut Ave
Mail Drop 072-04
Dalton, GA 30721
Email: keith.sm...@shawinc.com Office: 706.532.3244
Please consider the environment before printing.
--
**
Privileged and/or confidential information may be contained in this message.
If you are not the
addressee indicated in this message (or are not responsible for delivery of
this message to that
person) , you may not copy or deliver this message to anyone. In such case,
you should destroy this
message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of
this kind, please advise the
sender.
Shaw Industries does not provide or endorse any opinions, conclusions or
other information in this
message that do not relate to the official business of the company or its
subsidiaries.
**
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu
with the message: INFO IBM-MAIN
**
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: Upgrade to Enterprise COBOL v5.1
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Keith Smith
Thank you! We are about to start looking at V5.1 for production and I am
accumulating a quick list for
reference if we run into anything. We have had success so far with the
limited testing we have
completed.
We've had only one problem with COBOL v5.1 in DEV/Test: An XML converter
program for a CICS Web Service, generated by RDz v9.0.1.2 and compiled with
COBOL v5.1, does not run; instead returning error message IRZS Failed to
retrieve the text of a Language Environment runtime message. Verify that the
Language Environment runtime message module
for facility IRZ is installed in DFHRPL or STEPLIB. The same source deck
compiled with COBOL v4.2 runs fine.
RDz Support is currently working a PMR for that.
-jc-
On Thu, Oct 9, 2014 at 1:43 PM, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Keith Smith
Cut-n-past to the list maybe?
I s'pose:
something like
SLIP
SET,SA,RA=(25DCC,25DCF),ASIDSA=('JOBNA*'),A=TRACE,TD=(STD,REGS,25DCC,2
5DCF
),ID=OVLY,END
And I would go with a MODE=INT GTF trace, with SD=10M.
The SLIP dump of the U4087 abend should contain the most recent 10MB
of GTF trace.
The specific addresses in the SLIP are where the job has allocated the
storage that holds the pointer that got corrupted in each previous
dump, so we're gambling on it being at the same virtual address in
each job next time we try to trap the corrupter. Note the generic job name
in ASIDSA.
-jc-
On Thu, Oct 9, 2014 at 11:00 AM, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jim Mulder
[ snip ]
I reviewed your PMR and dumps, and made some suggestions in
the
PMR.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Thank you, Sir. We'll run it by Change Control, and possibly try
your suggestions tonight.
-jc-
**
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: RACF sysplex communication
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Ten Eyck How do I tell if a given LPAR has RACF sysplex communication enabled? Console command RVARY LIST: . . . MEMBER smfid IS SYSPLEX COMMUNICATIONS ENABLED IN DATA SHARING -jc- ** 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: IODF for OSA Exp3 Port 1
Hmmm.. Are you perhaps confusing this Chris Mason with the late SNA expert of the same name? -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Tuesday, October 07, 2014 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IODF for OSA Exp3 Port 1 On Tue, 7 Oct 2014 08:15:56 -0400, Christopher Mason wrote: Been a little quiet of late Chris - fallen back into the rabbit hole ? ... ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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: SMP/E Misleading Error Message
Having installed HCTG900 (CICS Transaction Gateway v9.0) into our CICS TS 5.1 GLOBAL CSI according to the instructions in its Program Directory, I cannot explain how HCTG900 was missing from the Global zone's FMID list, but it wasn't there. Adding HCTG900 to the Global zone's list allowed the RECEIVE ORDER job to complete successfully. I've sent a RCF suggesting changes to both the message text of GIM69213S and its explanation in the SMP/E Messages, Codes, and Diagnosis manual to indicate that a FMID must appear in both the target zone and the global zone. -jc- -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kathryn A. Pinto Hi John, Please list the GZONE entry from the global zone of SMP.CICSTS51.GLOBAL.CSI to see if HCTG900 appears in the FMID subentry list. SET BDY(GLOBAL). LIST GZONE. You should get a result like: GLOBALUPGLEVEL = SMP/E 36.59 OPTIONS = GOPT ZONEINDEX = CTG900D DLIB PINTO.RECORD.VSAM.CSI CTG900T TARGET PINTO.RECORD.VSAM.CSI SREL= C150 === FMID= HCTG900 If HCTG900 is not in the FMID list, SMP/E will not consider it during RECEIVE ORDER processing. There are times when the Global zone index list may identify a target zone that is managed by a different global zone. This might be the case for crosszone processing purposes. Since this target zone is managed by a different global zone, the FMIDs installed in this zone may not appear in the Global zone FMID list for the current global zone that is being processed by the RECEIVE ORDER command. If the FMID is not in the GZONE FMID list, the PTFs obtained for these FMIDs cannot be RECEIVEd into this global zone. Therefore, RECEIVE ORDER will not attempt to obtain PTFs for FMIDs that do not appear in the GZONE FMID list. Kathy Pinto SMP/E Development ** 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: Enterprise COBOL v5.1 Implemented?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Well, I suppose it is possible that it is removing the *code* but not the literal. Does COBOL 5.1 have a show me the pseudo-assembler listing option? That would provide a better test IMHO. MAP -jc- ** 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
SMP/E Misleading Error Message
OK, puzzle me this: RECEIVE ORDER( ORDERSERVER(ORDSRVR) CONTENT(ALL) FORTGTZONES(CTG900T) CLIENT(CLNTINFO) ) DELETEPKG . GIM69213S ** A PTF ORDER WAS NOT SENT TO THE SERVER BECAUSE NO PTFS WILL BE APPLICABLE TO THE SPECIFIED ZONES. AT LEAST ONE FUNCTION SYSMOD MUST BE FOUND IN THE SPECIFIED ZONES BEFORE A PTF ORDER CAN BE SENT. GIM20501I RECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. But a browse of the CICS Global CSI shows: NAME TYPE CSI DATA SET CICD510 DLIB SMP.CICSTS51.DLIB.CSI CICT510 TARGET SMP.CICS.TARGET.CSI CTG900D DLIB SMP.CTG900.DLIB.CSI CTG900T TARGET SMP.CTG900.TARGET.CSI GLOBAL GLOBAL SMP.CICSTS51.GLOBAL.CSI ** Bottom of data And within CTG900T: NAME HCTG600 HCTG610 HCTG700 HCTG710 HCTG720 HCTG800 HCTG810 HCTG900 = CICS Transaction Gateway v9.0 Inside HCTG900: Entry Type: SYSMOD Zone Name: CTG900T Entry Name: HCTG900 Zone Type: TARGET Description: CICS Transaction Gateway for z/OS Type: FUNCTION Status: APP FMID: HCTG900 JCLIN Date/Time: 13.302 13:26:34 APP REWORK 2012318 SUP HCTG600 HCTG610 HCTG700 HCTG710 HCTG720 HCTG800 HCTG810 DEL HCTG600 HCTG610 HCTG700 HCTG710 HCTG720 HCTG800 HCTG810 FEATURE ICTGB900 REWORK 2012318 MOD CTGARM CTGBATCH CTGGCONC CTGGTOKC CTGINIT CTGRESBC CTGSACOC CTGSOCOC CTGSTDIC CTGSTLOC CTGSTPIC CTGSTQUC MAC CTGSMFA DATA CTGACCPT CTGALLOC CTGAPPLY CTGDDDEF CTGISMKD CTGIZFS0 CTGIZFS1 CTGMKDIR CTGRECV CTGRECVE CTGSMF CTGSMPSU CTGSTATS CTGSTDAT SAMP CTGASIS CTGCONF CTGCONV CTGENV CTGJOB CTGPROC CTGSMFB CTGSMFR CTGSMFRD CTGSSLPW CTGSTAT1 CTGSTJOB CTGS01A1 CTGS02A1 CTGS03A1 CTGS03A2 CTGS04A1 CTGS05NV CTGS08A1 CTGTESTL CTGTESTR HFS CTGT0194 CTGT0195 CTGT0443 CTGT0444 CTGT0449 CTGT0452 CTGT0453 CTGT0454 CTGT0455 CTGT0456 CTGT0457 CTGT0458 CTGT0459 CTGT0460 CTGT0461 CTGT0462 CTGT0463 CTGT0467 CTGT0469 CTGT0556 CTGT0557 CTGT0562 CTGT0564 CTGT0595 CTGT0596 CTGT0597 CTGT0598 CTGT0599 CTGT0600 CTGT0601 CTGT0602 CTGT0603 CTGT0604 CTGT0605 CTGT0606 CTGT0607 CTGT0608 CTGT0612 CTGT0613 CTGT0616 CTGT0617 CTGT0618 CTGT0619 CTGT0620 CTGT0621 CTGT0622 CTGT0625 CTGT0626 CTGT0639 CTGT0641 CTGT0642 CTGT0643 CTGT0645 CTGT0647 CTGT0652 CTG00196 CTG00197 CTG00199 CTG00200 CTG00201 CTG00204 CTG00470 CTG00471 CTG00472 CTG00473 CTG00474 CTG00475 CTG00476 CTG00477 CTG00478 CTG00479 CTG00480 CTG00481 CTG00482 CTG00483 CTG00485 CTG00486 CTG00487 CTG00488 CTG00489 CTG00490 CTG00491 CTG00522 CTG00524 CTG00526 CTG00528 CTG00530 CTG00533 CTG00535 CTG00537 CTG00540 CTG00552 CTG00553 CTG00554 CTG00555 CTG00560 CTG00565 CTG00567 CTG00568 CTG00570 CTG00584 CTG00586 CTG00587 CTG00588 CTG00589 CTG00590 CTG00591 CTG00592 CTG00594 CTG00623 CTG00624 CTG00628 CTG00629 CTG00638 CTG00644 CTG00651 CTG00653 Note there aren't any PTFs in the CTG900T zone Same bogus error with explicitly specified PTFs: RECEIVE ORDER(
Enterprise COBOL v5.1 Implemented?
Hi, All, Has anyone implemented COBOL 5.1 to the point that you have measured the promised performance improvements in application code over the same code compiled with earlier COBOL compilers? Any hiccups or other glitches or gotchas you'd care to mention with COBOL v5.1? TIA, -jc- ** 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: COBOL 5 compile options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock On 9/26/2014 2:25 PM, Frank Swarbrick wrote: Hey Steve, Your recommendation for defining binary data items and using TRUNC(OPT) does not make the following truncate with COBOL standard rules: I didn't say it did: only TRUNC(STD) is guaranteed to truncate with COBOL standard rules. But the COBOL standard rules are not very useful, I think. Of course, in either case, you still have to know your data, and define your fields appropriately. If I'm going to be moving 123451 to a binary field (or if a calculation could possibly result in such a value), I need to plan for my target to be a fullword, pic s9(9). Programmers still need to be cognizant of the limits of the fields they work with. Too many programmers, in my opinion, understand the boundaries of half word and full word (and double word) field values. ??? Perhaps you meant to write Too few ...? As they say, common sense is not so common. Indeed, in today's world common sense seems to be a (the?) prototypical oxymoron. -jc- ** 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: SIS?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Well, I'll whine. Where the F,,, is Ibmlink SIS now? On my ServiceLink page, it's between Product Cross Reference (PCR) and Service Request and Delivery (SRD), where it has been since Day One of the Webified IBMLink. -jc- ** 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: SIS?
Try www.ibm.com/ibmlink -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 26, 2014 1:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SIS? And, even now I know where to go, I can't see any way to get there starting from any of the support pages from the menus on www.ibm.com, even after signing in. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 26, 2014 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SIS? Thank you. For the bloody life of me, I could not find that page. I guess I will bookmark it, but I have bad luck bookmarking IBM pages :( -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Barkow, Eileen Sent: Friday, September 26, 2014 11:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SIS? https://www-304.ibm.com/ibmlink/servicelink/servicelink.wss?lc=encc =U S -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Gibney, Dave Sent: Friday, September 26, 2014 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SIS? Well, I'll whine. Where the F,,, is Ibmlink SIS now? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto: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 ** 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: Help finding CICS Application Programming Primer
GIYF -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hansen, Dave L - Eagan, MN Dear Group, (Still waiting on the CICS-L Listserv) Back when my hair was a younger color I used to write online CICS programs. I found a sample CICS program shown below. I found the JCL for Batch compilation for COBOL programs documented in the CICS Application Programming Guide (SC34-2844). I was looking for more information on building a test transaction for CICS. From the infocenter I did find The general insurance application under the samples. Also I could find Batch compilation for COBOL programs documented at the infocenter. The CICS TS for z/OS V5 R1 Application Programming Reference (SC34-2845) describes What you need to know to understand this manual on page vii. It lists the CICS Application Programming Primer. Q). Where is the CICS Application Programming Primer? I did not find it in the bibliography. I didn't find a link like that at the infocenter. Just trying to find what information is available and where. Thanks, Dave IDENTIFICATION DIVISION. PROGRAM-ID.SAMCICS. * ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE DIVISION. * 01 WS-INPUT. 05 WS-TRAN-ID PIC X(4). 05 WS-MESSAGE-I PIC X(70). * 01 WS-OUTPUT. 05 WS-TEXT PIC X(8). 05 WS-MESSAGE-O PIC X(70). * 01 WS-MSG-LENGTH PIC S9(4) COMP. * PROCEDURE DIVISION. * MOVE 74TO WS-MSG-LENGTH. * EXEC CICS RECEIVE INTO(WS-INPUT) LENGTH(WS-MSG-LENGTH) END-EXEC. * MOVE WS-MESSAGE-ITO WS-MESSAGE-O. MOVE 'OUTPUT: ' TO WS-TEXT. MOVE 78 TO WS-MSG-LENGTH. * EXEC CICS SEND FROM(WS-OUTPUT) LENGTH(WS-MSG-LENGTH) ERASE END-EXEC. * EXEC CICS RETURN END-EXEC. * GOBACK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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: SLIP IF Trap?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of nitz-...@gmx.net [ snip ] So every sysprog should have enough dump reading skills to at least ascertain when someone is giving them bullsh.. (Now I dream on.) You are not alone. :-) -jc- ** 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: SLIP IF Trap?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson I also recommend MODE=HOME for PVTMOD= In general, you should try to use ASID and/or JOBNAME if you are going to use MODE=HOME. This avoids unnecessary space-switch interrupts (and their processing). Without ASID/JOBNAME, space-switches must be monitored for all address spaces. The IF trap we were given specifies both JOBNAME and MODE=HOME. Its purpose is to enable a SA trap for the same job, which leads to one more question: The SA trap we were given for the same problem specifies RANGE(12R?+1C4,+1C7), but the example in the SLIP doc restates the register in the ending address as well. Is it necessary to restate the register, like RANGE=(12R?+1C4,12R?+1C7)? Or will it work correctly as first cited? (The SA trap also specifies JOBNAME but not MODE=HOME.) The reason for the original IF trap question was that it didn't trip the first time we tried it, despite that there is no possible way for the instruction at the start address specified to be branched around. -jc- ** 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: SLIP IF Trap?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Chase, John [ snip ] The SA trap we were given for the same problem specifies RANGE(12R?+1C4,+1C7), but the example in the SLIP doc restates the register in the ending address as well. Is it necessary to restate the register, like RANGE=(12R?+1C4,12R?+1C7)? Or will it work correctly as first cited? [ snip ] Never mind; I found the correct page in the manual. Essentially, either way will work. -jc- ** 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
SLIP IF Trap?
Hi, All, IBM Lvl 2 has given us a SLIP IF trap to set for a problem we currently have open, but so far the trap has not triggered. The address range to monitor was specified as . . .,PVTMOD=(modname,C4),. . . . The instruction immediately preceding that offset is a STORE, so the instruction at offset C4 necessarily gets executed (unless the STORE causes an interrupt, like 0C4) but the IF trap never trips. SLIP doc says: PVTMOD=(name[,start[, end]]) And If you specify only start, the range consists of that single address. As you can see above, the spec we were given includes only the start address. Is that sufficient for an IF SLIP? Or do we need to specify a range equal to the size of the instruction we want to trap? TIA, -jc- ** 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: Emptiness (was: z/OS FTP client behavior)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour J.) In 7227021730034872.wa.paulgboulderaim@listserv.ua.edu, on 09/16/2014 at 06:20 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: But empirically I discover: o If the first catenand is an empty instream data set, the remaining catenands are transmitted regardless. o If the first catenand is an empty UNIX file, the remaining catenands are not transmitted. o Otherwise, catenands following an empty catenand interior are transmitted. Can anyone supply a rationale for these behaviors? C2H5OH? C2H5COOH? -jc- ** 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: MVS
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane Ginnane On Tue, 16 Sep 2014 07:25:10 -0600, Paul Gilmartin wrote: Can't we forget MVS (that's *so* 20th Century), and talk instead about z/OS, which is the topic of the Redbook (see URL)? Nope. Up to, and including, the (new, you-beaut) 1.12 Info Centre, it was simply MVS for the important manuals. Now I see z/OS MVS - including 2.1. Some habits seem to die hard. z/OS is a package. MVS is just an operating system that's included in z/OS. -jc- ** 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: Bizarre maybe-FTP problem
Been using Bluezone FTP for more than a decade, and have never encountered that sort of error. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Monday, September 15, 2014 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bizarre maybe-FTP problem Actually it wasn't me doing the upload, and now I'm told BlueZone was the emulator used, using FTP. So maybe this is a BZ buglet. From: Phil Smith Sent: Monday, September 15, 2014 12:52 PM To: ibm-m...@bama.ua.edu Subject: Bizarre maybe-FTP problem After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. Re-FTPing fixed it. But I dislike a mystery like this, especially on a Monday... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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: SW XCEL and IBMLINK
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Our shop was without a Software Xcel contract for a few months due to a contract mix-up. As of this morning, we have it back. My question is what changed in the interim? I used to be able to initiate TRACK, SIS, SR/PMR, etc. all from one webpage. I no longer see that webpage when I login. Any ideas/suggestions as to what happened? Is there a new webpage I am not aware of? When mine breaks, I just type in www.ibm.com/ibmlink and it redirects either to the sign-in page or the ServiceLink page, depending on the cookie. -jc- ** 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: Is there a CPU cost to using key9 storage while running with key8
-Original Message- From: IBM Mainframe Discussion List On Behalf Of David Price What hardware are you on? I ask because a z196 has some high CPU costs for certain PSW Key-related instructions. For example, SPKA (Set PSW Key from Address) on a z196 shows up in CICS CPU figures because it stalls the pipeline when changing PSW keys between key 8 and key 9 -- or even when it doesn't change keys e.g. it is just 'going' from key 8 to key 8! SPKA may be executed in CICS more than you think (consider User Exits -- GLUEs and TRUEs -- some of which may have been inserted by your monitoring software). An interesting observation. I'd have thought that CICS (in particular), in an early stage of startup when it runs authorized, would set the Storage-Protection-Override Control (bit 39 of CR0) if STGPROT=YES was specified as a DFHSIT parm. See z/Architecture Principles of Operation, 10th Edition, at page 3-12 for details of Storage-Protection-Override Control. This would seem to obviate any need for CICS, post-initialization when running unauthorized, to issue SPKA or similar key-related instructions. -jc- ** 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: Is there a CPU cost to using key9 storage while running with key8
Sorry: ... key-related instructions simply to access key9 storage. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chase, John Sent: Friday, August 29, 2014 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a CPU cost to using key9 storage while running with key8 -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Price What hardware are you on? I ask because a z196 has some high CPU costs for certain PSW Key-related instructions. For example, SPKA (Set PSW Key from Address) on a z196 shows up in CICS CPU figures because it stalls the pipeline when changing PSW keys between key 8 and key 9 -- or even when it doesn't change keys e.g. it is just 'going' from key 8 to key 8! SPKA may be executed in CICS more than you think (consider User Exits -- GLUEs and TRUEs -- some of which may have been inserted by your monitoring software). An interesting observation. I'd have thought that CICS (in particular), in an early stage of startup when it runs authorized, would set the Storage-Protection-Override Control (bit 39 of CR0) if STGPROT=YES was specified as a DFHSIT parm. See z/Architecture Principles of Operation, 10th Edition, at page 3-12 for details of Storage-Protection-Override Control. This would seem to obviate any need for CICS, post-initialization when running unauthorized, to issue SPKA or similar key-related instructions. -jc- ** 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible method to post large files, for example and such
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jantje. [ snip ] My company (and I guess many others) blocks access to all such file-sharing services, unfortunately. Maybe you could consider using attachments to the posts? I believe the listserv is configured to discard attachments before relaying posts. -jc- ** 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: revisiting the documentation dilemma
Not a flame, but I've finally gotten used to the InfoCenter delivery. But soon I'll be forced to accustom to the Knowledge Center delivery. The presentation is somewhat like the InfoCenter, but finding stuff initially is a bit more challenging. For example, to find the doc for the COBOL compilers, one must look under the Rational navigation entry. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, August 19, 2014 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: revisiting the documentation dilemma I haven't read the rest of the thread yet. Let the flames possibly roar, but Softcopy Librarian still worked for me to download z/OS 2.1. Unforutantely, is only .pdf's. But it did bring me shelves and the Softcopy Reader: Shelf Organizer allows me to find what I want when I need it. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 19, 2014 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: revisiting the documentation dilemma Correct, DVDs are no longer being produced. I forget what version of z/OS they did that. z/OS V1.13 may be the last - but I am not sure. I would recommend getting MOZILLA browser and install the addin - DOWNTHEMALL. It is very fast to down load anything from the web. I use it to download all of the IBM Manuals I want. I think I downloaded 678 PDFs from IBM in about 10 mins maybe 20 mins. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Pommier, Rex Sent: Tuesday, August 19, 2014 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: revisiting the documentation dilemma Hi list, I've been meandering through the archives and saw several threads regarding documentation changes that IBM has been implementing, with knowledge centers et al. So my question is a rather basic one. We just upgraded to 1.13 a couple months ago. Do the documentation DVDs no longer exist even in softcopy form? On my old 1.11 system I was able to download and install a DVD image and have the documentation library locally on my PC. If I want to have a similar functionality with my 1.13 documentation do I need to download each manual I want individually and build my own library? I spent a couple hours yesterday on IBM's web site(s) and it appears that this is my only option. Could somebody please confirm whether this is correct or if there is someplace where I could do a mass download of books please point me to it. Thanks, Rex -- 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 ** 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: more about True North integrated circuits
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing On 08/16/2014 06:14 AM, Mike Stayton wrote: and also http://www.research.ibm.com/articles/brain-chip.shtml Mike Stayton An interesting development, but if technology ever progresses to the point where we remotely approach the cognitive power of the human brain we would need to exercise EXTREME caution, as humans can learn and be certain of so many things that simply aren't true including mutually impossible facts, be blind to their own ignorance, come to irrational, destructive conclusions, and have mental breakdowns. There is a reason that the computers that we rely on have been designed around deterministic architectures. Science fiction has repeatedly dealt with the dangers of placing cognitive machines in control. I particularly remember one original Star Trek episode (The Ultimate Computer) where such a cognitive computer (M-5) went berserk because its designer patterned its memory engrams on his own and he himself turned out to be mentally unstable. A similar virus affected the HAL 9000 computer in Clarke's _2001: A Space Odyssey_. Just image the extreme damage potential of an ultra-fast, ultra-efficient cognitive machine in control of some critical process or decisions if it were patterned on the memory engrams of a Sarah Palin. ... or Adolf Hitler, or Josef Stalin, or Barack Obama, or Isaac Newton, or Albert Einstein, or Thomas Jefferson, or Bobby Fischer, or pick your poison. -jc- ** 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
Default TSO Region Size?
Hi, All, Many of our TSO users have a 4MB default TSO Region size (Size === 4096 field on the logon panel), which nowadays is a relic of the 1970s, pretty much unusable for many utilities like Fault Analyzer, etc. I'm looking for suggestions on what should be a reasonable and realistic default Size value for today's world. From past experiments I've found that 96M is about the minimum for anybody who wants to run Java programs (indeed, I cannot run java -version in less than 80M), so I'm leaning toward a default of 128M and a MAXSIZE of 2G in the RACF TSO segment. Comments? Suggestions? Caveats? TIA, -jc- ** 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: Happy New Year
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht [ snip ] Sigh... I can't win or lose... ;-) I could just toss up a coin (rare collectable or damaged pick-up): Head - you win. Tail - I lose. ;-) You can't win. You can't break even. You can't even quit the game. (Ginsberg's Theorem) -jc- ** 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: INITILAIZE COST
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert A. Rosenberg At 20:01 -0700 on 08/11/2014, Duffy Nightingale, SS wrote about Re: INITILAIZE COST: Heavy emphasis on that last sentence. Just had a customer who didn't keep track of the number of entries in his COBOL table while adding new ones. Ended up adding entries way beyond the end of his table leading to altering the fields following the table to wrong values leading to very strange scary looking dumps that seemed to point to big problems in unsupported code! But, nope, simple, his table got bigger than the definition. I thought the code spotted an attempt to go beyond the end of the table by exceeding the OCCURS value or am I thinking of PL/I which would catch this error? Depends on compile-time option SSRANGE / NOSSRANGE. http://www-01.ibm.com/support/knowledgecenter/SS6SG3_5.1.0/com.ibm.cobol511.ent.doc/custom/igycch257.html?lang=en -jc- ** 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: IBM Announcements
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Can anyone post a good link for IBM Announcements? I have been through a couple of PCs in the last four months and have lost admin privileges (and FIREFOX) in the process. For now, I only have IE and none of my old favorites. One of those was the requested link. Help anyone? :) http://www-01.ibm.com/common/ssi/index.wss?request_locale=en -jc- ** 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: Rational Development and Test (RDT) aka z/OS on a PC
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) This behavior should be APAR-able, IMO. -jc- ** 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
HIPER PTF SUP'd by non-HIPER?
It seems logical to me that a PTF which supersedes a HIPER PTF should itself be ASSIGNed the HIPER SOURCEID flag, but in one current instance (UI19849, which supersedes UI18382 whose APAR is flagged HIPER and DATALOSS) the superseding PTF is not flagged HIPER. Is that perhaps an oversight by the team that created UI19849? It is presumed that the fix in UI18382 is present in UI19849. TIA, -jc- ** 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: Rational Development and Test (RDT) aka z/OS on a PC
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Norbert Friemel On Mon, 11 Aug 2014 09:24:00 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) The required parameters are in DFSMS Using Data Sets: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.5 The following parameters are both required to allocate a PDSE: - Specify DIR space (greater than zero) or DSORG=PO (partitioned organization) in the JCL, in the DYNALLOC macro, in the data class, or in the TSO ALLOCATE command. - Specify DSNTYPE=LIBRARY in the JCL, in the data class, in the TSO ALLOCATE command, using the LIKE keyword, or as the installation default specified in SYS1.PARMLIB. Hmmm I guess that makes the behavior non-APAR-able after all. There's a Guideline that says the allocation fails without DIR space: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.4 That's not the case in z/OS 1.13 Or not. -jc- ** 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: LE APAR PM99349
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert A. Rosenberg At 09:30 -0400 on 08/03/2014, Shmuel Metz (Seymour J.) wrote about Re: LE APAR PM99349: In 2830304844335286.wa.ibmmaintpg.com...@listserv.ua.edu, on 08/03/2014 at 06:52 AM, Shane Ginnane ibm-m...@tpg.com.au said: Security through obfuscation has never worked. Might appear to for a while, As long as it works long enough to develop a fix and get it installed, it's worth doing. That assumes that once a problem is spotted that the creation of the fix is started and that the fix actually gets distributed and installed. Too many times, since the problem description is not revealed the creation of a fix is not regarded as necessary. IOW: By not saying what the problem is (or even that there is a problem) there is a tendency to not see a need to actually fix it. Best I can tell, the SECINT SOURCEID is available only via the SECINT.ASSIGNS file, available only through the Security Portal. I've never seen a SECINT PTF in any RECEIVE ORDER with CONTENT(RECOMMENDED) (but that doesn't mean there aren't any). Thus, it appears that one is expected to subscribe to the Security Portal and to its notification process to learn when a security/integrity problem has been identified and fixed. -jc- ** 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
LE APAR PM99349
Hi, All, One newly-available PTF for LE, UI18450, fixes APAR PM99349, but a search for PM99349 on IBMLink fails with a not found error. Am I to ass.u.me that it's a security / integrity APAR and just apply the PTF? TIA, -jc- ** 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: LE APAR PM99349
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Dennis Trojak Yes it is a security/integrity APAR. If you subscribe to the Security Portal you can review it. Description: This issue may pertain to users of Language Environment for z/OS with FMID HLE7770, HLE7780 and HLE7790. Thanks. I had not noticed those details before; normally just download the latest SECINT assigns and holddata. -jc- ** 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
RECEIVE ORDER server problems?
Anybody else having long delay times on SMP/E RECEIVE ORDER? I have a job for one PTF that's been waiting 30 minutes so far: GIM693ISMP/E HAS BEEN WAITING 15 MINUTES FOR ORDER ORDn. SMP/E WILL WAIT A MAXIMUM OF 120 MINUTES. GIM693ISMP/E HAS BEEN WAITING 30 MINUTES FOR ORDER ORDn. SMP/E WILL WAIT A MAXIMUM OF 120 MINUTES. -jc- ** 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
