Re: Does the JES2 ESTBYTE parm limit STC or just batch output?
Thank you all. Jesse answered the question. It looks like STCs are agnostic to ESTBYTE. Regardless of the line count, if a STC takes 25% of the spool, it needs to be cancelled, either by Exit 20, Netview, or as a last resort the operator. Oh well, back to the drawing board, Exit 20, and Netview. On Sat, Jun 10, 2017 at 4:00 PM, Edward Gould <edgould1...@comcast.net> wrote: > > On Jun 10, 2017, at 2:33 PM, Tom Brennan <t...@tombrennansoftware.com> > wrote: > > > > I should probably relay my old story about estimated line counts: Back > around 1984 a spool shortage occurred that slowed or stopped all processing > enough that the manager response was "Put in some limits". So someone > implemented a JES2 exit that 722'd when the estimated line count was > exceeded. Managers were happy I guess. > > Indeed we had field in the accounting field that specified the max number > of lines (25K was the max). > We were somewhat lucky as a full spool almost never happened (in the > 80’s). We liked to think that was way. But it did work. > > Ed > > > > The result, however, was that virtually all of the 722's were folks who > simply needed to increase their estimated line count, often after a > complaining phone call to my desk. So basically all the exit did was cause > reruns and additional CPU usage - very expensive in those days. I ended up > removing the exit and concentrated on actions to handle spool problems on > the back-end (notification and automation, including spool offload if > necessary). Those back-end methods have their own issues, but at least the > complaning calls stopped. > > > > Jesse 1 Robinson wrote: > >> In light of our spool problems, we have undertaken to set a limit. > Trying to make everyone put output limits in their jobs would be out of the > question. So we dug into TFM and found system wide ESTLNCT. There are > related parms for byte count and page count, but we went with lines for > simplicity. It's a 'basic' parm not associated with job class. We set > ESTLNCT to a value that we calculated would represent around 20% of the > spool. Fortunately we have a sandbox system where we can play with this > sort of thing. Good news for us: a large output job gets S722 when our > experimental limit is exceeded. Bad news for OP: I set up a started task to > do the same thing; it ran to completion regardless of output count. So it > appears that STCs are not subject to the ESTLNCT value. I’m 99% sure that > the TSO OUTLIM value specified in IKJTSOxx affects only TSO; in fact, only > the TSO TRANSMIT command, not TSO output in general. Before discovering > ESTLNCT, we set out to get automation (SA) to analyze the 'output exceeded' > message and cancel a job when it reaches 20% of the spool; that value is > included in the message. I imagine that the same strategy could be used to > limit STCs, but it would require more work. It just occurred to me that if > you're concerned about a specific STC, you might try putting a JOB card on > it. I have not tried that. > > > > -- > > 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 > -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does the JES2 ESTBYTE parm limit STC or just batch output?
Yes, Jesse, it was exactly this excerpt you quote which inspired my post. It is very vague wrt ESTBYTE, whether it applies just to batch and APPC or also STCs. Are the internal JES2 limits it cites set just for TSO XMITs or do they apply also to STCs in lieu of the ESTBYTE parm. If so, it would be nice to have an option like the OPT=0,1,2 ESTBYTE subparm when the limit is triggered than to have to install the JES2 EXIT 20 just to cancel the task. Just wondering if anyone has been able to get ESTBYTE working for STCs and not just batch, APPC, and would not want to fill the spool and hang the MAS just to find out. On Fri, Jun 9, 2017 at 12:03 AM, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > We have experienced a number of spool-full conditions in the recent past, > always caused by runaway batch jobs that produce tens of millions of lines > of garbage until the entire MAS grinds to a halt. So we're experimenting > with JES2-defined limits. In researching the options, we came across the > doc below. We're focused on batch, but this passage may be telling. If only > we could understand it. May you be granted more insight that us. > > "Considerations for started tasks and TSO LOGONs > > "Output limits for TSO/E transmits can be set by TSO/E using the > TSO/E OUTLIM= parameter. JES2 also sets a limit internally. When > SYSOUT is transmitted in the foreground for started tasks and TSO/E > LOGONs, the member uses the lower of these two limits. JES2 sets the > following output limits for started tasks and TSO LOGONs: > > "999,999 for lines, cards, and pages > 2,147,483 (in 1000s of bytes) for spool utilization. > An installation can change the limits for started tasks or TSO > LOGONs by using JES2 Exit 20 to change the limit for each particular > started task or TSO LOGONs The limit for TSO/E transmits which are > specified thorough the OUTLIM parameter, should not be greater than > the limit JES2 sets for punches or a X'722' abend will occur. > See z/OS TSO/E Customization for information about limiting the > TSO/E TRANSMIT > command." > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Thursday, June 08, 2017 4:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Does the JES2 ESTBYTE parm limit STC or just batch > output? > > The EST Byte, Line, Page can be dynamically changed. > > The simplest way to avoid an IPL (and JES2 just stops when spool is full - > but will respond to commands like PURGE) > > Is to cycle the STC, add another spool volume, or see what is really going > on. > > If the STC is filling up spool, it needs to be determined why. We have > automated the HASP050 / HASP375 message to send emails and alerts when some > of the JES2 functions are impacted (BERT, SPOOL, JNUM, etc.) > > My understanding is the IEFUSO exit can cancel an STC if it exceeds its > limits. You can code the STCCLASS statement in JES2 and allow the IEFUSO > to do its job. > > You can also use automation tools to monitor for HASP375, HASP050 or other > > You can use products like z/OSEM or EASYEXIT (DTS Software) to control > your jobs names (STC, TSU, or JOB) for determining final action. > > Lizette > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of George Henke > > Sent: Thursday, June 08, 2017 1:59 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Does the JES2 ESTBYTE parm limit STC or just batch output? > > > > Just averted a near disaster, a mid-day IPL of 4 LPARs, with a STC > > filling up the spool with 10B bytes of data because the ESTBYTE limit > > was not turned on for termination, OPT=1. > > > > But would it have done anything anyway for a STC or does it just apply > > to batch and APPC. > > > > The manual is silently ambiguous on this. > > > > If anyone has had success limiting STC output so, please let me know, > > else it will probably be JES2 Exit 20. > > > > -- > > George Henke > > (C) 845 401 5614 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Does the JES2 ESTBYTE parm limit STC or just batch output?
Just averted a near disaster, a mid-day IPL of 4 LPARs, with a STC filling up the spool with 10B bytes of data because the ESTBYTE limit was not turned on for termination, OPT=1. But would it have done anything anyway for a STC or does it just apply to batch and APPC. The manual is silently ambiguous on this. If anyone has had success limiting STC output so, please let me know, else it will probably be JES2 Exit 20. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zSECURE 32 x 80 Hang
Whenever we Dial into our z/OS VM with PCOMM and 32X80 screen size it hangs at the very end of the ISPF dialog and after displaying the final ISPF dialog screen. 24 X 80 is ok. Coming through PCOMM on CITRIX is ok. Coming through a NATed address in PCOMM is also ok. It only fails when we Dial In with 32 X 80. Any ideas? -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mounting Unique zFS for SMPE APPLY
The zFS names on our SMPE maintenance system are the same as on the PROD RES VOLS. How do you make them unique so they can be mounted on the SMPE maintenance system for the SMPE APPLYs? I suppose just DSS copy and rename them to something else? -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VISARA Consoles FICON Get 505, 510
Thank you very much, Jerry, for this very useful feedback. Yes, we are using the Coax Box add-on and having just horrendous problems not only with it but with the 3074 itself. We have learned that the Visara FICON product has only 5 customers and has been available for only since Jan 1. This looks and feels more like beta testing, the bleeding edge, than implementation of a real product, The omission of ESCON from the zEC12 is proving to be a fatal mistake. It is forcing us to use these kind of unvetted products. These kind of HW oversights are reminiscent of the days when IBM prematurely converted from powerful Bi-Polar chips to underpowdered CMOS chips and customers had to flee back to the Bi-Polar boxes. When will IBM learn. But then Watts Humphrey who put the z in z/OS, z/VSE, and z/VM, which means literally zero-tolerance for downtime, is no longer there; he retired and died in 2010. Such unconscious mistakes would not occur if he were still around. . On Wed, Jul 24, 2013 at 12:50 PM, Jerry Whitteridge jerry.whitteri...@safeway.com wrote: Ensure you are on the latest microcode version for the 3074's. Are you using pure 3074 or the add on Coax box ? There were some challenges with the early code but it appears to stable and functional now. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George Henke Sent: Tuesday, July 23, 2013 5:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VISARA Consoles FICON Get 505, 510 Has anyone converted VISARA consoles from ESCON to FICON? They work fine as ESCON, but will not talk to z/OS as FICON. They run off of ESCON and FICON directors respectively. We have done 3 PORs and each time the console's get either a 505 or a 510. We need VISARAs for the LMU interface for the STK SILOs, but they also double as system consoles. We are going zEC12 which is pure FICON. The OPTICA PRISM ESCON Converters which IBM recommends must be direct to the device, they cannot go through an ESCON director. So we are forced to make them FICON and need them working. I suppose a workaround would be to attach the ESCON VISARAs through OPTICA PRISM ESCON Converters directly to the CEC, instead of the ESCON director. We are MULTISYSTEM with 4 LPARs with EMIFed CHPIDs. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OPTICA PRIZM FICON2ESCON Conversion and Visara
Has anyone used these converters to front-end Visara consoles either directly or behind an ESCON Director? The unvetted Visara FICON console product is causing us great consternation and the only other option for a zEC12, which is pure FICON, ESCON being no longer available, are these OPTICA PRIZM converters. With all due respect to Reuben Garrett Lucius Goldberg, our MF is beginning to resemble more a Rube Goldberg Machine than an IBM computer. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VISARA Consoles FICON Get 505, 510
Has anyone converted VISARA consoles from ESCON to FICON? They work fine as ESCON, but will not talk to z/OS as FICON. They run off of ESCON and FICON directors respectively. We have done 3 PORs and each time the console's get either a 505 or a 510. We need VISARAs for the LMU interface for the STK SILOs, but they also double as system consoles. We are going zEC12 which is pure FICON. The OPTICA PRISM ESCON Converters which IBM recommends must be direct to the device, they cannot go through an ESCON director. So we are forced to make them FICON and need them working. I suppose a workaround would be to attach the ESCON VISARAs through OPTICA PRISM ESCON Converters directly to the CEC, instead of the ESCON director. We are MULTISYSTEM with 4 LPARs with EMIFed CHPIDs. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zEC12 LPAR Abends
Has anyone else experienced a similar problem? This abend is a result of the z/VM Control Program (CP) being unable to acquire the IPTE Interlock in a reasonable time. The IPTE Interlock can be acquired by both CP and by Guests (running under SIE). The approach CP uses to acquire the lock is to try once every 50-100 microseconds for up to 10,000 attempts. If not acquired at the end of that, the LCK009 abend is taken. We have validated that the abend was not a result of the Guest holding the interlock indefinitely, but rather the rare timing that different vCPUs of the guest in question would acquire it in between CP's attempts to acquire it. The following are factors contributing to the possibility of resulting in the abend: 1. The rate at which the Guest is doing IPTEs. The higher the rate, the greater the possibility of the abend. 2. The number of virtual CPUs configured for a given virtual machine. Since IPTE can be issued by any of the virtual CPUs, the greater the number the greater the possibility. 3. The number of logical processors. Just having multiple virtual CPUs is not enough, but being able to run them concurrently increases the possibility. 4. Load on the system by other guests. The lighter the load overall, the more likely multiple vCPUs of the same guest could be dispatched at once and the greater the possibility. 5. Frequency at which CP attempts to acquire the lock. Currently 50-100 microseconds. The less frequently CP attempts to acquire the lock, the more likely CP misses an opportunity where the lock was available. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zEC12, and previous generations, why? type question - GPU computing.
I believe IBM produced a pc with a 370 to run VM on a PC. Merrill Lynch had one. Somewhere in the late 80's I believe. On Thu, Sep 6, 2012 at 1:52 AM, Timothy Sipples1 sipp...@sg.ibm.com wrote: Yes, there are organizations that use zEnterprise servers for heavy numeric computation. Like decimal floating point. Cryptography is another excellent example. And you can buy optional CryptoExpress adapters if you want to augment the excellent capabilities found in every machine. You can also buy the optional zBladeCenter Extension (zBX) if you want to add DataPower accelerators, Power blades, and/or X86 blades. You can also add an optional IBM DB2 Analytics Accelerator, to boost many types of DB2 queries. So we're way ahead of you, John. ;-) I think the simple answer is that it depends what you optimize for in designing a server processor (or complex). But IBM has broken a lot of rules already about which server should do what, and I predict more rules will be broken. With respect to the 370-on-a-chip, IBM sort of did that with the 1975 introduction of the IBM 5100 Portable Computer starting at $8,975 (1975 dollars), although it was for a relatively narrow initial purpose (to get APL running). The 5100 sold reasonably well from what I've read, but I think there were three basic problems which prevented it from becoming a blockbuster: 1. The price was not low enough for mass market appeal. (Apple had a similar problem with the Lisa in the early 1980s.) 2. The software selection didn't exactly hit the mark, although it was a good try for the time. (IBM learned the value of software somewhat later in its evolution but not in time for the 1981 IBM PC.) 3. It probably didn't have the right third party marketing and distribution channels. With some very notable exceptions, like typewriters, at that time IBM would have had some challenges with this type of product. Keep in mind that for 1975 this was absolutely amazing technology, but amazing technology required some expense. Being early is pricey. If the 5100 debuted in, say, 1977 or 1978, it would have still been well timed but could have dramatically reduced the chip and board count. I also think the small built-in monitor could have been sacrified (at least as an option) in favor of a display port of some kind -- ideally RF for TV hookup. And IBM might have gone with a diskette drive for storage -- the 5100 was too early for the 5.25 inch drive, which debuted in 1976. Finally, if IBM had provided a little more guidance on the 370 subset instruction set they implemented, software developers could have taken over from there. So I think the 5100 could have been a nice 5110 by tweaking the recipe a bit. But history didn't happen that way. IBM had some success with the System/4 Pi avionics processors which are descended from System/360. Timothy Sipples Consulting Enterprise IT Architect (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The IBM zEnterprise EC12 announcment
Please check out the following excerpt. Is it right? Who is going to buy obsolete inventory at the same price as current inventory? Are there not many resellers out there who will drop the price of the z196? The three items below make going with the new processor a no brainer compar= ed to a z196, even if there are not any specific features that help the CMS= workload. IBM does NOT provide fire sales to push out its old stock. Therefo= re, upgrading to a EC12 will not cost much more than upgrading to a z196 (t= he upgrade calculations are a little higher for a two generation tech bump,= but only about 10% if adding MIPS). It will last longer before IBM freezes the in-tech HW and microcode= upgrades (z10 already has memory frozen; microcode will be frozen in June'= 13). Expect between 2 and 3 years longer life from a EC12 compared to z196= . The software is slightly cheaper compared to z196 AWLC. Base 3 MSU= s did not change; other AWLC products have the following discounts in what = IBM is referring to as TU1 (Technology Update Pricing for AWLC). Referenc= e to IBM SW price document below. o 4 - 45 MSUs 2.0% 46 - 315 MSUs 4.0% 316 - 1315 MSUs 4.5% 1316 - 2676 MSUs 5.0% 2677 - 5476 MSUs 6.0% 5477 - more MSUs 7.0% http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=ANsubtype=CAa ppname=gpateamsupplier=897letternum=ENUS212-320pdf=yes http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=3DANsubtype=3DCAa=ppname=3Dgpateamsupplier=3D897letternum=3DENUS212-320pdf=3Dyes -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Finding Waiters/Holders After Abend
Help before my shop replaces a GRS STAR with a Mii (aka MIM) RING on a MULTISYSTEM, just so production support does not have to issue an F GRS command to try to discover the Waiters/Holders too late, after the fact, after the job abends. Evidently MIM has a nice audit trail in the job log which discloses this info. Does GRS have a similar facility? There are the usual workarounds: Automations entering the F GRS command triggered by the IKJ56241I message, OMEGAMON Exception Analysis, etc. But is there anything within GRS itself that will produce an audit trail? If not, has anyone else a nifty solution to this somewhat sticky problem. -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
