Re: Flash Cards on MVS
Ed, If you are speaking of the new zEC12, with the Flash Express option, A couple things come to mind, but I have no direct knowledge because we don't have Flash Express. - It is a feature code of the zEC12. So only IBM parts, no OEM - Since it is a feature code of the zEC12, it would be covered under the same maintenance as any other part of the processor. - requires z/OS 1.13+maint to exploit There is fault tolerance built in, and replacement can be done concurrently. At this time, I am pretty sure that the only exploiters are PAGING and Dump Services. I hear of other plans, but don't know if those have been implemented yet. Here is a link to the redbook zEC12 Technical Guide(see Appendix C). It pretty much appears to answer all your questions: http://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf _ 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 Ed Gould Sent: Tuesday, March 05, 2013 4:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Flash Cards on MVS I got one civil reply offline. The uncivil one from eastern Europe is not worth the courtesy of a reply. I will attempt to rephrase the question(s) below. I have a customer that is looking at the most current IBM system. I do not have contact with anyone that has the most current IBM system, so I am asking the group nicely, several questions. These are more operations (IMO) issues questions and figured the group would have the knowledge to reply. I did google and really didn't come up with any answers pertaining to IBM's MF implementation of Flash cards. Has anyone have experience with implementing IBM's (NOT STK or OEM) flash cards. What is the typical longevity of IBM's Flash cards and do you keep a few around just in case or ? IF/when they reach their end of life do you toss them return them to IBM etc... (how many spares do you keep on hand) How does your company handle replacements ie operations (or another group) handles the insertion and taking out of "old" cards. IOW operations side of the of the handling. Thanks in advance for any information. -- 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
Retrieving output submitted by surrogates
From: Robin Atwood Sent: 06 March 2013 21:12 To: 'IBM-MAIN@LISTSERV.UA.EDU' Subject: Retrieving output submitted by surrogates This is a rather arcane topic but hopefully one of you out there might have some insight. I am working on a problem where a customer uses our application to submit jobs to JES2, and then, when the output is available, the application reads it from the spool and sends it back to the customer. This uses the SAPI (function 79) JES2 call and has worked well for years. Now a customer wants to use a surrogate userid to submit the jobs which run under various different userids. Submission works fine, as long as the RACF rules are defined, but when I try to pick up the output, I get RC=4, nothing found. When constructing the SSS2 I specify the jobid since I know that from the submit stage. Crucially I set: MVI SSS2SEL2,SSS2SCRE MVC SSS2CREA,USERID where the userid is the surrogate. According to the TSO/E guide: "With RACF installed, users can be defined to the RACF SURROGAT class. Jobs submitted by surrogate users can be cancelled and/or viewed by surrogate users without knowing the user's password" Which implies what I am doing ought to work. If I clear SSS2SEL2, on our test system the call works but on the customer's (much more security) it still fails. SSS2CREA is defined as the "owning userid", so is there a different way of specifying a surrogate? Or is it necessary to define JESSPOOL rules to give the surrogate read rights to the output? Thanks for any illumination! -- Robin Atwood -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Vary off path
Is there an easy way to VARY off a path? Looking at the commands manual it looks like you have to vary off the path to each device. In z/VM we can vary off a path to every device. VARY OFF PATH D3 TO ALL VARY OFF CHPID D3 I want to vary off the path and the chpid logically, I don't want to physically vary off the chpid until users of the other LPARs have also logically varied off their paths and chpid. -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
You can specify a range of devices, does this help? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Wednesday, March 06, 2013 14:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Vary off path Is there an easy way to VARY off a path? Looking at the commands manual it looks like you have to vary off the path to each device. In z/VM we can vary off a path to every device. VARY OFF PATH D3 TO ALL VARY OFF CHPID D3 I want to vary off the path and the chpid logically, I don't want to physically vary off the chpid until users of the other LPARs have also logically varied off their paths and chpid. -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
Not really, I have 10 control units with 4 CPHIDs, I need to vary off 2 of the CHPID. That's a lot of ranges. On Wed, Mar 6, 2013 at 8:32 AM, Vernooij, CP - SPLXM wrote: > You can specify a range of devices, does this help? > > Kees. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Pace > Sent: Wednesday, March 06, 2013 14:31 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Vary off path > > Is there an easy way to VARY off a path? Looking at the commands manual > it looks like you have to vary off the path to each device. > > In z/VM we can vary off a path to every device. > VARY OFF PATH D3 TO ALL > VARY OFF CHPID D3 > > I want to vary off the path and the chpid logically, I don't want to > physically vary off the chpid until users of the other LPARs have also > logically varied off their paths and chpid. > > > > -- > The postings on this site are my own and don't necessarily represent > Mainline's positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and may > be unlawful. If you have received this e-mail by error, please notify the > sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
>Thank you for that link. I was not aware that IBM made closed APAR >documentation available to the public. > >I still think it is wrong for two major machine upgrades to have occurred and >yet none of the HLASM manuals was updated. > HLASM hasn't really changed. It would be nice if the page at http://www.vm.ibm.com/devpages/jelliott/cmosproc.html would be updated to include the HLASM opcode table that is appropriate for each model. It would also be nice if the HLASM manuals would contain a link to a web page with the current information about what op code tables are recognized, the APAR that provided the support and the processors that introduced the new instructions. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
Paul Gilmartin wrote: I had understood that, new with MVS/XA, HLASM was not "'given away' as a part of the operating system", but a separately priced prerequisite. Has that changed, or was I mistaken? The 1980's were a long time ago (smile), and I'm not going to look up the history of whether we ever charged for HLASM and its predecessors. Today, though, HLASM is a nonexclusive base element of z/OS, which is to say that: - It is separately orderable (as HLASM for z/OS and z/VM and z/VSE V1R6, 5696-234). - It is included as part of z/OS at no additional charge. This has been true since OS/390 was introduced. The full list of current z/OS elements and features and which are priced can be found in z/OS Planning for Installation, in topic 1.1.1, "List of base elements and optional features," which you can find here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/e0z2b1c3/1.1.1?SHELF=all13be9&DT=20120919155103 -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieving output submitted by surrogates
Robin Atwod wrote: >but when I try to pick up the output, I get RC=4, nothing found. From where? SYSLOG or result of the SAPI macro(s) usage? >MVI SSS2SEL2,SSS2SCRE >MVC SSS2CREA,USERID Geez, it took me some time to get the definition of SSS2SEL2 in Bookmanager... ;-) >Which implies what I am doing ought to work. If I clear SSS2SEL2, on our test >system the call works but on the customer's (much more security) it still >fails. With same result as above (RC=4) or do you get another results/messages? >Or is it necessary to define JESSPOOL rules to give the surrogate read rights >to the output? Depending on your JESSPOOL profiles, you may need to give SURROGATE id access to the output. Alternatively try $T DEBUG,SECURITY=YES to see what JES2 says when your id is trying to access it. Or have that id access that job via SDSF, perhaps you can see some ICH408* message(s). HTH! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
Mark Pace wrote: >Not really, I have 10 control units with 4 CPHIDs, I need to vary off 2 of >the CHPID. That's a lot of ranges. What about CF CHP(xx),OFFLINE? Groete / Greetings Elardus Engelbrecht PS: It is a lng time ago I did that command... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
The H Assembler at least was once charged for. The cost was always nominal, US$150 per month is what I remember, but I should not wish to be hanged if that number is wrong. It was widely used because it did SYSGENs, NCPGENs, and the like very much faster than the F Assembler. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
Mwah, 20 ranges in a command script is doable. But, why don't you just CONFIG the 2 CHPIDs OFF per LPAR? z/OS will handle this without problems. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Wednesday, March 06, 2013 14:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Vary off path Not really, I have 10 control units with 4 CPHIDs, I need to vary off 2 of the CHPID. That's a lot of ranges. On Wed, Mar 6, 2013 at 8:32 AM, Vernooij, CP - SPLXM wrote: > You can specify a range of devices, does this help? > > Kees. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Pace > Sent: Wednesday, March 06, 2013 14:31 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Vary off path > > Is there an easy way to VARY off a path? Looking at the commands > manual it looks like you have to vary off the path to each device. > > In z/VM we can vary off a path to every device. > VARY OFF PATH D3 TO ALL > VARY OFF CHPID D3 > > I want to vary off the path and the chpid logically, I don't want to > physically vary off the chpid until users of the other LPARs have also > logically varied off their paths and chpid. > > > > -- > The postings on this site are my own and don't necessarily represent > Mainline's positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
As I understand it the CF command will vary the physical CHPID offline to all LPARs, not just logically to the z/OS LPAR. I could be wrong about that. If it does do it physically I can wait until the other LPARs have varied their paths offline and then I'll use the CF command. On Wed, Mar 6, 2013 at 9:01 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Mark Pace wrote: > > >Not really, I have 10 control units with 4 CPHIDs, I need to vary off 2 of > >the CHPID. That's a lot of ranges. > > What about CF CHP(xx),OFFLINE? > > Groete / Greetings > Elardus Engelbrecht > > PS: It is a lng time ago I did that command... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
Why is this discussion taking place here ratner than on ASSEMBLER-LIST? On Wed, 6 Mar 2013 09:02:31 -0500, John Gilmore wrote: >The H Assembler at least was once charged for. > >The cost was always nominal, US$150 per month is what I remember, but >I should not wish to be hanged if that number is wrong. It was widely > I should not wish you to be hanged even if that number happens to be correct. >used because it did SYSGENs, NCPGENs, and the like very much faster >than the F Assembler. > F Assembler? Assembler VS? Assembler VS was known as IFOX00, IIRC. I once had a manual that explained the differences. It got left behind in a move. On Wed, 6 Mar 2013 07:46:08 -0600, Tom Marchant wrote: > >HLASM hasn't really changed. It would be nice if the page at >http://www.vm.ibm.com/devpages/jelliott/cmosproc.html >would be updated to include the HLASM opcode table that is >appropriate for each model. It would also be nice if the HLASM >manuals would contain a link to a web page with the current >information about what op code tables are recognized, the APAR >that provided the support and the processors that introduced >the new instructions. > Irony noted? That would require, at least once, the doc update that IBM appears to be trying to avoid. There may be a way out. The summary output from DFSORT, for example, includes such a link. HLASM might be updated by APAR to show a similar link in its summary output; refreshed by APAR should it happen to rot. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
The CF command as issued as a z/OS command only configures it off to that LPAR. If you go to the HMC single object operations, and do it there, it will take it offline to all images. _ 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 Mark Pace Sent: Wednesday, March 06, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Vary off path As I understand it the CF command will vary the physical CHPID offline to all LPARs, not just logically to the z/OS LPAR. I could be wrong about that. If it does do it physically I can wait until the other LPARs have varied their paths offline and then I'll use the CF command. On Wed, Mar 6, 2013 at 9:01 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Mark Pace wrote: > > >Not really, I have 10 control units with 4 CPHIDs, I need to vary off > >2 of the CHPID. That's a lot of ranges. > > What about CF CHP(xx),OFFLINE? > > Groete / Greetings > Elardus Engelbrecht > > PS: It is a lng time ago I did that command... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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
Re: Vary off path
W dniu 2013-03-06 15:17, Mark Pace pisze: As I understand it the CF command will vary the physical CHPID offline to all LPARs, not just logically to the z/OS LPAR. I could be wrong about that. If it does do it physically I can wait until the other LPARs have varied their paths offline and then I'll use the CF command. No. MVS command CF CHP(xx),OFFLINE will offline the chpid for given LPAR only. If you want to make offline all the paths, then it's much easier to offline the chpid. BTW: you can offline the channel from Support Element, then you can do it for all LPARs at the time if you want, but it is unrecommended for live systems! -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
Thanks everyone. The CF command was what I needed. On Wed, Mar 6, 2013 at 9:25 AM, Jousma, David wrote: > The CF command as issued as a z/OS command only configures it off to that > LPAR. If you go to the HMC single object operations, and do it there, it > will take it offline to all images. > > _ > 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 Mark Pace > Sent: Wednesday, March 06, 2013 9:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Vary off path > > As I understand it the CF command will vary the physical CHPID offline to > all LPARs, not just logically to the z/OS LPAR. I could be wrong about > that. If it does do it physically I can wait until the other LPARs have > varied their paths offline and then I'll use the CF command. > > > On Wed, Mar 6, 2013 at 9:01 AM, Elardus Engelbrecht < > elardus.engelbre...@sita.co.za> wrote: > > > Mark Pace wrote: > > > > >Not really, I have 10 control units with 4 CPHIDs, I need to vary off > > >2 of the CHPID. That's a lot of ranges. > > > > What about CF CHP(xx),OFFLINE? > > > > Groete / Greetings > > Elardus Engelbrecht > > > > PS: It is a lng time ago I did that command... > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > The postings on this site are my own and don't necessarily represent > Mainline's positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > 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 > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
On Wed, 6 Mar 2013 07:46:08 -0600, Tom Marchant wrote: >HLASM hasn't really changed. It would be nice if the page at >http://www.vm.ibm.com/devpages/jelliott/cmosproc.html >would be updated to include the HLASM opcode table that is >appropriate for each model. It would also be nice if the HLASM >manuals would contain a link to a web page with the current >information about what op code tables are recognized, the APAR >that provided the support and the processors that introduced >the new instructions. > >-- >Tom Marchant Tom: As the owner of the referenced page, this is an interesting request. I do link to the Principles of Operation publications which do include all the opcodes of course, but the summary of changes does not list the opcodes, just the functions. This would be IMHO a welcome addition to those publications. I will add the HLASM APARs to the page today, for the zArchitecture machines. Thanks for the suggestion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
On Wed, 6 Mar 2013 08:20:20 -0600, Paul Gilmartin wrote: >Why is this discussion taking place here ratner than on >ASSEMBLER-LIST? Because the OP asked his question on this list. Does it make sense to move it to another list? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
The usual suspects would be responding even if this thread were moved to the assembler list. The only effect at this late point in time would be to fracture the archives. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Flash Cards on MVS
I guess I could expand on this some more. zEC12 is the only built-in solution I am aware of. Don't think there is anything that will co-exist with it in the market, now or probably ever. That being said, I am aware that DASD vendors market solid-state disk, which present to the operating system as traditional DASD. That is not new technology. Not sure if you were asking that, or not. However, the answers to that should be the same too, covered under maintenance agreement. _ 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 Jousma, David Sent: Wednesday, March 06, 2013 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Flash Cards on MVS Ed, If you are speaking of the new zEC12, with the Flash Express option, A couple things come to mind, but I have no direct knowledge because we don't have Flash Express. - It is a feature code of the zEC12. So only IBM parts, no OEM - Since it is a feature code of the zEC12, it would be covered under the same maintenance as any other part of the processor. - requires z/OS 1.13+maint to exploit There is fault tolerance built in, and replacement can be done concurrently. At this time, I am pretty sure that the only exploiters are PAGING and Dump Services. I hear of other plans, but don't know if those have been implemented yet. Here is a link to the redbook zEC12 Technical Guide(see Appendix C). It pretty much appears to answer all your questions: http://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf _ 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 Ed Gould Sent: Tuesday, March 05, 2013 4:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Flash Cards on MVS I got one civil reply offline. The uncivil one from eastern Europe is not worth the courtesy of a reply. I will attempt to rephrase the question(s) below. I have a customer that is looking at the most current IBM system. I do not have contact with anyone that has the most current IBM system, so I am asking the group nicely, several questions. These are more operations (IMO) issues questions and figured the group would have the knowledge to reply. I did google and really didn't come up with any answers pertaining to IBM's MF implementation of Flash cards. Has anyone have experience with implementing IBM's (NOT STK or OEM) flash cards. What is the typical longevity of IBM's Flash cards and do you keep a few around just in case or ? IF/when they reach their end of life do you toss them return them to IBM etc... (how many spares do you keep on hand) How does your company handle replacements ie operations (or another group) handles the insertion and taking out of "old" cards. IOW operations side of the of the handling. Thanks in advance for any information. -- 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 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. --
Re: Where current HLASM doc?
Thanks for that PSP link, now bookmarked. Once again I am proven incorrect, but that's why I keep reading this list. I'm also not sure access to the PSP buckets will help to enlighten me very much, but it is interesting nonetheless. Peter P.S. - Also thanks for the button link! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, March 05, 2013 5:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where current HLASM doc? On 5 March 2013 17:03, Farley, Peter x23353 wrote: > I don't have access to PSP buckets. You may well have. Try http://www14.software.ibm.com/webapp/set2/psearch/search?domain=psp, and use HLASM as the search argument. But I'm not sure how useful the results are. > I'm an application guy, not a systems guy. I write code that exercises the > operating system for the system programmers' benefit. http://www.mxg.com/thebuttonman/html/button680.htm Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieving output submitted by surrogates
On Wed, 6 Mar 2013 21:14:13 +0800, Robin Atwod wrote: >This is a rather arcane topic but hopefully one of you out there might have >some insight. I am working on a problem where a customer uses our >application to submit jobs to JES2, and then, when the output is available, >the application reads it from the spool and sends it back to the customer. >This uses the SAPI (function 79) JES2 call and has worked well for years. >Now a customer wants to use a surrogate userid to submit the jobs which run >under various different userids. Submission works fine, as long as the RACF >rules are defined, but when I try to pick up the output, I get RC=4, nothing >found. First, just to make sure we're using the same terminology, there are two important user IDs to consider here: (a) the execution user, specified in your case via USER= on the JOB statement, and (b) the user who submits the job (which is the surrogate user). JESSPOOL security processing will allow the execution user to view/retrieve output without any profiles defined. However, the submitter (surrogate user) does not have authority to the job output unless a JESSPOOL profile allows it. That will also affect the SAPI processing, but I really don't know what kind of return codes you'd get. You might be able to see some JES2 error messages if you first issue "$T DEBUG,SECURITY=YES" if the SAPI function works like normal spool access/selection does, but I"m not sure. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
On Wed, 6 Mar 2013 09:15:39 -0600, Jim Elliott, IBM wrote: >On Wed, 6 Mar 2013 07:46:08 -0600, Tom Marchant wrote: > >>It would be nice if the page at >>http://www.vm.ibm.com/devpages/jelliott/cmosproc.html >>would be updated to include the HLASM opcode table that is >>appropriate for each model. > >As the owner of the referenced page, this is an interesting request >I will add the HLASM APARs to the page today, for the zArchitecture >machines. Thanks for the suggestion. Thanks, Jim. The APAR that provides HLASM support would be useful. The name of the opcode table that first included the instructions for that model perhaps even more so. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Retirement
About a month ago I said I might quietly drop off the list. I'm still here, enjoying my 3rd week of retirement. I do find that I read less posts, especially if I don't sign on till noon or later and have 30 or 40 in my inbox. Since I probably won't work anymore, at least as a systems programmer, the more technical discussions are less interesting than they used to be. I like retirement so far. I usually don't sent my alarm. There are some drawbacks though. Today I had to go out and shovel snow for an hour or so. When I lived in Dubuque during the week, I didn't have to worry about that, and my wife had enough shoveled to make the job a lot less when I came home on the weekend. Good thing I have a big snowblower. Eric Bielefeld Retired Systems Programmer Milwaukee, Wisconsin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retirement
Theorem: Once a Marine always a Marine. Corollary: Once a sysprog always a sysprog. Good Luck and enjoy yourself :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Eric Bielefeld Sent: Wednesday, March 06, 2013 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Retirement About a month ago I said I might quietly drop off the list. I'm still here, enjoying my 3rd week of retirement. I do find that I read less posts, especially if I don't sign on till noon or later and have 30 or 40 in my inbox. Since I probably won't work anymore, at least as a systems programmer, the more technical discussions are less interesting than they used to be. I like retirement so far. I usually don't sent my alarm. There are some drawbacks though. Today I had to go out and shovel snow for an hour or so. When I lived in Dubuque during the week, I didn't have to worry about that, and my wife had enough shoveled to make the job a lot less when I came home on the weekend. Good thing I have a big snowblower. Eric Bielefeld Retired Systems Programmer Milwaukee, Wisconsin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
IIRC, it is strongly advised to never use the HMC single object operations to vary a CHP when the related LPARs have operating systems running in them. Alas, I wish that all operating systems were designed/required to gracefully handle the HMC varying resources on and off line. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: Wednesday, March 06, 2013 9:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Vary off path > > The CF command as issued as a z/OS command only configures it off to that > LPAR. If you go to the HMC single object operations, and do it there, it will > take it offline to all images. > > __ > ___ > 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 Mark Pace > Sent: Wednesday, March 06, 2013 9:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Vary off path > > As I understand it the CF command will vary the physical CHPID offline to all > LPARs, not just logically to the z/OS LPAR. I could be wrong about that. If it > does do it physically I can wait until the other LPARs have varied their paths > offline and then I'll use the CF command. > > > On Wed, Mar 6, 2013 at 9:01 AM, Elardus Engelbrecht < > elardus.engelbre...@sita.co.za> wrote: > > > Mark Pace wrote: > > > > >Not really, I have 10 control units with 4 CPHIDs, I need to vary off > > >2 of the CHPID. That's a lot of ranges. > > > > What about CF CHP(xx),OFFLINE? > > > > Groete / Greetings > > Elardus Engelbrecht > > > > PS: It is a lng time ago I did that command... > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > The postings on this site are my own and don't necessarily represent > Mainline's positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > 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
Re: TN3270 I/P Access fails after IPL
Check that LP #'s are correct for each LPAR. Looks similar to this: http://bit.listserv.ibm-main.narkive.com/NJ8Hqmgn/osa -- Donald J. dona...@4email.net On Tue, Mar 5, 2013, at 01:43 PM, Tom Trainor wrote: > I have four(4) LPARS on a single CHPID for an Ethernet CHPID defined as > OSE (non-QDIO) in the IOCDS. > > Here is the OAT entry for ONE (1) of the LPARS: (I/P address removed for > security reasons) > > 04(3404)* passthru 00 no nnn.nnn.nnn.nnn SIUALL > > Each of the LPARS has the I/P defined IN the OAT file AND in the TCPPROF > file under HOME: > > HOME >nnn.nnn.nnn.nnn ETHn > > PROBLEM: When I IPL any ONE (1) LPAR, all LPARS lose I/P connectivity > until I pop the ethernet cable in and out of the Ethernet OSA CARD > (OSA-Express OSA card on a 2066, i.e. z800) whereupon each of the four > (4) I/P instances recovers their connection. > > Any IDEAS? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Donald J. dona...@4email.net -- http://www.fastmail.fm - A no graphics, no pop-ups email service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vary off path
Don Williams wrote: >IIRC, it is strongly advised to never use the HMC single object operations to >vary a CHP when the related LPARs have operating systems running in them. Agreed. One of our operators did something to a Production LPAR instead to a Sandbox LPAR from HMC. Lots of Ouch-ouch-ouch and IPL... >Alas, I wish that all operating systems were designed/required to gracefully >handle the HMC varying resources on and off line. Including boxed devices? I think z/OS should reply with this (but it is just me): REPLY 00,Reply with G, N, W, Y or N: 1. G - Go ahead, make my day. 2. N - No, do not continue. 3. W - Go ahead, but wait for me, I want to check out that resource XYZ. 4. Y/N - Are your hardware + software fees and licenses fully paid up? ;-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
Re: Where current HLASM doc?
And you could get the SLAC mods for H Assembler which made it MUCH more usable. Thanks, Greg. :-) In fact many of the feature upgrades from H Assembler to HLASM came from the SLAC mods descriptions as we wrote SHARE requirements for those features. Lloyd - Original Message From: John Gilmore To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, March 6, 2013 9:02:36 AM Subject: Re: Where current HLASM doc? The H Assembler at least was once charged for. The cost was always nominal, US$150 per month is what I remember, but I should not wish to be hanged if that number is wrong. It was widely used because it did SYSGENs, NCPGENs, and the like very much faster than the F Assembler. John Gilmore, Ashland, MA 01721 - USA -- 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: Where current HLASM doc?
On 3/6/2013 9:20 AM, Paul Gilmartin wrote: F Assembler? Assembler VS? Assembler VS was known as IFOX00, IIRC. I once had a manual that explained the differences. It got left behind in a move. I've never heard IFOX00 called the VS assembler; it's always been the XF assembler in my crowd. The "VS" appellation would have been too vague as XF, H, (and H with SLAC enhancements) were available at the same time. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
Is this list not an appropriate forum for any mainframe topic? In my experience, you are more likely to get a useful response to a question here than on one of the more specialized lists. I suppose another good reason is that I am not on the assembler list. I have little interest these days in assembler exotica. I did not think this question would be such a big deal. I thought someone would say "you dummy, since 1.6 it's been called DFHLASM, and so that's the bookshelf where you'll find the current doc" or something like that. I never in my wildest dreams thought that current documentation for a supported IBM product would be a research project. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 06, 2013 6:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where current HLASM doc? Why is this discussion taking place here ratner than on ASSEMBLER-LIST? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DSNE106E message on DB2 batch job
To list; I have a batch job that is getting an error message: DSNE106E PLAN TRANSLD NOT AUTHORIZED FOR SUBSYSTEM DB8G AND AUTH ID IBMUSER This is also happening on another plan name TRANSPD. I did a GRANT EXECUTE on both plans to the userid of PUBLIC. Not sure where to go next on this. I know that a DB2BIND was run against the two plann and the subsystem. Any help would be greatly appreciated. Regards, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Flash Cards on MVS
David: Thanks! The search on IBM.com was hopeless and google was the same. The book chapter didn't answer all my questions directly but enough to go back to the originator and assure him it is not an issue. Ed On Mar 6, 2013, at 6:20 AM, Jousma, David wrote: Ed, If you are speaking of the new zEC12, with the Flash Express option, A couple things come to mind, but I have no direct knowledge because we don't have Flash Express. - It is a feature code of the zEC12. So only IBM parts, no OEM - Since it is a feature code of the zEC12, it would be covered under the same maintenance as any other part of the processor. - requires z/OS 1.13+maint to exploit There is fault tolerance built in, and replacement can be done concurrently. At this time, I am pretty sure that the only exploiters are PAGING and Dump Services. I hear of other plans, but don't know if those have been implemented yet. Here is a link to the redbook zEC12 Technical Guide(see Appendix C). It pretty much appears to answer all your questions: http:// www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf _ 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- m...@listserv.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, March 05, 2013 4:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Flash Cards on MVS I got one civil reply offline. The uncivil one from eastern Europe is not worth the courtesy of a reply. I will attempt to rephrase the question(s) below. I have a customer that is looking at the most current IBM system. I do not have contact with anyone that has the most current IBM system, so I am asking the group nicely, several questions. These are more operations (IMO) issues questions and figured the group would have the knowledge to reply. I did google and really didn't come up with any answers pertaining to IBM's MF implementation of Flash cards. Has anyone have experience with implementing IBM's (NOT STK or OEM) flash cards. What is the typical longevity of IBM's Flash cards and do you keep a few around just in case or ? IF/when they reach their end of life do you toss them return them to IBM etc... (how many spares do you keep on hand) How does your company handle replacements ie operations (or another group) handles the insertion and taking out of "old" cards. IOW operations side of the of the handling. Thanks in advance for any information. -- 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
Re: Where current HLASM doc?
John, I think your numbers are pretty much OK, We also used asmH (IEV90) for something unique. Its too long and intricate to go into here. Suffice it to say we had clerks creating SQL "like" inquiries )asm H macros) and would run these in a batch mode that would take 48 hours or more (elapsed) to get the results. Each ASM job became an inquiry. These queries were monsters on a 168MP taking typically 5 minutes of CPU to compile. Ed On Mar 6, 2013, at 8:02 AM, John Gilmore wrote: The H Assembler at least was once charged for. The cost was always nominal, US$150 per month is what I remember, but I should not wish to be hanged if that number is wrong. It was widely used because it did SYSGENs, NCPGENs, and the like very much faster than the F Assembler. John Gilmore, Ashland, MA 01721 - USA -- 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: DSNE106E message on DB2 batch job
Check SYSIBM.SYSPLSYSTEM catalog table and make sure you have the right value in column "SYSTEM" for the plan SELECT * FROM SYSIBM.SYSPLSYSTEM WHERE NAME = 'TRANSLD' ; The SYSIBM.SYSPLSYSTEM table layout is explained here http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db2z10.doc.sqlref%2Fsrc%2Ftpc%2Fdb2z_sysibmsysplsystemtable.htm Sri IBM Mainframe Discussion List wrote on 03/06/2013 11:45:17 AM: > From: william janulin > To: IBM-MAIN@listserv.ua.edu, > Date: 03/06/2013 11:47 AM > Subject: DSNE106E message on DB2 batch job > Sent by: IBM Mainframe Discussion List > > To list; > > I have a batch job that is getting an error message: > > DSNE106E PLAN TRANSLD NOT AUTHORIZED FOR SUBSYSTEM DB8G AND AUTH ID IBMUSER > > > This is also happening on another plan name TRANSPD. > > I did a GRANT EXECUTE on both plans to the userid of PUBLIC. > > Not sure where to go next on this. I know that a DB2BIND was run > against the two plann and the subsystem. > > Any help would be greatly appreciated. > > Regards, > Bill J. > > -- > 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: Vary off path
As my father-in-law likes to say, when they make me king... 8-) For LPARs with no active operating system, the HMC should be able to simply vary resources logically on and off at will. For LPARs with an active operating system, the HMC should signal the operating system a request to logically vary resources on or off. The signal should include a time out value (e.g., number of seconds) and a time out action (e.g. abort/cancel, continue/force, prompt operator, etc.). The user should be able to select the time out value and time out action. However, the HMC does need to be king, and to have the option to forcibly vary resources on and off after warning the operator what may happen to his first born, etc. [i.e., override the operating system(s)]. Don > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Wednesday, March 06, 2013 12:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Vary off path > > Don Williams wrote: > > >IIRC, it is strongly advised to never use the HMC single object operations to > vary a CHP when the related LPARs have operating systems running in them. > > Agreed. One of our operators did something to a Production LPAR instead to > a Sandbox LPAR from HMC. > Lots of Ouch-ouch-ouch and IPL... > > >Alas, I wish that all operating systems were designed/required to gracefully > handle the HMC varying resources on and off line. > > Including boxed devices? > > I think z/OS should reply with this (but it is just me): > > REPLY 00,Reply with G, N, W, Y or N: > > 1. G - Go ahead, make my day. > 2. N - No, do not continue. > 3. W - Go ahead, but wait for me, I want to check out that resource XYZ. > 4. Y/N - Are your hardware + software fees and licenses fully paid up? ;-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
Re: Flash Cards on MVS
Ed - I'm assuming you are referencing the Flash Express feature introduced on the zEC12 and not flash storage as used in storage controllers (DS8000, EMC DMX, etc). We don't have first hand experience with flash, yet, but from the various webcalls I sat in on during the announcement cycle and updates we've received from our account team I took a number of notes. I'd say, though, that one of the best initial sources that seems to hit the majority of your questions is a FAQ doc IBM created and placed here: http://public.dhe.ibm.com/common/ssi/ecm/en/zsq03058usen/ZSQ03058USEN.PDF That said there are a couple of things I remember being asked that had immediate and emphatic answers from the IBM presenters. As to whether the flash cards wear out the answer was that, yes, ALL flash eventually wears out but that the life cycle of flash in a zEC12 should far exceed the lifecycle of the server itself (no doubt exceptions may occur for customers that tend towards really old/used boxes or extremely long lifecycles). Somewhere I had a note about the (list) price but have since misplaced that but recall it as sounding surprisingly reasonable. While we have a zEC12 we elected not to initially populate it with flash as it's our DR backup for our 2 z196's (and we are still DB2 V9 so no large page usage yet). I fully expect when we lifecycle our z196's to zEC12's we will populate all 3 machines with flash at that time. HTH. ___ Karl S Huf | Senior Vice President | World Wide Technology 50 S LaSalle St, LQ-11, Chicago, IL 60603 | phone (312)630-6287 | k...@ntrs.com Please visit northerntrust.com CONFIDENTIALITY NOTICE: This communication is confidential, may be privileged and is meant only for the intended recipient. If you are not the intended recipient, please notify the sender ASAP and delete this message from your system. IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment concerns tax matters, it is not intended to be used and cannot be used by a taxpayer for the purpose of avoiding penalties that may be imposed by law. For more information about this notice, see http://www.northerntrust.com/circular230 P Please consider the environment before printing this e-mail. From: Ed Gould To: Date: 03/05/2013 03:38 PM Subject:Re: Flash Cards on MVS Sent by:IBM Mainframe Discussion List I got one civil reply offline. The uncivil one from eastern Europe is not worth the courtesy of a reply. I will attempt to rephrase the question(s) below. I have a customer that is looking at the most current IBM system. I do not have contact with anyone that has the most current IBM system, so I am asking the group nicely, several questions. These are more operations (IMO) issues questions and figured the group would have the knowledge to reply. I did google and really didn't come up with any answers pertaining to IBM's MF implementation of Flash cards. Has anyone have experience with implementing IBM's (NOT STK or OEM) flash cards. What is the typical longevity of IBM's Flash cards and do you keep a few around just in case or ? IF/when they reach their end of life do you toss them return them to IBM etc... (how many spares do you keep on hand) How does your company handle replacements ie operations (or another group) handles the insertion and taking out of "old" cards. IOW operations side of the of the handling. Thanks in advance for any information. -- 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
Reality check on LOAD + Rexx LINKPGM
I have a Rexx program (bigger than a "script") that is going to call a module whose name will come from a customer-specified parameter file. As I have it coded now the Rexx first calls a little assembler stub that I happened to already have that issues an MVS LOAD. I then use Rexx ADDRESS LINKPGM to call the module. LINKPGM makes the LOAD technically redundant, but I like the explicit LOAD because the return codes from my assembler LOAD are way better than the return code from LINKPGM, For example: Error loading : ABEND Code S806 Reason Code 4 versus +++ RC(-3) +++ My reading of Assembler Services indicates that there is little additional overhead in doing things this way, that is. with an explicit LOAD followed by a LINKPGM: "A module is considered usable for ATTACH, LINK, or XCTL if it has not been marked NOT REUSABLE by a previous ATTACH, LINK, or XCTL." (FWIW, the loaded module might or might not be RENT/REUS/authorized etc.) Would the august sages of IBMMAIN agree that this is not a bad way to do things; that there is little additional overhead in using LOAD + LINKPGM (+ DELETE) as opposed to just LINKPGM? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debug Tool with Subprograms
On 2/22/2013 7:26 AM, Donald Likens wrote: In case anyone has a better idea I am documenting my solution... I see no way to set a break point before starting the program, so what I am doing is as follows: LOAD INITPGM; LDD INITPGM; AT ENTRY INITPGM BEGIN; set break points; END; Note (these are assembler programs) So far it seems to be working. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Something like this might do LDD A QUALIFY CU A AT stmt1 GOTO stmt2 LDD B QUALIFY CU B AT stmt3 GOTO stmt4 Note that if the CSECT you are trying to qualify to is in another load module, you would need to use the LM::>CU syntax for the LDD and QUALIFY CU commands. If you really want to reference labels, I think it would be AT LABEL label1 GOTO LABEL label2 Note that GOTO will branch to the target and then your program will run to the next breakpoint or off the end. If you want it to branch to the target and then stop, use JUMPTO. George -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
You have our blessing. Go forth and LOAD. ;-) . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Charles Mills To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/06/2013 03:32 PM Subject:Reality check on LOAD + Rexx LINKPGM Sent by:IBM Mainframe Discussion List I have a Rexx program (bigger than a "script") that is going to call a module whose name will come from a customer-specified parameter file. As I have it coded now the Rexx first calls a little assembler stub that I happened to already have that issues an MVS LOAD. I then use Rexx ADDRESS LINKPGM to call the module. LINKPGM makes the LOAD technically redundant, but I like the explicit LOAD because the return codes from my assembler LOAD are way better than the return code from LINKPGM, For example: Error loading : ABEND Code S806 Reason Code 4 versus +++ RC(-3) +++ My reading of Assembler Services indicates that there is little additional overhead in doing things this way, that is. with an explicit LOAD followed by a LINKPGM: "A module is considered usable for ATTACH, LINK, or XCTL if it has not been marked NOT REUSABLE by a previous ATTACH, LINK, or XCTL." (FWIW, the loaded module might or might not be RENT/REUS/authorized etc.) Would the august sages of IBMMAIN agree that this is not a bad way to do things; that there is little additional overhead in using LOAD + LINKPGM (+ DELETE) as opposed to just LINKPGM? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 3 March 2013 11:51, Ed Jaffe wrote: > On 3/3/2013 8:19 AM, Peter Relson wrote: >> >> For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES >> option so that if you must use the HLASM optional function, you can do so. > > We will change every IHASDWA in every software product we have to code > GR32=YES. THANKS for the great info! Thanks indeed, Peter. Two little things: How should we have expected to hear about this nice little update? It's not in the Data Areas, but then mapping macro keywords (like DSECT= and such), are not generally listed there. I can't find an APAR. Maybe for this kind of thing IBM-MAIN is just right. And I notice as I do some reworking to take advantage of this, that SETRP is now failing with RUB=(R5), because R5 is a GR32, and SETRP generates LR15,R5 CPYA 15,R5 one of which must surely provoke the HLASM warning. Would a single LAE not do the trick here? But there are others - sigh... Such a nice idea these Assembler Types. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
On 5 Mar 2013 15:31:23 -0800, in bit.listserv.ibm-main you wrote: >On Tue, 5 Mar 2013 16:16:50 -0500, John Gilmore wrote: >> >>It does not much interest IBM's management, I suspect because it is >>not the focus of 'interesting' activity. Moreover, it is not a profit >>center. It generates no identifiable revenue stream; it is instead >>'given away' as a part of the operating system (which is of course >>paid for). >> >I had understood that, new with MVS/XA, HLASM was not "'given away' >as a part of the operating system", but a separately priced prerequisite. >Has that changed, or was I mistaken? > >TNLs? Did someone say it's harder to update electronic documentation >than hardcopy? Fairly long ago, I understood that in parts of the >aviation service industry mechanics were allowed to print hardcopies >of electronic manuals, but that it was a serious offense to retain them >beyond an explicit expiration date. Should there be a SHARE requirement that all APARs that update documentation also cause an update to the related manuals? In these days of electronic documents, that should be relatively inexpensive and not cause a massive distribution of paper manuals. Those who are attending SHARE might want to consider it. > >-- gil > Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
On Wed, 6 Mar 2013 15:31:35 -0800, Charles Mills wrote: > >As I have it coded now the Rexx first calls a little assembler stub that I >happened to already have that issues an MVS LOAD. > >I then use Rexx ADDRESS LINKPGM to call the module. LINKPGM makes the LOAD >technically redundant, ... > >Would the august sages of IBMMAIN agree that this is not a bad way to do >things; that there is little additional overhead in using LOAD + LINKPGM (+ >DELETE) as opposed to just LINKPGM? > I would expect that if you LINKPGM the module more than once you come out 'way ahead, especially if it's non-LPA. Do you DELETE it when you're finished? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
On Wed, 6 Mar 2013 15:31:35 -0800, Charles Mills wrote: >... >I then use Rexx ADDRESS LINKPGM to call the module. ... > Afterthought: If the module expects OS CALL linkage conventions, use LINKMVS rather than LINKPGM. You can fake it, and more, with LINKPGM, but why reinvent the wheel? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
> Do you DELETE it when you're finished? Ah, but of course! (And I think I did say "+ DELETE" in the OP.) > If the module expects OS CALL linkage conventions, use LINKMVS rather than > LINKPGM FSVO OS CALL Linkage conventions. LINKMVS puts halfword lengths on ALL parameters. That is the convention for EXEC PARM= and for compiler and utility DD overrides, but it is not the general call convention that I know (not what is shown in the example in Assembler Services Guide under "Passing Control with Return"). COBOL (the language of my called program) for example does not in general expect halfword length prefixes (although one could probably code for them) in the Linkage Section. In any event, LINKPGM was a studied choice, not something that grew out of wanting to reinvent the wheel. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 06, 2013 6:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reality check on LOAD + Rexx LINKPGM On Wed, 6 Mar 2013 15:31:35 -0800, Charles Mills wrote: >... >I then use Rexx ADDRESS LINKPGM to call the module. ... > Afterthought: If the module expects OS CALL linkage conventions, use LINKMVS rather than LINKPGM. You can fake it, and more, with LINKPGM, but why reinvent the wheel? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
Thank you. I shall get loaded forthwith. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Wednesday, March 06, 2013 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reality check on LOAD + Rexx LINKPGM You have our blessing. Go forth and LOAD. ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
On Wed, 6 Mar 2013 19:07:30 -0800, Charles Mills wrote: > >Ah, but of course! (And I think I did say "+ DELETE" in the OP.) > You did (parenthetically, now that I reread it.) >> If the module expects OS CALL linkage conventions, use LINKMVS rather than >> LINKPGM > >..., LINKPGM was a studied choice, not something that grew out of wanting to >reinvent the wheel. > Understood, now. That's, for example, how SYS1.SAMPLIB(CSFTEST) calls ICSF, which doesn't expect the halfword length. I have on occasion reinvented the wheel in order to test extreme PARM lengths. Results: BPXBATCH cheerfully accepts and correctly processes a PARM of length up to 65,535 (x''; why not?) HLASM accepts and correctly processes a parm of length up to 32,767 (x'7FFF'); at length 32,768 (x'8000'), it produces several hundred thousand lines of error messages, then program checks. I think that's pretty harsh. Where's the Black Team when you need them? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Current HLASM doc
To determine what's been added via PTF to YOUR copy of HLASM, specify the INFO option. It will show the new mnemonics as well as various fixes. John Ehrman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Current HLASM doc
On Wed, 6 Mar 2013 21:45:07 -0800, John R. Ehrman (408-463-3543 T/543-) wrote: >To determine what's been added via PTF to YOUR copy of HLASM, specify >the INFO option. It will show the new mnemonics as well as various >fixes. > Neat! Thanks. Does it tell me what new parameter values have been added to the OPTABLE instruction since the last edition of the HLASM Reference? I don't see any, but perhaps there are none. No, a little bit of searching for 'opcode' and vicinity finds values 'ZS5', 'ZS6', and 'Z196'; not in the V1R6 RM. Better than nothing, but not as explicit as it should be. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHARE Requirements (Was: Where current HLASM doc?)
On 3/6/2013 5:17 PM, Clark Morris wrote: Should there be a SHARE requirement that all APARs that update documentation also cause an update to the related manuals? In these days of electronic documents, that should be relatively inexpensive and not cause a massive distribution of paper manuals. Those who are attending SHARE might want to consider it. IIRC, there is a current SHARE requirement asking for periodic manual refreshes (every six months?) to be delivered to the InfoCenters, etc. SHARE requirements are not tied to conference attendance in any way. Any member company can open a requirement at any time via the electronic system. Every six months, Cheryl Watson presents a session reviewing how this is done. The most recent (from SHARE in San Francisco) is here: https://share.confex.com/share/120/webprogram/Session13044.html -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieving output submitted by surrogates
Walt, Thanks, you have confirmed what we were thinking here. We will try and test this today. Regards -Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: 07 March 2013 00:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retrieving output submitted by surrogates On Wed, 6 Mar 2013 21:14:13 +0800, Robin Atwod wrote: >This is a rather arcane topic but hopefully one of you out there might >have some insight. I am working on a problem where a customer uses our >application to submit jobs to JES2, and then, when the output is >available, the application reads it from the spool and sends it back to the >customer. >This uses the SAPI (function 79) JES2 call and has worked well for years. >Now a customer wants to use a surrogate userid to submit the jobs which >run under various different userids. Submission works fine, as long as >the RACF rules are defined, but when I try to pick up the output, I get >RC=4, nothing found. First, just to make sure we're using the same terminology, there are two important user IDs to consider here: (a) the execution user, specified in your case via USER= on the JOB statement, and (b) the user who submits the job (which is the surrogate user). JESSPOOL security processing will allow the execution user to view/retrieve output without any profiles defined. However, the submitter (surrogate user) does not have authority to the job output unless a JESSPOOL profile allows it. That will also affect the SAPI processing, but I really don't know what kind of return codes you'd get. You might be able to see some JES2 error messages if you first issue "$T DEBUG,SECURITY=YES" if the SAPI function works like normal spool access/selection does, but I"m not sure. -- Walt -- 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
