Re: We're losing the battle
Ron Hawkins writes: Oh come on Richard. There are Banks all around the world that have never possessed a MF, and get along quite nicely with five nines availability on Unix clustered solutions. Last I checked (which was very recently), exactly none of the top 50+ banks are without mainframes, nearly all IBM mainframes. (There might be an exception or two in Japan where there are Fujitsu, Hitachi, and NEC mainframes running operating systems like MSP, XSP, VOS3, and ACOS.) It has also been the trend that the mainframe banks have bought out the smaller non-mainframe banks. I don't think that's coincidence -- the modern mainframe is a fantastic vehicle to support rapid business acquisition. But I have a second point to make below We should not fool ourselves into thinking that Parallel Sysplex and GDPS are the only HA clustered solutions in the market place, whether local, metro or geographically dispersed. I had UNIX customers doing multi-site RAID-1 over RAID-5 before Hiperswap was a twinkle in IBM's eye! Damn site easier to operate too. Nobody said Parallel Sysplex and GDPS are the only high availability clustered solutions in the market. But this whole thread got started because of a complaint about *planned* outages. One must not be sloppy here: five nines should have a business definition, and that definition does not typically distinguish between planned and unplanned outages. (Or at least people should say something like five nines, excluding planned outages of up to [X] duration [Y] times per year.) If you're down, you're down. Note also that down in business terms means both completely down and not responding fast enough, predictably enough. For a credit card company it's that wallet-share question: whether the customer reaches for their Visa or their American Express card. (And there's stickiness to that decision: credit card users tend to reach back for the same card.) That's another level of rigor that the five nines shorthand often does not capture. Last I checked (again very recently), it still wasn't possible to upgrade your major database version and keep the business running while you do it, even if you have the fanciest and most expensive distributed UNIX cluster in the world. That run-while-upgrading process is routine on z/OS with Parallel Sysplex and DB2 data sharing. And I'm sure z/TPF enthusiasts could point to some really interesting things they can do, to pick another example. There are many others pervasive throughout the hardware, operating system, and middleware. Does it matter? Not to everyone, but of course it matters to many businesses and for many services. The need to avoid planned outages seems to be increasing over time actually, so there's a lot of demand here. J R writes: The front ends need to be bulletproof because back ends are not always available. This has nothing to do with whether the front and back ends are Tandem or IBM. The front end and back ends may even be on the same box. It's not necessarily that the box becomes unavailable but, more likely, that the back end application does -- sometimes intentionally, sometimes not. The important thing is that the front end can continue to service transactions, stand in for the back end and SAF the results. Very good point. Basically an organization introduces front-end receive-and-store queuing systems if they have unreliable backends. And sometimes that's good enough, but it's always a second-best service level. For example, the ATMs might offer lower limit cash withdrawals (and hold those withdrawal records for later reconciliation), but they won't provide an up-to-date account balance if the backend is offline. Back in the day, Tandem was the dominant fault-tolerant platform. However, for almost two decades, sysplex technology has given mainframes fault tolerance that Tandem can only dream of. So, it's not that Tandem's front end value is lessening but that they are no longer the only game in town. I do think Tandem (HP NonStop) front-end value is lessening because of decisions HP and especially software vendors have made recently. But I think you're exactly right about the fact that, if you have a highly available IBM mainframe backend, why do you still need a special queuing front-end? Quite simply you don't, and that's been the trend, to edit and to simplify for several reasons. [De-tiering is good in HA engineering, actually, so if you can eliminate a tier or two ceteris paribus you'll improve your statistical predicted availability. Said another way, a pair of five nines clusters lashed in sequence together does not quite result in five nines end-to-end. (Get out your calculator and give it a try.)] It shouldn't be surprising. In any business, if a middleman no longer offers a unique benefit, why deal with the middleman? Why not just go direct? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo,
JES3 command equivalent to JES2's OUTDISP=KEEP
Is there an equivalent JES3 option to the JES2 OUTDISP=KEEP option? Output with OUTDISP=KEEP will be printed and kept on spool after the print with OUTDISP=LEAVE (which is changed to KEEP once more when the output is release again). I tried to find out by RTFM but had no success so far. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stupid Question of the day.
Paul Gilmartin wrote: If some future release (or a USERMOD?) were to remove not just SYSIKJUA propagation, but to remove the ENQ entirely, might it then be possible for a user to have concurrent sessions not only in different LPARs, but even in a single LPAR? The MULTITSO package in CBT file 134 appeared when the millenium was young, and JES (at least JES2) only allowed one TSU job of a specific name to run at a time. It works by front-ending the ENQ SVC and converting SYSIKJUA enqueues to shared. Also, exits step in to alter the job name in the TSO session's JCL. This permits 40-ish concurrent TSO sessions from a single TSO userid. CLISTs invoked at LOGON time used an ISPF profile with a qualifier of the job name, cloning it from the user's master copy if it did not already exist. Good for a single system, but not SYSPLEX aware. Still, I think it proves your point. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Timothy Sipples) writes: Nobody said Parallel Sysplex and GDPS are the only high availability clustered solutions in the market. But this whole thread got started because of a complaint about *planned* outages. One must not be sloppy here: five nines should have a business definition, and that definition does not typically distinguish between planned and unplanned outages. (Or at least people should say something like five nines, excluding planned outages of up to [X] duration [Y] times per year.) If you're down, you're down. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle http://www.garlic.com/~lynn/2008j.html#7 We're losing the battle http://www.garlic.com/~lynn/2008j.html#10 We're losing the battle when we were out marketing ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp ... against tandem (as well as s/88 aka stratus) ... there was a customer with five-nines application availability requirement (five minutes outage/annum). the non-clustered fault-tolerant solutions had software maintenance (scheduled) outages that far exceeded 5min/annum. we had also coined the term disaster survivability and geographic survivability ... i.e. clustering at a distance ... as hardware and other components become more more reliable ... localized disturbances were becoming a larger percentage of unplanned outages. http://www.garlic.com/~lynn/subtopic.html#available as mentioned earlier in the thread ... long ago and far away, my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture ... where she created peer-coupled shared data. http://www.garlic.com/~lynn/subtopic.html#shareddata Lack of uptake (at the time) resulted in her not staying long in the position. Except for ims hot-standby ... it wasn't until sysplex that you started seeing her architecture being supported. the long mainframe lead time ... was at least partial motivation for ha/cmp product (based on power platform rather than mainframe platform). it was also behind POK Rochester objecting to ha/cmp contributions to the corporate continuous availability strategy document ... claiming that it would be years before they could have such support. some folklore x-over ... Bruce's talk last month at Jim's tribute pointed out that his formulization of transaction semantics was the real significant enabler opening up online transactions (sufficient trust in computer operations vis-a-vis manual/paper operation). This was during the days of the original relational/sql implementation project at san jose research on vm/cms platform http://www.garlic.com/~lynn/subtopic.html#systemr Following Bruce's talk was some people from tandem (corresponding to Jim having left research for tandem). Two things mentioned in that time-frame was Jim defining the TPF thruput (ACP having been renamed TPF as more non-airlines started using it for transactions) as a transaction objective for Tandem systems. The other was the study showing that hardware was becoming significantly more reliable and other factors were increasingly becoming source of outages (planned, human mistakes, disturbances in localized geographical area). Jim later left Tandem for DEC database group in San Francisco. It was in this time-frame that I had something of an argument with him at '91 Asilomar SIGOPS ... where I was claiming I could do high availability on (clustered) commodity hardware (using ha/cmp methodology as example) and he claiming that it still required proprietary hardware (somewhat reflecting the Tandem and DEC vax/cluster affiliations). I've since noted that not too long later, he then had to be up on the stage for the announcement of the m'soft availability clustering ... recent reference: http://www.garlic.com/~lynn/2008i.html#50 Microsoft versus Digital Equipment Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne Lynn Wheeler [EMAIL PROTECTED] writes: Following Bruce's talk was some people from tandem (corresponding to Jim having left research for tandem). Two things mentioned in that time-frame was Jim defining the TPF thruput (ACP having been renamed TPF as more non-airlines started using it for transactions) as a transaction objective for Tandem systems. The other was the study showing that hardware was becoming significantly more reliable and other factors were increasingly becoming source of outages (planned, human mistakes, disturbances in localized geographical area). re: http://www.garlic.com/~lynn/2008j.html#16 We're losing the battle old ACP/TPF related email from the period http://www.garlic.com/~lynn/2008i.html#email800325 in this post http://www.garlic.com/~lynn/2008i.html#39 American Airlines giving some numbers for 120 transaction/second TPF system -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Tue, 24 Jun 2008 14:20:03 -0600, Howard Brazee [EMAIL PROTECTED] wrote: On 24 Jun 2008 12:55:15 -0700, [EMAIL PROTECTED] (Ed Philbrook) wrote: Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. What's funny is that shops have old, old, old standards that compile CoBOL without SSRANGE (for efficiency). Many of those shops fell in love with PL/I because boundary checking was automatic. It was just as expensive though. As time goes by, the costs of not having SSRANGE, get bigger and bigger (relative to the cost of implementing it), but the person who set the standard has been replaced a dozen times, and the standard lives on. Ok. I am going to see how to take your suggestion into account. And about data manipulation, I thought to the following checks: - a data is moved into another that has a shorter size (it will be truncated or it could override other data) - a PIC X is moved into a PIC 9 without test IF NUMERIC - a data is redefined and one of its numeric field is redefined in several fields - size of FD is not equal to size defined in JCL (LRECL) - a file is read but it has not been opened - some numeric conversions could lead to lost of accuracy, no ? Same with arithmetic statements, I suppose. What are you thinking about this? Other ideas? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CHECK(IBMXCF,XCF_SIG_STR_SIZE)
Hi, We have a problem with the subject check. We have added three system to our sysplex in the sysplex CDS and the day after the health check show this check. We've solved two sizes problems in structures but we can't remove the check for the last structure. The last structure has a problem of size and number lists (h. checker says) but both of the checks are related between them. We've execute the cfsizer and increase the size but the check continues. We have increased the structure size three times and we can't remove it!!!. And the best: we rebuild the structure to the other CF and the check dissappears !!!. When the structure return to it own CF the check return again. We attach the check in the post. Kind regards Jorge García Juanino Técnico de Sistemas Z/Os/Área de Producción y Tecnología MAPFRE TECNOLOGÍAS DE LA INFORMACIÓN Crtra. De Pozuelo nº 52 28220 Majadahonda (Madrid) Tfno: 91 581 27 34/ 618 33 35 59 Fax: 91 581 24 01 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html De: Cadena HZSPRINT Enviado el: miércoles, 25 de junio de 2008 12:55 Para: zzl DGTP IT Soporte Sistemas z/OS Asunto: CHECK(IBMXCF,XCF_SIG_STR_SIZE) en LNA4 1 * * * HZSPRINT (HBB7730-06024) 2008/06/25 12:55 * * * * HZSU001I Check messages * * Sysplex: SYSPLEX0System: LNA4* * * * Filter: CHECK(IBMXCF,XCF_SIG_STR_SIZE) * * * * * * Start: CHECK(IBMXCF,XCF_SIG_STR_SIZE)* * * CHECK(IBMXCF,XCF_SIG_STR_SIZE) START TIME: 06/25/2008 12:55:21.679889 CHECK DATE: 20050130 CHECK SEVERITY: MEDIUM CHECK PARM: 20 * Medium Severity Exception * IXCH0247E Structure IXCPATH6 does not have enough lists to support full signal connectivity. Explanation: This check assumes that a signal structure is intended to support full signal connectivity among all possible systems in the sysplex. The expected number of systems in the sysplex is determined by the number of systems supported by the primary sysplex couple data set. The structure has 0 lists, but 140 lists are needed to provide full signal connectivity between all 12 systems that could be in the sysplex. Whenever XCF allocates a signaling structure, it tries to allocate it with enough lists to provide full signaling connectivity among all possible systems in the sysplex. If XCF finds it needs more lists, it will attempt to rebuild the structure to get them. When XCF switches to a new primary sysplex couple data set that supports more systems than the previous one, it will attempt to rebuild the structure to get more lists in anticipation of the need to establish signaling paths with more systems. The failure of this check suggests that XCF was unable to allocate the structure with the desired number of lists (an unlikely pathological case caused by space constraints), or its attempt to rebuild the structure failed. System Action: The system continues processing normally. Operator Response: Report the problem to the system programmer. System Programmer Response: Examine logs to determine why the rebuild of the structure failed. Messages IXL013I and IXL015I are relevant. Resolve the indicated problem(s). If XCF does not automatically initiate a rebuild of the structure with an appropriate number of lists as a result of the problem resolution, initiate a rebuild of the structure. To do so, issue the command SETXCF START,REBUILD,STRNAME=IXCxxx where IXCxxx is the name of the signaling structure. Upon successful completion of the rebuild, verify that the structure was allocated with the necessary number of lists. XCF issues message IXC457I on the system that allocates the structure to indicate the number of lists in the structure and the number of systems that can establish full signaling connectivity
Re: Displaying Quiesced zFS files
I agree and out of pure morbid curiosity, at this point, did you happen to issue a 'D GRS,C'? And if so did Latch Number 87 come back, a quiesce latch for a zFS file system. Just curious if other zFS support may be lacking.. Mark Zelden [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 09:41:13 -0500, Ramiro Camposagrado wrote: The following section was added to the DFS/SMB section of the PSP buckets for z/OS 1.4, 1.5, 1.6, and 1.7, as a result of a PMR that I have opened with zFS development in regards to this issue. I guess they are still working on the fix. 06/04/11 If a zfs filesystem is quiesced 04/11/2006? Over 2 years and still no relief? What about the 1.8 and 1.9 buckets (I didn't check)? Considering the push to zFS, this is really bad. Jeers for IBM on this one... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSE Systems Programming Resource A/P
I would be interested in discussing this further. Please contact me offline. John P. Baker [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Mednick Sent: Wednesday, June 25, 2008 1:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: VSE Systems Programming Resource A/P If there's a VSE Systems Programmer sitting around twiddling their thumbs and is interested in some contract work in the Asia/Pacific Region to undertake a storage migration, please contact me off list. I have no commercial interest in this requirement and I was asked if I knew of anyone who might be able to help. Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z9 Crypto Express2 usage
John, I am curious about your intended use for the cards. Usually the intended use plus any regulatory requirements gives quite a bit of information about the final configuration for ICSF/CEX2C setup. If there is a TKE involved, then there is a good SHARE presentation on the setup. Rob Schramm Sirius Computer Solutions -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
Ed, Thanks for the link. Interesting stuff there. Rob Schramm Sirius Computer Solutions -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CEE3703I In HANC Control Block, the Eye Catcher is damaged.
You can have VS COBOL II modules linked with VS COBOL II and still run them without VS COBOL II run-time library, you can run them with LE library. We have only LE in the DFHRPL. Using ISRDDN I searched the Linklist/LPA concatenation for IGZ* modules and they are only found in hlq.CEE.SCEERUN and hlq.CEE.SCEERUN2. We appear to be in the category you describe. My thanks to those who replied here and on CICS-L, there doesn't appear to be anything (explicitly listed as that won't work) wrong with the construction of the module itself. And I see the abstract for John Monti's Orlando SHARE presentation 8209 Heaps of fun with LE Heaps says Have you seen a CEE0802C message saying your LE Heap control information was damaged? Well this session is for you. These problems are most often caused by application overlays. The speaker will guide you through the LE Heaps in a fun and interesting way to help you learn techniques and LE run-time options which can assist with finding the source of these problems. Lo, and behold, just a bit after the CEE3703I message in the subject line of this thread there is a CEE0802C Heap storage control information was damaged. message. So I now have something to read and point the apps people at. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve Comstock) wrote: What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Evaluate your needs and wants, compare them with the costs involved - just as you do with any other purchase. Some people compare computers with transportation. Sometimes a cargo ship is the best solution, other times, trains, large trucks, small trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling work better for particular tasks. Each tool has different standards, different costs, different strengths, and different weaknesses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Op codes removed from z/10
Does anyone know what these opcodes are? They are no longer supported on the z/10, but I can't find them in the Reference Summary E503 E504 E505 E506 E507 Stephen Bielskie Assistant Vice President IT - z/OS Base Products - Princeton - KIUT57 IT - Mainframe Hardware - Princeton - KIUT54 CREDIT SUISSE Princeton, NJ Telephone : (609) 243-0711 Email :[EMAIL PROTECTED] == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
E503SVC Assist E504Obtain Local Lock E505Release Local Lock E506Obtain CMS Lock E507Release CMS Lock These instructions comprised a part of the MVS Extended Facility, which provided performance improvements back in the days of MVS/XA and MVS/SP. John P. Baker -Original Message- From: IBM Mainframe Assembler List [mailto:[EMAIL PROTECTED] On Behalf Of Bielskie, Stephen Sent: Wednesday, June 25, 2008 9:54 AM To: [EMAIL PROTECTED] Subject: Op codes removed from z/10 Does anyone know what these opcodes are? They are no longer supported on the z/10, but I can't find them in the Reference Summary E503 E504 E505 E506 E507 Cross-posted to IBM-Main Stephen Bielskie Assistant Vice President IT - z/OS Base Products - Princeton - KIUT57 IT - Mainframe Hardware - Princeton - KIUT54 CREDIT SUISSE Princeton, NJ Telephone : (609) 243-0711 Email :[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
If you have current program specs (other than the self-documenting assembler code) it may be easier to start there and write the C# code from scratch. However, I have yet to see a programming department that kept program specs up to date, so you may have to spend considerable time determining exactly what each program does beyond the scope of the original specs. If you wind up having to interpret every program, you face the problem of finding reliable assembler programmers who are also proficient in C#. I suggest finding good assembler programer contractors who can convert the code to specs, then handing the specs off to good C# programmers. Also, a one-to- one conversion is unlikely to be the best solution. By having the specs in hand, a few good C# programmers should be able to redesign the application (s) so they work well with C# programming practices and meet company standards. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Storage Alternation TRAP
Hi Thank you I will try out. George Kozakos wrote: Miklos Szigetvari wrote: How can I set an SA trap, to specify the BEFORE and AFTER values (i.e the content before the alternation and after ) ? You could use two SA SLIPs with TARGETID on the BEFORE value SLIP to activate the AFTER value SLIP. Regards, George Kozakos z/OS Function Test/Level 3 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: [EMAIL PROTECTED] Info: [EMAIL PROTECTED] Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
Thx -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John P. Baker Sent: Wednesday, June 25, 2008 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Op codes removed from z/10 E503SVC Assist E504Obtain Local Lock E505Release Local Lock E506Obtain CMS Lock E507Release CMS Lock These instructions comprised a part of the MVS Extended Facility, which provided performance improvements back in the days of MVS/XA and MVS/SP. John P. Baker -Original Message- From: IBM Mainframe Assembler List [mailto:[EMAIL PROTECTED] On Behalf Of Bielskie, Stephen Sent: Wednesday, June 25, 2008 9:54 AM To: [EMAIL PROTECTED] Subject: Op codes removed from z/10 Does anyone know what these opcodes are? They are no longer supported on the z/10, but I can't find them in the Reference Summary E503 E504 E505 E506 E507 Cross-posted to IBM-Main Stephen Bielskie Assistant Vice President IT - z/OS Base Products - Princeton - KIUT57 IT - Mainframe Hardware - Princeton - KIUT54 CREDIT SUISSE Princeton, NJ Telephone : (609) 243-0711 Email :[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
The were a number of linkage assist instructions that were never publicly by IBM documented to my knowledge. I did find a brief overview at the following web site: http://www.bixoft.com/english/opcde5.htm Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bielskie, Stephen Sent: Wednesday, June 25, 2008 8:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Op codes removed from z/10 Does anyone know what these opcodes are? They are no longer supported on the z/10, but I can't find them in the Reference Summary E503 E504 E505 E506 E507 Stephen Bielskie Assistant Vice President IT - z/OS Base Products - Princeton - KIUT57 IT - Mainframe Hardware - Princeton - KIUT54 CREDIT SUISSE Princeton, NJ Telephone : (609) 243-0711 Email :[EMAIL PROTECTED] == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Wed, 25 Jun 2008 05:55:16 -0700, Patrick Falcone [EMAIL PROTECTED] wrote: I agree and out of pure morbid curiosity, at this point, did you happen to issue a 'D GRS,C'? And if so did Latch Number 87 come back, a quiesce latch for a zFS file system. Just curious if other zFS support may be lacking.. D GRS,C ISG343I 09.15.40 GRS STATUS 670 NO ENQ RESOURCE CONTENTION EXISTS NO LATCH CONTENTION EXISTS D GRS,L,JOBNAME=ZFS ISG343I 09.15.53 GRS STATUS 672 LATCH DISPLAY FOR JOB ZFS NO LATCHES OWNED OR WAITED UPON D GRS,AN,WAITER ISG349I 09.20.55 GRS ANALYSIS 715 LONG WAITER ANALYSIS: ENTIRE SYSPLEX THERE ARE NO WAITING TASKS MATCHING THE INPUT SPECIFICATION D GRS,AN,BLOCKER ISG349I 09.21.03 GRS ANALYSIS 718 LONG BLOCKER ANALYSIS: ENTIRE SYSPLEX THERE ARE NO BLOCKING TASKS MATCHING THE INPUT SPECIFICATION D GRS,AN,DEPEND ISG349I 09.21.09 GRS ANALYSIS 734 DEPENDENCY ANALYSIS: ENTIRE SYSPLEX THERE ARE NO WAITING TASKS MATCHING THE INPUT SPECIFICATION -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
In a message dated 6/25/2008 9:17:49 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: ... a number of linkage assist instructions that were never publicly by IBM documented to my knowledge. IBM documented the five mentioned by the OP in an extremely thin generally available publication in ca. 1983 or 1984 that was titled something like S/370/XA Processor Assist. I believe that this book was also the first public documentation on the (at that time) new Control Register bit that governs Low Address Protection. I had a copy of the book for a decade or two. I also vaguely recall that another pair of assist instructions were to set and remove an FRR. Bill Fairchild Rocket Software **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
They were documented in a separate IBM publication on the MVS Extended Facility. I have a copy if anyone is interested. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Wednesday, June 25, 2008 10:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Op codes removed from z/10 The were a number of linkage assist instructions that were never publicly by IBM documented to my knowledge. I did find a brief overview at the following web site: http://www.bixoft.com/english/opcde5.htm Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES3 command equivalent to JES2's OUTDISP=KEEP
Hunkeler Peter (KIUK 3) wrote: Is there an equivalent JES3 option to the JES2 OUTDISP=KEEP option? Output with OUTDISP=KEEP will be printed and kept on spool after the print with OUTDISP=LEAVE (which is changed to KEEP once more when the output is release again). AFAIK, there is no direct equivalent to this idea of printing the exact same report over and over each time an operator releases it. It might be possible to provide a similar capability through user exit IATUX72. I'd have to study the flow to know for sure. Your question makes we wonder if Credit Suisse participated in the recent top-ten ranking of JES3 SHARE requirements. (Did you?) This ranking had not been performed since 1998 and there was lots of junk in the requirements data base. SHARE volunteers winnowed the requirements from 300+ down to around 90. (We unilaterally retired those we considered obsolete.) And, in an unprecedented move (at least as far as I'm aware), we opened up the top ten ranking process to the public. Here is the excerpt from my posting to JES3-L: |Of course, only SHARE participants can submit requirements. But, we've |decided to allow any member of the JES3 community, whom we judge to be |serious and sincere about the process, to help focus IBM's attention on |the highest priority requirements. (Naturally, we reserve the right to |reject any non-SHARE ballot that seems insincere. And, as always, it's |one vote per company.) The level of participation was good. The end of the voting was June 16. I'm not yet sure what the final results were. Full OUTDISP= support was definitely on the list and, if the community considered it important, it should make it to the top ten. At SHARE in Orlando, IBM pledged to use this information to help focus the development efforts of their new gaggle of JES3 developers -- recently in-sourced from India back to Rochester, MN USA. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
agreed 100% i would add that our 19000 inhouse cobol programs do not leave much alternative than to hope for a big life expectancy for our mainframe In some cases the choice is that there is no choice . be it cobol or some fancy software running only on some fancy OS for some fancy department . Bruno Sugliani zxnetconsult(at)free(dot)fr On Wed, 25 Jun 2008 07:38:49 -0600, Howard Brazee [EMAIL PROTECTED] wrote: On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve Comstock) wrote: What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Evaluate your needs and wants, compare them with the costs involved - just as you do with any other purchase. Some people compare computers with transportation. Sometimes a cargo ship is the best solution, other times, trains, large trucks, small trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling work better for particular tasks. Each tool has different standards, different costs, different strengths, and different weaknesses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Steve Comstock wrote: [...] So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? Two reasons: 1. Applications they use run on mainframes only. 2. For the same reason why Englishmen drive on left side. The change is risky and costly. Where are NEW customers of mainframe and z/OS? We sometimes see messages about another mainframe switched off. Where are the new projects? (disclaimer: I know, there are FEW) -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS 1.4 on a z10
Is anyone running z/OS 1.4 on a z10? I have a customer that wants to purchase a z10, but is not ready to upgrade their version of z/OS. I know the official party line is that nothing is supported prior to z/OS 1.7. But the customer does not care about being supported, only that it runs. Thanks. -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
Thanks Mark. You gotta wonder what happened to this support. It had to be working at some point, you would think. I wonder where it dropped. I'm laughing and I'm not gonna ask if there are any more commands that were issued or need to be for that matter. I promise! Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 25 Jun 2008 05:55:16 -0700, Patrick Falcone wrote: I agree and out of pure morbid curiosity, at this point, did you happen to issue a 'D GRS,C'? And if so did Latch Number 87 come back, a quiesce latch for a zFS file system. Just curious if other zFS support may be lacking.. D GRS,C ISG343I 09.15.40 GRS STATUS 670 NO ENQ RESOURCE CONTENTION EXISTS NO LATCH CONTENTION EXISTS D GRS,L,JOBNAME=ZFS ISG343I 09.15.53 GRS STATUS 672 LATCH DISPLAY FOR JOB ZFS NO LATCHES OWNED OR WAITED UPON D GRS,AN,WAITER ISG349I 09.20.55 GRS ANALYSIS 715 LONG WAITER ANALYSIS: ENTIRE SYSPLEX THERE ARE NO WAITING TASKS MATCHING THE INPUT SPECIFICATION D GRS,AN,BLOCKER ISG349I 09.21.03 GRS ANALYSIS 718 LONG BLOCKER ANALYSIS: ENTIRE SYSPLEX THERE ARE NO BLOCKING TASKS MATCHING THE INPUT SPECIFICATION D GRS,AN,DEPEND ISG349I 09.21.09 GRS ANALYSIS 734 DEPENDENCY ANALYSIS: ENTIRE SYSPLEX THERE ARE NO WAITING TASKS MATCHING THE INPUT SPECIFICATION -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Bruno Sugliani wrote: agreed 100% i would add that our 19000 inhouse cobol programs do not leave much alternative than to hope for a big life expectancy for our mainframe In some cases the choice is that there is no choice . be it cobol or some fancy software running only on some fancy OS for some fancy department . Ah, so do you need some training to keep your staff up to date on new features / options of COBOL? Or that fancy z/OS UNIX System Services? [Of course, it would have to be in English, although I'd be happy to work with an interpreter. Maybe someone on ibm-main would volunteer. :-) ] Bruno Sugliani zxnetconsult(at)free(dot)fr On Wed, 25 Jun 2008 07:38:49 -0600, Howard Brazee [EMAIL PROTECTED] wrote: On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve Comstock) wrote: What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Evaluate your needs and wants, compare them with the costs involved - just as you do with any other purchase. Some people compare computers with transportation. Sometimes a cargo ship is the best solution, other times, trains, large trucks, small trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling work better for particular tasks. Each tool has different standards, different costs, different strengths, and different weaknesses. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4 on a z10
Yes, running z/VM would be an option. On Wed, Jun 25, 2008 at 11:13 AM, John P Kalinich [EMAIL PROTECTED] wrote: Mark Pace of the IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/25/2008 10:07:28 AM: Is anyone running z/OS 1.4 on a z10? I have a customer that wants to purchase a z10, but is not ready to upgrade their version of z/OS. I know the official party line is that nothing is supported prior to z/OS 1.7. But the customer does not care about being supported, only that it runs. Is running VM an option? Regards, John K -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z9 Crypto Express2 usage
Rob, higher level of tape encryption to start. I have not seen regulatory requirements. Not sure about the TKE. Like I said, we are at the very beginning and I know next to nothing. I saw several of your posts from earlier this year. (were you at 5/3 in Cincinnati?) If you are now a gun for hire - we might be interested in some guidance, if the price is right. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E Error - Resolved
To clear this up for the list archive, we opened an ETR with IBM. Their take was that a bad copy of the original UO00396 had likely been applied. They had me reorder that service, APPLY REDO, and add the following: UO00446 UO00458 UO00497 UO00573 Looks to have corrected the problem. Thanks to all for the assistance and advice. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Pat Sent: Thursday, June 05, 2008 3:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: SMP/E Error - Resolved UO00335. Not in the PTS. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, June 05, 2008 2:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: SMP/E Error - Resolved On Thu, 5 Jun 2008 13:57:52 -0500, Miller, Pat [EMAIL PROTECTED] wrote: Like I say, I was skeptical. But I see no service in the CSI that hits it that has been applied since the serverpac install. What is the RMID of GIMLEVEL? Is that PTF still in your SMPPTS? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Wed, 25 Jun 2008 08:11:17 -0700, Patrick Falcone [EMAIL PROTECTED] wrote: Thanks Mark. You gotta wonder what happened to this support. It had to be working at some point, you would think. I wonder where it dropped. It worked for HFS, never for zFS apparently (what was IBM thinking?). And since there is no open APAR (that I can find) that references the INCOROUT for D OMVS,F,E, does that mean a requirement is needed to fix what is BAD. I'm laughing and I'm not gonna ask if there are any more commands that were issued or need to be for that matter. I promise! You might not ask... but I was still trying. And I found one that should do the trick! D OMVS,W (D OMVS,WAITERS) D OMVS,W BPXO063I 10.30.08 DISPLAY OMVS 136 OMVS 000F ACTIVE OMVS=(M8) MOUNT LATCH ACTIVITY: NONE FILE SYSTEM LATCH ACTIVITY: NONE OTHER WAITING THREADS: USER ASID TCB PID AGE -- ZELDENM 00B4 0098959833554812 00.00.19 IS DOING: ZFS OpenCall / Osi Wait FILE: ixm (20,5398) FILE SYSTEM: SYS1.OMVS.RESM81.XML.ZFS It doesn't tell you the file system is quiesced, but it is a single operator command that I can communicate to the console operators, my team, and the WebSphere team that should give enough of a hint that a quiesced zFS could be the problem. Easy enough to ask an operator to do over the phone. Explaining zfsadm would be more difficult. I'm not sure the operators even have OMVS segments in some environments. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Non-SMS GDG Issue
We had some corruption in TLMS which left us a broken tape GDG. TLMS was fixed and the dataset was recataloged using IEHPROGM. Now the chain for the GDG is broken. When I tried an ALTER with ROLLIN I got a message that it's a NON-SMS dataset and it didn't roll back in. Has anyone gone through this before and if so how did you fix it? So far I've not found anything in the manuals. TIA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need some CA-SPOOL/TCPIP routing help
Thanks Carmen, I appreciate any hints I can get at this point. One of our biggest issues is the I/P stack issue. ESF is on one stack and the printer is on another agencies network which is accessible through the other I/P stack. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Yukus, Mary J CIV USMEPCOM Sent: Tuesday, June 24, 2008 4:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Need some CA-SPOOL/TCPIP routing help Hi Everyone, Sorry, this is lengthy. I need some suggestions/direction to accomplish a task that may or may not be doable. We have a customer that needs to connect their Xerox printer to the mainframe (via a BARR system and network). We planned to use ESF to push the output to the BARR server. We ran into a stumbling block with the way our TCPIP stacks are defined. ESF runs on our primary TCPIP stack. The printer connection is within the user's TCPIPB stack. We can't change ESF to use the other stack since there are other printers that use it. If we try to connect through the main stack, we get nothing (which is what we should get on the main stack). If we bring up ESF on the TCPIPB stack we get the following 12:47:00 Gethostbyname 12:47:00 Socket 3 Bind port 515 from 0.0.0.0 port 721 12:47:00 Socket 3 Connect to port 515 from port 721 12:47:00 Connect errno=49. Destination host refused socket connection 12:47:00 Socket 3 Bind port 515 from 0.0.0.0 port 722 12:47:00 Socket 3 Connect to port 515 from port 722 12:47:00 Connect errno=49. Destination host refused socket connection We don't know where the error is, on our end or the users end where the BARR Server resides. The next problem is getting the output through ESF and onto a different TCPIP Stack. A suggestion was given to us that somewhere (such as a REXX exec) we should be able to tell ESF what stack the Xerox Printer/BARR server resides in and then route it out to that address. We do not have strong TCPIP experience and we are at a loss on how to accomplish this. Does anyone have any suggestions or other methods to get this to work? We're running out of ideas Thanks, Mary -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Wed, 25 Jun 2008 11:03:07 -0500, Mark Zelden [EMAIL PROTECTED] wrote: You might not ask... but I was still trying. And I found one that should do the trick! D OMVS,W (D OMVS,WAITERS) D OMVS,W BPXO063I 10.30.08 DISPLAY OMVS 136 OMVS 000F ACTIVE OMVS=(M8) MOUNT LATCH ACTIVITY: NONE FILE SYSTEM LATCH ACTIVITY: NONE OTHER WAITING THREADS: USER ASID TCB PID AGE -- ZELDENM 00B4 0098959833554812 00.00.19 IS DOING: ZFS OpenCall / Osi Wait FILE: ixm (20,5398) FILE SYSTEM: SYS1.OMVS.RESM81.XML.ZFS It doesn't tell you the file system is quiesced, but it is a single operator command that I can communicate to the console operators, my team, and the WebSphere team that should give enough of a hint that a quiesced zFS could be the problem. Easy enough to ask an operator to do over the phone. Explaining zfsadm would be more difficult. I'm not sure the operators even have OMVS segments in some environments. Hey that's neat ! Thanks Bruno Sugliani zxnetconsult(at)free(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Wed, 25 Jun 2008 08:49:56 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Hello, Yes and it could interesting to compare the size of parms that are sended with the size of parms that are expected in called subprogram, no? Did you already encounter such a problem? As a result, is there an abend or an unexpected behavior? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z9 Crypto Express2 usage
From your perspective, the crypto cards won't buy you much. All you get is a secure key repository and an API. Assuming the hardware is configured and activated, about all you have to do is allocate a couple of VSAM clusters, set up a couple of started tasks, set up some RACF profiles, and set the master key(s). An hour or three, tops. Note: the crypto coprocessors may not show as 'online' until after the master key(s) are set. Now you need some software to exploit the facility as well as some sort of key management strategy and infrastructure. Key management may be the biggest single challenge, IMHO. The facility may or may not be exploited by your tape encryption solution. While setting up ICSF may be trivial, deploying encryption is anything but. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Thinnes Sent: Tuesday, June 24, 2008 6:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: z9 Crypto Express2 usage Have a z9 with 2 Crypto Express2 cards we hope to use. Any suggested manuals for someone that has no experience with with ICSF or these cards? I reviewed the archives and found a pointer to Red Book SG24-7123 z9-109 Crypto update. I also am reviewing several ICSF manuals. Any other good sources? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
How do you define 'performance'? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 24, 2008 5:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Slow FTP transfer from z/OS to Unix Hal Merritt wrote: What do your test results show? What I've seen is some measurable amount of delay at each router. When the connections are improved from 100Mb to 1000Mb, the delays are about the same even though performance is drastically improved. [An unrelated aside. Based on this interesting chart, it looks like IPv6 is really starting to come online! http://mobitec.ie.cuhk.edu.hk/projects/IPv6/hops.html ] -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
Hal Merritt wrote: How do you define 'performance'? We test our network using ftp to transfer large zipped files. Our definition of 'performance' is KBytes/sec. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
In a message dated 6/25/2008 11:16:09 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: You might not ask... but I was still trying. And I found one that should do the trick! D OMVS,W (D OMVS,WAITERS) Wonder if it could be opened as 'Integrity APAR'? **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
In a message dated 6/25/2008 1:12:43 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: We test our network using ftp to transfer large zipped files. Our definition of 'performance' is KBytes/sec. Most of the big delays I can remember were auto-negotiate, mismatched MTU sizes along the way and bad packets. We had a sniffer on one of the switches that was pretty good at all of the above. Don't know where 'milking machines' came from but as we beat down the packet problems with 'packet shapers' many performance problems evaporated. **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
This has bit us several times in the past. If I remember correctly it caused various 0C4 and 0C1 type abends. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of J. Chiampi Sent: Wednesday, June 25, 2008 12:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problems that occur in production On Wed, 25 Jun 2008 08:49:56 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Hello, Yes and it could interesting to compare the size of parms that are sended with the size of parms that are expected in called subprogram, no? Did you already encounter such a problem? As a result, is there an abend or an unexpected behavior? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
I wonder if there is some repackaging along the way. My model assumes that a single packet traverses the network unchanged in any way. A fixed delay at the appliance works, but I don't understand how a packet that has to be transmitted twice would take the same amount of time as one transmitted only once. Unless the appliance were to begin transmitting the packet before it had completely arrived. The network speeds are not that relevant in this specific sub context. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, June 25, 2008 1:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Slow FTP transfer from z/OS to Unix Hal Merritt wrote: How do you define 'performance'? We test our network using ftp to transfer large zipped files. Our definition of 'performance' is KBytes/sec. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CEE3703I In HANC Control Block, the Eye Catcher is damaged.
It sounds like time to compile and run with SSRANGE turned on. This should (easily?) catch the problem. Schneiderwent, Craig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... You can have VS COBOL II modules linked with VS COBOL II and still run them without VS COBOL II run-time library, you can run them with LE library. We have only LE in the DFHRPL. Using ISRDDN I searched the Linklist/LPA concatenation for IGZ* modules and they are only found in hlq.CEE.SCEERUN and hlq.CEE.SCEERUN2. We appear to be in the category you describe. My thanks to those who replied here and on CICS-L, there doesn't appear to be anything (explicitly listed as that won't work) wrong with the construction of the module itself. And I see the abstract for John Monti's Orlando SHARE presentation 8209 Heaps of fun with LE Heaps says Have you seen a CEE0802C message saying your LE Heap control information was damaged? Well this session is for you. These problems are most often caused by application overlays. The speaker will guide you through the LE Heaps in a fun and interesting way to help you learn techniques and LE run-time options which can assist with finding the source of these problems. Lo, and behold, just a bit after the CEE3703I message in the subject line of this thread there is a CEE0802C Heap storage control information was damaged. message. So I now have something to read and point the apps people at. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
As the OP, I'm sorta inclined to resent this, but I know I was just whining some. Although I think zBoxes and z/OS plus zLinux are the no brainer way to go, I also recognize I am a pro mainframe bigot. My underlying concern, which I related in a later post is the real point. We now live in a world (z or Wintel or *nix) where downtime does not have to visibly happen. And customers are permitted to and should insist on 24/7 service. But the other fact is everyone (well almost) has a Window$ workstation on their desk that many reboot every day, and certainly (if updates are properly being applied) doesn't stay up more than a week or two. This leads to the mindset that downtime is acceptable. And maybe it is for many(most) applications. I don't include financial in that group, and I certainly don't include any related to public safety (Police, Fire, etc) in the group. I've always appreciated Ron's wise words in these fora, hope he doesn't take this personal :) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Hawkins Sent: Tuesday, June 24, 2008 9:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle Bruno. This thread, as with many on this topic, starts out with the assumption that UNIX, LINUX and Windows Server Operating Systems, along with server class hardware are no different to the Home PC they loaded up with Windows XP in order to play Warcraft, or the laptop they use for email and terminal emulators. It only goes downhill from there. It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. As Radoslaw said, I love Mainframes but I'm not blind. Those that wish to make a valid comparison between z/OS and other HA OS need to get their noses out of Windows and have a look at how HA is being done on other SERVER Operating Systems. In many cases it is not platform that provides the HA, but rather an application running on the OS like Veritas Cluster Server or HACMP. These HA applications won't even run on XP. And what I would give for backup software like Commvault or Netbackup on the Mainframe. Backup on Open System Server software is Light years ahead of anything on the MF, whether it's IBM or ISV software. It's like comparing a Ferrari to the first stone wheel... I like to take a wider view than the lint in my belly button... Ron PS For those that WOW, I'm a level 63 Human Warrior :) Thank you Ron I was feeling alone . i have been sometimes pulling out applications from mainframe in my shop and applied all good recipes from centralised processing ( dual computer rooms , dual replicated storage bays for dasds , dual network, load balancing , dual tape robotics and even ESX vmware to drag and drop servers on the fly) And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS linux , Windows data servers , AIX applications , etc ... ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
--snip On the one hand I hear that nothing beats the MF for reliability, security, recoverability, and so on. Then I hear people telling me not be so sure about that. So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? ---unsnip- In my not-so-humble opinion: Nothing will beat the MF in terms of overall performance. No business runs on strictly compute-bound or strictly I/O bound code; the mixture may vary but both capabilities are important to the business. While many desktops can compute with awesome speed today, they can't do large volumes of I/O in anything approaching a reasonable time frame. The MF can do thusands of I/O's per second, via multiple channels, but MIGHT not be quite as fast for a purely compute-bound program. Wake me up, if you can, when the non-MF platforms can multi-task with literally thousands of tasks and still get reasonable work done in a reasonable time frame. And whether we like it or not, the MF still has very high reliability, excellent security and a pretty D*** high degree of recoverability. And we've had 40+ years of practice in making improvements in all those areas. (I've seen as many as 4,000 Virtual Machines running in a VS/CMS environment and all were still getting sub-second terminal response time for trivial transactions! On a single 370/168!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
-snip-- They were documented in a separate IBM publication on the MVS Extended Facility. I have a copy if anyone is interested. unsnip If that's an electronic copy, I'd be VERY interested. Or you can contact me off-list.. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
... Back in the day, Tandem was the dominant fault-tolerant platform. However, for almost two decades, sysplex technology has given mainframes fault tolerance that Tandem can only dream of. So, it's not that Tandem's front end value is lessening but that they are no longer the only game in town. I do think Tandem (HP NonStop) front-end value is lessening because of decisions HP and especially software vendors have made recently. But I think you're exactly right about the fact that, if you have a highly available IBM mainframe backend, why do you still need a special queuing front-end? Quite simply you don't, and that's been the trend, to edit and to simplify for several reasons. ... I have no idea what's going on in the banking industry in general,; maybe reliance on Tandem is decreasing. But I see no move at this bank to move away from them. Our move towards higher availability has next to nothing to do with ATM support (Tandem's forte); it is driven by online banking support. I suspect that the ATM support will eventually start taking more advantage of the mainframe's high availability, but, as I said in a previous posting, the platform's availability has little to do with the need for something like Tandem. It's the applications; it's maintenance of the databases; etc. The HA front ends for ATMs allow near continuous ATM availability for customers without having to go though major costly redesigns and reprogramming. Bank IT deparments are pretty conservative in general, and the current financial environment isn't likely to inspire major changes. I suspect you will not see many banks that currently use Tandems stop using them because of high mainframe availability. I'd bet more on seeing IT staffs being cut, development put on hold, and greater dependance being put on whatever is in place right now. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
On Wed, 25 Jun 2008 15:09:08 -0500, Rick Fochtman wrote: -snip-- They were documented in a separate IBM publication on the MVS Extended Facility. I have a copy if anyone is interested. unsnip If that's an electronic copy, I'd be VERY interested. Or you can contact me off-list.. There is this: http://bitsavers.trailing-edge.com/pdf/ibm/370/SA22-7092-0_MVSAssists.pdf -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
Oops - appears to be slashIBM-MAIN-dotted! -Mark Vitale There is this: http://bitsavers.trailing-edge.com/pdf/ibm/370/SA22-7092-0_MVS Assists.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 25 Jun 2008 12:56:09 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: Nothing will beat the MF in terms of overall performance. That's like saying nothing will beat a cargo ship or train or 18 wheeler in terms of overall performance. But the measure of overall performance depends on our goals. I notice that the rising cost of oil have a variety of effects on how we transport things. Trains are getting more use relative to trucks. But we are also building greenhouses to redefine the problem of getting groceries from far away farmland to here. Same thing happens as our security, privacy, and even energy needs change how we do IS. And of course, size. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 25 Jun 2008 12:42:40 -0700, [EMAIL PROTECTED] (Gibney, Dave) wrote: We now live in a world (z or Wintel or *nix) where downtime does not have to visibly happen. And customers are permitted to and should insist on 24/7 service. But the other fact is everyone (well almost) has a Window$ workstation on their desk that many reboot every day, and certainly (if updates are properly being applied) doesn't stay up more than a week or two. The person in the next cubicle had a hard disk crash the other day. She basically used it as a workstation to access the MF and the Unix box - but she was dead in the water for several days. The mind set in most shops does not include making full backups of their PCs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4 on a z10
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/25/2008 11:07:28 AM: Is anyone running z/OS 1.4 on a z10? I have a customer that wants to purchase a z10, but is not ready to upgrade their version of z/OS. I know the official party line is that nothing is supported prior to z/OS 1.7. But the customer does not care about being supported, only that it runs. The format of the MP adjustment factors (supplied by the STSI instruction) changed in the z10, and without an SRM PTF to support this change you get 0C9 abends. I don't think VM would have any reason to virtualize the MP adjustment factors, so my guess would be that running under VM would not avoid this problem. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/25/2008 10:05:06 AM: E503 SVC Assist E504 Obtain Local Lock E505 Release Local Lock E506 Obtain CMS Lock E507 Release CMS Lock These instructions comprised a part of the MVS Extended Facility, which provided performance improvements back in the days of MVS/XA and MVS/SP. John P. Baker -Original Message- From: IBM Mainframe Assembler List [mailto:[EMAIL PROTECTED] On Behalf Of Bielskie, Stephen Sent: Wednesday, June 25, 2008 9:54 AM To: [EMAIL PROTECTED] Subject: Op codes removed from z/10 Does anyone know what these opcodes are? They are no longer supported on the z/10, but I can't find them in the Reference Summary E503 E504 E505 E506 E507 MVS use of the SVC assist was removed in MVS/ESA SP3.1.0 MVS use of the lock assists was removed in OS/390 2.10. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Op codes removed from z/10
On Wed, 25 Jun 2008 15:16:53 -0500, Tom Marchant m42tom- [EMAIL PROTECTED] wrote: ... There is this: http://bitsavers.trailing-edge.com/pdf/ibm/370/SA22-7092-0_MVSAssists.pdf SA22-7092-0 also documents a sixth instruction, ADD FRR (B242). All of those six instructions actually pre-dated XA. I still have a (paper) copy of GA22- 7079-0 IBM System/370 Assists for MVS dated 1981, that includes descriptions of those six instruction and also FIX PAGE (E502) and six tracing instructions in the range E508 to E50D. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS v1.7 JES2: StcInRdr vs. IntRdr
Hey there. I'm grasping at straws and am hoping someone remembers their JES2 internals. I've looked in the JES2 Innita Tuna? manual (Ch 2. Controlling JES2 processes) without success and can't find a RedBook that helps. Perhaps someone remembers or can point me to a Fine Manual. (I'll ETR otherwise.) Background: z/OS v1.7, DB2 v7. During our (peak) registration periods, we experience occasional, un-explainable slow-downs in 1-3 minute bursts on the order of 3-5 in a 2-3 day period. To date, no particular culprit has been positively identified. Aside from 100% CPU 20+ un-dispatched tasks, one reported symptom is an increasing number of DB2 threads (from OmegaMon) waiting for Stored Procedure start-ups ie. for WLM to start another address space. (@15 TCBs each) Sure enough, once the dust settles, there can be 10+ WLM address spaces that slowly disappear as idle. This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e-mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) As mentioned before, if there's no satisfactory consensus, I'll pursue an ETR and relay the response. Tks much folx. -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Non-SMS GDG Issue
What did your job look like? The IEHPROGRM docs I have say to use IDCAMS for this purpose. Linda Mooney -- Original message -- From: Daniel McLaughlin [EMAIL PROTECTED] We had some corruption in TLMS which left us a broken tape GDG. TLMS was fixed and the dataset was recataloged using IEHPROGM. Now the chain for the GDG is broken. When I tried an ALTER with ROLLIN I got a message that it's a NON-SMS dataset and it didn't roll back in. Has anyone gone through this before and if so how did you fix it? So far I've not found anything in the manuals. TIA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
On Wed, 25 Jun 2008 14:00:00 -0500, Hal Merritt wrote: I wonder if there is some repackaging along the way. My model assumes that a single packet traverses the network unchanged in any way. A fixed delay at the appliance works, but I don't understand how a packet that has to be transmitted twice would take the same amount of time as one transmitted only once. I'm not a network guy. You may be correct when considering the transmission of a single packet. However, when transferring a large file, consisting of thousands of packets, doesn't the router transmit and receive packets in parallel? In that case, wouldn't you expect that the difference in the total time when there are additional hops to be very small? Perhaps even smaller than the variations that occur due to the amount of network traffic. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FTP client ssl error
I am trying to do a SSL FTP from the mainframe to another server out side of our network. I can do a FTP SSL to the mainframe from outside of the network. I imported the CERT from the client and set it up. I searched the archives and this before and it looks like I have it defined correctly in RACF what have I missed. I can FTP from my PC to the server using the CERT I im ported to the mainframe. This is the error. 234 AUTH TLS OK. TLS enabled and waiting for negotiation. FC0674 authServer: secure_socket_open() FC0741 authServer: secure_socket_init() FC0754 authServer: secure_socket_init failed with rc = 8 (Certificate validation error) FC0907 endSecureConn: entered EZA2897I Authentication negotiation failed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL/PARM puzzle
See the section titled Continuing Parameter Fields Enclosed in Apostrophes in the JCL reference. One way to find that is to use the z/OS LibraryCenter here: http://publibz.boulder.ibm.com/bookmgr_OS390/libraryserver/zosv1r9/ From the initial page scroll down in the left frame to find MVS. Click the + to open the bookshelf. Scroll down till you see z/OS V1R9.0 MVS JCL Reference and click on it. Search in the book for something like continu* and you will hit all the discussions. You'll see Continuing Parameter Fields Enclosed in Apostrophes, 3.4.1.2 in the left frame. Click it and go to the section. Or, if I did this right, the line above may contain a clickable link. Roger Bolan infoprint.com Boulder, Colorado, USA P Think before you print -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS v1.7 JES2: StcInRdr vs. IntRdr
-snip--- Hey there. I'm grasping at straws and am hoping someone remembers their JES2 internals. I've looked in the JES2 Innita Tuna? manual (Ch 2. Controlling JES2 processes) without success and can't find a RedBook that helps. Perhaps someone remembers or can point me to a Fine Manual.(I'll ETR otherwise.) Background: z/OS v1.7, DB2 v7. During our (peak) registration periods, we experience occasional, un-explainable slow-downs in 1-3 minute bursts on the order of 3-5 in a 2-3 day period. To date, no particular culprit has been positively identified. Aside from 100% CPU 20+ un-dispatched tasks, one reported symptom is an increasing number of DB2 threads (from OmegaMon) waiting for Stored Procedure start-ups ie. for WLM to start another address space. (@15 TCBs each) Sure enough, once the dust settles, there can be 10+ WLM address spaces that slowly disappear as idle. This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e-mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) As mentioned before, if there's no satisfactory consensus, I'll pursue an ETR and relay the response. Tks much folx. --unsnip- Neil, what's the observed CPU utilization of your JES2? If it's not really high, I'd suggest you look elsewhere. It's been a long time since I looked in this area, but IIRC, STC's take a slightly different path through JES2 processing. A more likely culprit might be AS-Create; even more likely, IMHO, a ENQ/DEQ contention issue. JES2 uses something called a PCE, a Process Control Element, to represent multiple INTRDR's, rather than TCB's. They're managed internally by JES2 and typically run fairly quickly. I'm not sure, but I think conversion is done under a PCE as well, so the CPU time involved would be attributed to JES2. How many INTRDR's do you have defined? I don't know if you can specify the number of conversion tasks allowed or not; last time I tried to care, I couldn't specify a number for conversion tasks, but I could specify up to 10 INTRDR's. Without a much broader picture of your system, it's going to be hard to make any definitive diagnosis. Are you running RMF? I like RMF, with a 10-minute recording interval. If you'll do that, over a period where you're affected by this issue, and send me the reports, beginning two periods before and ending two periods after, I'll try and give you some pointers. (ZIP the reports, please.) :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Sequential compressed (on disk) - how to tell?
Howdy do. When I have an open SAM DCB (OUTPUT, if that matters) I want to be able to find out if the data set is a DASD compressed data set. Can this be done? AFAIK, compressed sequential data sets must be extended-format data sets, but extended-format data sets do not have to be compressed data sets. When using a DCBE with the DCB, DCBENSTR can be tested and if zero the data set is not extended format - and therefore I think can't be a compressed data set. But, if DCBENSTR is non-zero, then the data set is an extended-format (and therefore DASD) data set, but can I tell if it is a compressed data set or not? (I only mention DASD explicitly here so we don't go down the tape compaction cul-de-sac.) Thanks a bunch. Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP client ssl error
Check the cert's Cert Auth chain. From: IBM Mainframe Discussion List on behalf of Michael Saraco Sent: Wed 6/25/2008 5:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FTP client ssl error I am trying to do a SSL FTP from the mainframe to another server out side of our network. I can do a FTP SSL to the mainframe from outside of the network. I imported the CERT from the client and set it up. I searched the archives and this before and it looks like I have it defined correctly in RACF what have I missed. I can FTP from my PC to the server using the CERT I im ported to the mainframe. This is the error. 234 AUTH TLS OK. TLS enabled and waiting for negotiation. FC0674 authServer: secure_socket_open() FC0741 authServer: secure_socket_init() FC0754 authServer: secure_socket_init failed with rc = 8 (Certificate validation error) FC0907 endSecureConn: entered EZA2897I Authentication negotiation failed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
