Re: FW: Workable Mainframe Debuggers
David Logan wrote: Apologies of a sort about this email. My outlook ... Accepted of course, outlook should be renamed 'Look Out! Buggy Software' ... :) I use Windows Vista with Office 2007 ... I *strongly* recommend *against* it if anyone is thinking about it ... Cool! That is one of the best recommendations I saw on IBM-MAIN! :) I'm living on xp with office 2003. Yep, 5 year old software, I know. grin Groete / Greetings Elardus Engelbrecht -- 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: SMF in System Logger
Jim Holloway [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] com... We are beginning to test SMF in logstreams and so far, so good. Like others have mentioned, I really, really want the ability to delete records from the logstream programmatically after I've extracted them, but I can wait. Based on our experiences with VSAM SMF recording over the years we've decided to use a 2 day RETPD for SMF. I do, however, have some nits to pick: 1.) Logstream Structure Names: The doc is vague on what to name the structures. Every CF structure I've worked with, at the least said Structure names must begin with blah-blah. Not so here. I knew that IBM reserved the string SYS for itself when naming structures, so I arbitrarily picked SYSSMF_System_Name_Record_Type. I would've expected at the least, Name the structure whatever you want. The SMF manual refers you to the Setting up a Sysplex manual which doesn't address the specifics required for SMF. 2.) The IBM CFSizer webpage has no tools for helping you size your Jim, Keep in mind that the structures are for the System Logger, not for SMF. SMF uses the logstream and System Logger uses the structure. I have never seen any naming requirements for structures used by System Logger. I even started naming the Logger structures L_** to recognize them as System Logger structures. So you can name them as you like. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C++ Workable Mainframe Debuggers
Dave Cole writes: We are on the verge of publishing C Source code support (c/XDC) to beta testers. That's excellent. Thanks, Dave, for getting me more up-to-date. Side note: Another dividing line for the debuggers seems to be whether they support 64-bit code or not. z/XDC and IBM Debug Tool do, to pick two examples. So I would advise the original poster to check that aspect also. It's quite likely the C++ programmers will want 64-bit support -- if not now, then soon. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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: C++ Workable Mainframe Debuggers
Hi Unforunatly after several years of tests and a number of PMR's etc. etc we think the IBM C++ debugger is unusable for a complex applications We still use a number of printfs to debug C++ Bill Klein wrote: David, This note makes it appear that what you are looking for is a C++ application debugger. I haven't read all of the notes in the thread, but making this clear in the subject may help getting more responsive replies. Therefore, I have added C++ to the subject. David Logan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which is completely unusable to me. We write C++ programs here. My main app is something like 200 object modules. When I write a Hello world test app, fire it up under IBMs debug tool, it works great. When I try to debug our actual application, either the size or complexity is such that it just hacks up hairballs and dies. So I have filled my sources full of DEBUGX lines that I turn and off by module, and debug in batch via what turn out to be CEEMSG's. So are there viable alternatives to IBMs debug tool, or is this the one? If this is the one, I will have to give it another go so that I can explain in detail how it behaves badly. David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Friday, April 11, 2008 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Workable Mainframe Debuggers On Fri, Apr 11, 2008 at 12:35 PM, David Logan [EMAIL PROTECTED] wrote: I was wondering if there are any function debuggers on z/OS these days. Our shop is currently using z/OS 1.5, and the IBM provided LE debugger (via the LE TEST options) is completely unusable for us. It always has been. What suggestions might other people have? -- 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: Installers (Was: IBM announcements)
Regarding same ISV products in a common zone. Some products I have seen in the past have intersecting modules and can result in issues depending on the final linklist order. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: Installers (Was: IBM announcements)
It is also worth remembering that although the ISV can request a three-character element prefix from the IBM registry - there is no guarantee that all ISVs are adhering to the same standard. Also, even if all parties are using their element prefixes - what about the associated PTF and APAR names ? For the above two reasons, I always advise customers to install MXI into its own TGT and DLIB zones - however the final choice is always down to them. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel McLaughlin Sent: 14 April 2008 11:55 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Installers (Was: IBM announcements) Regarding same ISV products in a common zone. Some products I have seen in the past have intersecting modules and can result in issues depending on the final linklist order. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: Installers (Was: IBM announcements)
snippage For the above two reasons, I always advise customers to install MXI into its own TGT and DLIB zones - however the final choice is always down to them. end of snippage Would rather spend an extra few hundred cylinders of space and isolate my products than mix them up and try to undo a Gordian knot. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: IBM sites on Google Maps
In [EMAIL PROTECTED], on 04/10/2008 at 01:08 PM, [EMAIL PROTECTED] said: I stayed in a lot of hotels in the Winchester area whilst working at Hursley, and couldn't help but notice that at least two of them had their toilet facilities serviced and cleaned by a company called CICS.. I makes sense that they never heard of the product, but why would a travel agency call itself DOA? I've been hearing ads for a local firm with that name. For that matter, we have a barber shop called Sweeney Todd's; I don't know if they also sell pasties. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Installers (Was: IBM announcements)
In [EMAIL PROTECTED], on 04/10/2008 at 08:08 AM, Edward Jaffe [EMAIL PROTECTED] said: Keep in mind that ServerPac is an SMP/E bypass. It _restores_ SMP/E zones rather than installing into them. Keep in mind that you are talking about a specific step within ServerPac, not about the services that ServerPac provides for constructing dialogs. I don't believe that Art suggested that ISV's should use the existing ServerPac jobs, just the structure that manages them. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCF (was Re: System z10 announcement (in English))
In [EMAIL PROTECTED], on 03/04/2008 at 06:26 PM, Roger Bolan [EMAIL PROTECTED] said: Would you guys stop talking about DCF (Document Composition Facility, 5748-XX9) a.k.a. Script in the past tense? It is still available for z/OS, z/VM, and z/VSE. Yes, but aren't DCF, BookMaster and BookManager MVS all functionally stabilized? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. This observation led to the following idea, which I had previously advanced only to a select few through verbal conversation: Are you aware of extended indirect cataloging? If not, read up on SYMBOLICRELATE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Sas itrm
My management is interested in this product. I was wondering, how many People are using it, and what are there thoughts.Thank You. Bill Carroll EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- 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: DCF (was Re: System z10 announcement (in English))
That doesn't necessarily make them DEAD. And with B2H there's a certain element of continued vitality. Slight, mind you. :-( Martin (who uses Bookie and B2H every day) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sas itrm
On Mon, 2008-04-14 at 08:27 -0400, Carroll, William wrote: My management is interested in this product. I was wondering, how many People are using it, and what are there thoughts.Thank You. I wouldn't even consider installing it on the the mainframe again (not that I get any input to those decisions). Awful product to get working with OMVS and RACF. And their support teams (in this part of the world anyway) don't even appear to understand the environment. Shane ... -- 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
Xephon, are they still in business?
Is Xephon still in business? I'm subscribed to their TCP/SNA quarterly, but I have not received the March 2008 issue yet. It's not posted to their web site either and so far I have not had any response from them when I asked about it via their contact page. Thanks Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) -- 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: FW: Workable Mainframe Debuggers
Every once in a while someone pulls up a debugger tool, intending on having that skill in our resume. But when we actually need to debug, we go back to the old way - displays in the code. -- 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: Xephon, are they still in business?
Yes, they're in business, but they're owned now by zJournal. Try their new address - http://www.xephonusa.com On Mon, 14 Apr 2008 06:17:31 -0700, Mark T. Regan, K8MTR netsfw- [EMAIL PROTECTED] wrote: Is Xephon still in business? I'm subscribed to their TCP/SNA quarterly, but I have not received the March 2008 issue yet. It's not posted to their web site either and so far I have not had any response from them when I asked about it via their contact page. Thanks Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) -- 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: FW: Workable Mainframe Debuggers
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee Sent: Monday, April 14, 2008 8:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Workable Mainframe Debuggers Every once in a while someone pulls up a debugger tool, intending on having that skill in our resume. But when we actually need to debug, we go back to the old way - displays in the code. Hum, I know for a fact that our people use Xpeditor, especially in CICS. How? Because they complain any time something doesn't work the way they think that it should. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)
On Sun, 13 Apr 2008 02:51:34 +, Ted MacNEIL [EMAIL PROTECTED] wrote: I often see SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even though the MLQ is redundant. I agree with the redundancy argument; what's wrong with each product having the same library name(s) at every site? Hard to change that stuff in a production environment... well, maybe not hard, just a PITA when there are batch processes and people with their own clists etc. In production, standards should be enforced, so it won't become a PITA. (changed the subject since this has nothing to do with debuggers) What do local production standards have to do with the sysres names chosen for sysres dsns (perhaps years and years ago)? How would standards make it any easier to change? 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: TRANSLATE inst with DAT on
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. [EMAIL PROTECTED] writes: The Prin of Operations, programming notes on using the TR with DAT on, state that there will be a performance hit if the second operand actually crosses the 4096 line. This is because it will do a 'mock' execution first. Assuming DAT on, is the performance hit related to the possibility that the following 4096 page is not in virtual memory? way back on 360/67 ... (actually all 360s) TR used to test start start+255 (end) address of the table ... which met that if it crossed a 4k page ... it would catch both ... aka page fault both pages ... before starting instruction execution. somewhere along the way ... something was raised that TR only uses that much of the table that the input data-stream might used ... for instance, if the translation input stream only had values 0-9 ... and the table was within 256 bytes of the end of an addressable region ... then the instruction might fail (with start+256 precheck) ... even tho it otherwise could succesfully execute. so the TR instruction was fixed ... if the table start is within 256 bytes of the end of an addressable boundary... it pre-executes the instruction to see if any input stream bytes would index the table across the boundary. this would also theoritically have been a problem with 2k key fetch protect ... and the table was within 256 bytes of a 2k boundary (with the next 2k, fetch protected) and the input data stream never indexed anything (in the table) across the addressable boundary. a past thread that also got into this subject: http://www.garlic.com/~lynn/2005j.html#36 A second look at memory access alignment http://www.garlic.com/~lynn/2005j.html#37 A second look at memory access alignment http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment http://www.garlic.com/~lynn/2005j.html#40 A second look at memory access alignment http://www.garlic.com/~lynn/2005j.html#43 A second look at memory access alignment http://www.garlic.com/~lynn/2005j.html#44 A second look at memory access alignment -- 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: C++ Workable Mainframe Debuggers
Does C Source code support also mean C++? David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Sunday, April 13, 2008 5:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C++ Workable Mainframe Debuggers Cole Software's z/XDC - no We are on the verge of publishing C Source code support (c/XDC) to beta testers. More soon. Dave Cole At 4/13/2008 05:53 AM, you wrote: If you're debugging C/C++ on z/OS: 1. There's dbx for UNIX System Services (only): http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html No charge. 2. IBM Debug Tool for z/OS is available. IBM has introduced a new version annually for years now, so you want to stay current and take a fresh look if you remember an old version. Version 7, in particular, introduced some substantial C++ related improvements. Version 8 is current. I see a lot of old Debug Tool installed out there, unfortunately. You can license Debug Tool as MLC or, in the form of the Debug Tool Utilities Advanced Functions superset product, as OTC with subscription. As you prefer. Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTUAF) Version 7, so please try to get your z/OS release updated as soon as you can, at least for the development LPAR(s) where you're most likely to be debugging. You may be able to work with IBM to order DT or DTUAF Version 8 and arrange temporary use of Version 7; can't hurt to ask. Actually, as I write this Debug Tool V7 MLC is still orderable so no harm there, but for reasons of subscription you'll want to order DTUAF V8 if you go the OTC route. For graphical debugging use Rational Developer for System z (or WebSphere Developer Debugger for System z) in conjunction with Debug Tool (or DTUAF). I think those tools also provide graphical debugging with dbx now. Very slick. A certain popular IBM-MAIN training firm has a course on C/C++ debugging. Details here: http://www.trainersfriend.com/C_courses/N735descr.htm 3. There are a number of commercial debugger products for z/OS, most already mentioned. However, many (all?) of them don't support C++. Here's the latest information I have, and someone please correct me if my information is out of date: Cole Software's z/XDC - no CA-InterTest - no Compuware's Xpediter - C yes, C++ ? Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes, C++ ? Macro4's Tracemaster - no MacKinney Systems' Track and Xray - no ASG's (formerly Viasoft's) SmartTest - no Serena's StarTool ATD - product withdrawn? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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 -- 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: Workable Mainframe Debuggers
On Sat, 12 Apr 2008 21:42:01 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: Is there somewhere a customer who has an esthetic dislike for SYS1 and uses an alternative HLQ for production data sets? Even today the default names in ServerPac don't have SYS1 for the products I mentioned. The names are ISP.*, ISF.*, GIM.*, etc. It isn't a matter if dislike so much as it is a matter of history and not changing data set names that may be used in production and by end users. The first MVS system I worked on was an Express system (MVS SP 1.3) and I'm pretty sure I remember all those different HLQs. When I upgraded to MVS/XA I changed it all.Now try and do the same thing after another 20+ years of MVS history at a shop. Like I said... PITA. :-) 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: Consistent Data Set Names (Was: Workable Debuggers ...)
On Sun, 13 Apr 2008 20:07:41 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. JCLIN LLQ must equal the DDDEF name. There is no requirement that a DDDEF of LINKLIB point to hlq.LINKLIB. It can point to SCHMUEL.METZ and SMP/E will happily go on its way. 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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)
I happen to like having SYS1.** for (all) IBM targets. Always had a RACF rule for it - and a group SYS1 for that matter. Nowadays have similar for the OMVS started tasks. And yes, I go change all the ServerPac dsnames that need it - not helped by the mish-mash of names shipped. I'm sure I've beaten up on Marna about that. I *hate* it when I go into an AD/CD (derived) shop that has god-who-knows-how-many HLQs for system targets. I can work with whatever the customer dictates, but I also know where I can work most effectively. I work with what they give me - they pay the bill after all. Shane ... -- 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: Authorized Rexx Assembler Function
On Fri, 11 Apr 2008 16:56:56 -0400, Gerhard Postpischil [EMAIL PROTECTED] wrote: Oops. I completely forgot - I have a modified version of the STEPLIB program, that has an optional APF operand to authorize the libraries. Once that's done the authorized programs will run correctly; it's a great time saver when debugging new or heavily modified programs, since it can be done out of a test library. That would allow an authorized program to load a module from an otherwise unauthorized STEPLIB. It won't let you actually start running something as APF authorized, though. Getting something to start running authorized requires use of a function like IKJEFTSR, or TESTAUTH. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- 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
C++ Workable Mainframe Debuggers
Just a plug for SHARE. If you work for a SHARE member organization, the LNGC project does accept requirements for the various debugging tools. If there are specific features that you think should be added to IBM debuggers, please consider opening up SHARE requirements for them. Obviously, requirements can also be submitted concerning debugging COBOL, PL/I, or C as well. My guess is that most HLASM debugging requirements would go to the ASM project, but if submitted to LNGC, we would make certain that they, too, received user and IBM attention. Miklos Szigetvari [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi Unforunatly after several years of tests and a number of PMR's etc. etc we think the IBM C++ debugger is unusable for a complex applications We still use a number of printfs to debug C++ Bill Klein wrote: David, This note makes it appear that what you are looking for is a C++ application debugger. I haven't read all of the notes in the thread, but making this clear in the subject may help getting more responsive replies. Therefore, I have added C++ to the subject. David Logan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which is completely unusable to me. We write C++ programs here. My main app is something like 200 object modules. When I write a Hello world test app, fire it up under IBMs debug tool, it works great. When I try to debug our actual application, either the size or complexity is such that it just hacks up hairballs and dies. So I have filled my sources full of DEBUGX lines that I turn and off by module, and debug in batch via what turn out to be CEEMSG's. So are there viable alternatives to IBMs debug tool, or is this the one? If this is the one, I will have to give it another go so that I can explain in detail how it behaves badly. David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Friday, April 11, 2008 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Workable Mainframe Debuggers On Fri, Apr 11, 2008 at 12:35 PM, David Logan [EMAIL PROTECTED] wrote: I was wondering if there are any function debuggers on z/OS these days. Our shop is currently using z/OS 1.5, and the IBM provided LE debugger (via the LE TEST options) is completely unusable for us. It always has been. What suggestions might other people have? -- 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: C++ Workable Mainframe Debuggers
Thanks for the (C++) subject update, Bill. It's one of those cases where I work in it every day, so I forget the rest of the world doesn't know what I do :) Next, based on various other responses, it's good to know that IBMs debug tool is unusable for others when it comes to C++. At least it's not just me, although I am rather surprised that IBM is unable to get a functional debugger for the language. And, last but not least, a direct response to your email below: I would lobby for a functional C++ debugger...forget the features, unless that's considered a feature. David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Monday, April 14, 2008 8:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: C++ Workable Mainframe Debuggers Just a plug for SHARE. If you work for a SHARE member organization, the LNGC project does accept requirements for the various debugging tools. If there are specific features that you think should be added to IBM debuggers, please consider opening up SHARE requirements for them. Obviously, requirements can also be submitted concerning debugging COBOL, PL/I, or C as well. My guess is that most HLASM debugging requirements would go to the ASM project, but if submitted to LNGC, we would make certain that they, too, received user and IBM attention. Miklos Szigetvari [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi Unforunatly after several years of tests and a number of PMR's etc. etc we think the IBM C++ debugger is unusable for a complex applications We still use a number of printfs to debug C++ Bill Klein wrote: David, This note makes it appear that what you are looking for is a C++ application debugger. I haven't read all of the notes in the thread, but making this clear in the subject may help getting more responsive replies. Therefore, I have added C++ to the subject. David Logan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which is completely unusable to me. We write C++ programs here. My main app is something like 200 object modules. When I write a Hello world test app, fire it up under IBMs debug tool, it works great. When I try to debug our actual application, either the size or complexity is such that it just hacks up hairballs and dies. So I have filled my sources full of DEBUGX lines that I turn and off by module, and debug in batch via what turn out to be CEEMSG's. So are there viable alternatives to IBMs debug tool, or is this the one? If this is the one, I will have to give it another go so that I can explain in detail how it behaves badly. David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Friday, April 11, 2008 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Workable Mainframe Debuggers On Fri, Apr 11, 2008 at 12:35 PM, David Logan [EMAIL PROTECTED] wrote: I was wondering if there are any function debuggers on z/OS these days. Our shop is currently using z/OS 1.5, and the IBM provided LE debugger (via the LE TEST options) is completely unusable for us. It always has been. What suggestions might other people have? -- 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: Authorized Rexx Assembler Function
Walt Farrell wrote: That would allow an authorized program to load a module from an otherwise unauthorized STEPLIB. It won't let you actually start running something as APF authorized, though. Getting something to start running authorized requires use of a function like IKJEFTSR, or TESTAUTH. While I haven't tried this under z/OS, I can assure you that it works quite well under all earlier systems I used it on, from MVS to OS/390. Obviously it's unfit for use on a production system, as the auditors would have fits, but it saves a lot of time on a sandbox. Gerhard Postpischil Bradford, VT -- 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 names (was: Consistent Data Set Names)
On Mon, 14 Apr 2008 09:33:58 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: On Mon, 14 Apr 2008 08:49:16 -0500, Mark Zelden wrote: JCLIN LLQ must equal the DDDEF name. There is no requirement that a DDDEF of LINKLIB point to hlq.LINKLIB. It can point to SCHMUEL.METZ and SMP/E will happily go on its way. Is that true other than for SYSLMOD in binder steps? I'm accustomed to thinking that for all others task DDNAME is equal to DDDEF name (possibly modified by alternate DDNAME list). But, come to think of it, I don't believe I've ever coded JCLIN other than for binder steps. OK. I RTFM. I see: 9.7.4 SMP/E V3R4.0 Commands 9.7.4 Processing copy steps When scanning the copy input, SMP/E assumes the ddnames of the statement are the same as the lowest-level qualifier of the data set referred to. Gasp! TMI! I can think of at least 5 names: 1. The DDDEF name. 2. The LLQ of the DSNAME in the DDDEF (also as catalogued). 3. The DDNAME in the JCLIN DD statement. 4. The LLQ of the DSNAME appearing in the JCLIN DD Statement. 5. The DDNAME in the COPY command in SYSIN. The RM tells me that (clearly) (5) must match either (ambiguously) (4) or (2). May I then assume that (1) and (3) (and one of either (4) or (2)) are irrelevant and can be anything I want? I think the doc isn't really correct there.It is a convention to make the LLQ match the DDDEF. But it is the DDDEF that matters, not the DSNAME. To summarize: 1 is relevant, 2 is not (the DSN does not matter), 3 is not not (it is the LLQ of the DSN, not the DDNAME that matters for JCLIN [1], 4 is relevant, 5 is relevant. [1] From the same manual on JCLIN: The ddname for a distribution library or target library should match the lowest-level qualifier of the data set name. This is not a requirement, but rather a recommendation to help you specify the data sets used by SMP/E. 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
COBOL / VSAM question.
I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Xephon, are they still in business?
Hi! Just in case if you've not noticed. Xephon stopped sending printed issues and it's just pdf format such that each subscriber can download and print it if you like. But...they have've also changed their pricing too for new and existing customers. Check the web site. Cheers Timur -- From: Mark T. Regan, K8MTR [EMAIL PROTECTED] Sent: Monday, April 14, 2008 3:17 PM Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Subject: Xephon, are they still in business? Is Xephon still in business? I'm subscribed to their TCP/SNA quarterly, but I have not received the March 2008 issue yet. It's not posted to their web site either and so far I have not had any response from them when I asked about it via their contact page. Thanks Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) -- 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: FW: Workable Mainframe Debuggers
On Fri, 11 Apr 2008 10:35:07 -0600, David Logan [EMAIL PROTECTED] wrote: I was wondering if there are any function debuggers on z/OS these days. Our shop is currently using z/OS 1.5, and the IBM provided LE debugger (via the LE TEST options) is completely unusable for us. It always has been. What suggestions might other people have? Xpediter does not too bad a job. They do have a module to debug C code. Is Simon and Oliver still around. I remember having evaluated this 15 odd years ago. Don't remember why we didn't retain it. There is also Intertest. Not bad at all. I am sure there must be some others as well. Have you tried Google? Cheers, Jantje. -- 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: Authorized Rexx Assembler Function
On Mon, 14 Apr 2008 10:44:31 -0400, Gerhard Postpischil wrote: Walt Farrell wrote: That would allow an authorized program to load a module from an otherwise unauthorized STEPLIB. It won't let you actually start running something as APF authorized, though. Getting something to start running authorized requires use of a function like IKJEFTSR, or TESTAUTH. While I haven't tried this under z/OS, I can assure you that it works quite well under all earlier systems I used it on, from MVS to OS/390. Obviously it's unfit for use on a production system, as the auditors would have fits, but it saves a lot of time on a sandbox. I don't see how it really helps on a sandbox. What's so hard about adding your test library to the APF list? -- 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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)
I also like making SYS1. qualifiers for all of the IBM target datasets. When I was still at PH Mining, I would consolidate all of the ISPF libraries by type. Instead of having a bunch of ISPPLIBs, SLIBs, TLIBs, etc., I changed the DDDefs to all point to SYS1.ISPPLIB, SYS1.ISPSLIB, SYS1.ISPTLIB, etc. That way, in the logon proc and in the system libraries, there was one set of libraries. I never had any problems with doing it that way. It took a while longer setting it up on the Serverpac, but I think the results were worth it. Eric Shane [EMAIL PROTECTED] wrote: I happen to like having SYS1.** for (all) IBM targets. Always had a RACF rule for it - and a group SYS1 for that matter. Nowadays have similar for the OMVS started tasks. And yes, I go change all the ServerPac dsnames that need it - not helped by the mish-mash of names shipped. I'm sure I've beaten up on Marna about that. I *hate* it when I go into an AD/CD (derived) shop that has god-who-knows-how-many HLQs for system targets. I can work with whatever the customer dictates, but I also know where I can work most effectively. I work with what they give me - they pay the bill after all. Shane ... -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
SMP/E names (was: Consistent Data Set Names)
On Mon, 14 Apr 2008 08:49:16 -0500, Mark Zelden wrote: JCLIN LLQ must equal the DDDEF name. There is no requirement that a DDDEF of LINKLIB point to hlq.LINKLIB. It can point to SCHMUEL.METZ and SMP/E will happily go on its way. Is that true other than for SYSLMOD in binder steps? I'm accustomed to thinking that for all others task DDNAME is equal to DDDEF name (possibly modified by alternate DDNAME list). But, come to think of it, I don't believe I've ever coded JCLIN other than for binder steps. OK. I RTFM. I see: 9.7.4 SMP/E V3R4.0 Commands 9.7.4 Processing copy steps When scanning the copy input, SMP/E assumes the ddnames of the statement are the same as the lowest-level qualifier of the data set referred to. Gasp! TMI! I can think of at least 5 names: 1. The DDDEF name. 2. The LLQ of the DSNAME in the DDDEF (also as catalogued). 3. The DDNAME in the JCLIN DD statement. 4. The LLQ of the DSNAME appearing in the JCLIN DD Statement. 5. The DDNAME in the COPY command in SYSIN. The RM tells me that (clearly) (5) must match either (ambiguously) (4) or (2). May I then assume that (1) and (3) (and one of either (4) or (2)) are irrelevant and can be anything I want? -- gil -- 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: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 9:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL / VSAM question. I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. SNIP An 88 on the file status label to handle 00 97 is what we did for shops that migrated from VSE to MVS (or z/OS). That a VERIFY was done as part of OPEN is not a problem in 99.99% of the cases as far as we could ever see. So, no, I don't think you are blowing smoke. If the share options caused the OPEN to fail, that would be an entirely different animal. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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: Xephon, are they still in business?
It is too bad that they only give the option to print the older ones. It would be nice to see a table of contents before having to print the hole thing. A little step backwards. Regards, Herman Stocker -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of AlpTim1 Sent: Monday, April 14, 2008 10:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Xephon, are they still in business? Hi! Just in case if you've not noticed. Xephon stopped sending printed issues and it's just pdf format such that each subscriber can download and print it if you like. But...they have've also changed their pricing too for new and existing customers. Check the web site. Cheers Timur -- 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 The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. The sender's employer is not liable for any loss or damage arising in any way from this message or its attachments. -- 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: Consistent Data Set Names (Was: Workable Debuggers ...)
Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. This observation led to the following idea, which I had previously advanced only to a select few through verbal conversation: Are you aware of extended indirect cataloging? If not, read up on SYMBOLICRELATE. I'm familiar with indirect cataloging -- substituting a system symbol for the volume name. (We recommend this as the best way to support large configurations with multiple operating systems and/or product releases.) SYMBOLICRELATE is an entirely different concept. It is called _extended alias_ support and allows you to refer to one data set using an alternate name. I agree this appears to be a good way to achieve the desired objective using existing operating system facilities. However, when I experimented with this a while back, I found that it worked as expected only when the HLQs of the base name and alias were the same -- or more precisely -- expected to be in the same catalog. I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create 'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID are cataloged in a user catalog. Data sets starting with SYS1 are cataloged in the master catalog. Try as I might, I could not figure out how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of 'MYUID.BASE'. (Perhaps I overlooked something.) The above restriction should not be important in most if not all system data set cases. Indeed, the example of SYS1.SBLSxxx vs SYS1.IPCS.SBLS is a classic example of where extended aliases would be applicable. Seems like ServerPac could distribute a procedure/program to create/issue the appropriate DEFINE ALIAS statements for any data sets whose HLQs were changed from the delivered defaults. -- 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: FW: Workable Mainframe Debuggers
On 14 Apr 2008 06:29:28 -0700, [EMAIL PROTECTED] (McKown, John) wrote: Every once in a while someone pulls up a debugger tool, intending on having that skill in our resume. But when we actually need to debug, we go back to the old way - displays in the code. Hum, I know for a fact that our people use Xpeditor, especially in CICS. How? Because they complain any time something doesn't work the way they think that it should. We don't have Xpeditor nor CICS. That might be significant. -- 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: Xephon, are they still in business?
That's the web site address I went to. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) - Original Message From: Doc Farmer [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, April 14, 2008 9:27:45 AM Subject: Re: Xephon, are they still in business? Yes, they're in business, but they're owned now by zJournal. Try their new address - http://www.xephonusa.com On Mon, 14 Apr 2008 06:17:31 -0700, Mark T. Regan, K8MTR netsfw- [EMAIL PROTECTED] wrote: Is Xephon still in business? I'm subscribed to their TCP/SNA quarterly, but I have not received the March 2008 issue yet. It's not posted to their web site either and so far I have not had any response from them when I asked about it via their contact page. Thanks Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) -- 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: COBOL / VSAM question.
On 14 Apr 2008 07:56:24 -0700, in bit.listserv.ibm-main you wrote: I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. Very definitely, you should at least be checking for 00 and 97. Depending on the files and any recent compiler changes, other conditionally successful opens should be checked for. Clark Morris, COBOL programmer analyst who has done systems programming. -- 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: Workable Mainframe Debuggers
In a message dated 4/14/2008 1:42:12 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Agreed to the above and below. The only conflict I remember was when IBM came out with IOA as a hlq, and we'd already used it for some product from Israel that was acquired by some outfit in Texas :) I'd still like to brand DB/2 on the forehead of whomever came out with DSNsumting as a naming convention... **It's Tax Time! Get tips, forms and advice on AOL Money Finance. (http://money.aol.com/tax?NCID=aolcmp0030002850) -- 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
IEE806A
We are z/OS V1R7 and do not use MSYS. Every 10 mins this command is executed '$TOJOBQ 1-*,/OUTD=W,/DEST=LOCAL,ALL,D=N5'. This transmits jobs from 1 system to the other system output queue. JES2 issues a send command for every output it transmits over: SE '16.23.46 JOB11404 $HASP546 001 (JOB17156 FROM XXX) SYSTEM OUTPUT RECEIVED AT ',LOGON,USER=(BATCH) Sometimes we have a large number of output being transmitted. Then we receive this message: *IEE806A COMMANDS EXCEED LIMIT IN COMMAND CLASS M3 I have looked at the message and I understand why and what it is doing, my question is there a way to prevent jes2 from issuing the SEND command for these jobs and prevent this from happening. Thank You -- 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: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. It is the LLQ that matters in JCLIN. Consider this example: ++USERMOD(ICEEXIT) REWORK(1996350). ++VER (Z038) FMID (HSM1F00) . ++JCLIN. //ASMLINK JOB (ACCT),CLASS=M //ASMEXEC PGM=ASMBLR //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR // DD DSN=SYS1.ICEUSER,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSPUNCH DD DSN=amp;PUNCH(ICEIEXIT), //SPACE=(TRK,(1,1,1),DISP=(,PASS) //SYSIN DD * ICEIEXIT CSECT END /* //* //LKED EXEC PGM=IEWL,PARM='LET,LIST,NCAL,RENT,XREF' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSLMOD DD DSN=ANYTHING.FRED,DISP=SHR //SYSPUNCH DD *.ASM.SYSPUNCH,DISP=(OLD,DELETE) //SYSINDD * INCLUDE SYSPUNCH(ICEIEXIT) ENTRY ICEIEXIT NAME ICEIEXIT(R) /* ++SRC (ICEIEXIT) DISTLIB(AICESRCE) . ## // DD DSN=TECH.USERMODS.SOURCE(ICEIEXIT),DISP=SHR Will SMP/E try to link to the data set pointed to by a DDDEF (or DDNAME in JCL) of SYSLMOD, or the DSN pointed to by DDDEF or DDNAME of FRED? (FRED) 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: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. That seems clearer and more logical than what I thought I understood from the SMP/E RM. We'll see who's right. SYMBOLICRELATE is an entirely different concept. It is called _extended alias_ support and allows you to refer to one data set using an alternate name. I agree this appears to be a good way to achieve the desired objective using existing operating system facilities. However, when I experimented with this a while back, I found that it worked as expected only when the HLQs of the base name and alias were the same -- or more precisely -- expected to be in the same catalog. Me, too. I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create 'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID are cataloged in a user catalog. Data sets starting with SYS1 are cataloged in the master catalog. Try as I might, I could not figure out how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of 'MYUID.BASE'. (Perhaps I overlooked something.) WAD. I ranted about this in this list a while back. My expectations/desires matched yours, and I asked why the catalog search was not simply redriven from the beginning with the RELATED name so it would look in the directory actually containing that name. The modal reaction from the partisans was approximately I pity the fool ... If that were done, catalog search might loop, or IPL might be impossible, or it would be incompatible with existing art ... Or the universe might collapse into a black hole. I was and remain unmoved by the explanations. Loops can be terminated with counters. Reviews and audits can detect, anticipate, and avoid configuration errors that preclude IPL. Etc. -- gil -- 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: Specialty Engine Prices (Was: Another RNL question) [EMAIL PROTECTED]
Yes, I am absolutely sure. I was quoted a list price of (IIRC) $250K for an ICF, while zIIPs were priced at $95K, and I had quite a discussion with them on the matter. Ted MacNEIL [EMAIL PROTECTED] 4/12/2008 5:08 AM The list prices for IFL, zIIP zAAP have no bearing on ICF. IBM charges more for an ICF than the other specialty engines, and I'm not sure that the free upgrade applies either. Are you sure? The whole pricing algorithm started with ICF's (the first specialty engine). But, I can't find the doc. - Too busy driving to stop for gas! -- 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 Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: COBOL / VSAM question.
On 14 Apr 2008 08:14:24 -0700, [EMAIL PROTECTED] (Clark Morris) wrote: Very definitely, you should at least be checking for 00 and 97. Depending on the files and any recent compiler changes, other conditionally successful opens should be checked for. We had a purchased system that included a called program to handle KSDS input.I have no idea why they did that, maybe because the concepts of OO were being developed and they wanted on the bandwagon. Well, it accepted parms to open, read, or close - and it passed a return of 7 if the VSAM return code wasn't 00 on the open command. This program was called by every program that read a KSDS file (which is now down to zero programs). Every once in a while, it would abort and our procedure would be to restart.That was because it didn't check for 97. In a CoBOL shop, we had standards about having everything that used that program being extensively tested by users before our fixes went into production - so it just wasn't cost effective to fix this called program. This program had all of the problems of OO, but none of the advantages. -- 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: Sas itrm
In a message dated 4/14/2008 7:50:46 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Awful product to get working with OMVS and RACF. And their support teams (in this part of the world anyway) don't even appear to understand the environment. It's just the SAS branding of MXG. If you evaluate all the pieces and parts you can come up with exotic numbers for presentations. Dr. Barry explains how to process z/OS data on Windoze in SOURCLIB or find old SHARE badges at _www.mxg.com_ (http://www.mxg.com) ? **It's Tax Time! Get tips, forms and advice on AOL Money Finance. (http://money.aol.com/tax?NCID=aolcmp0030002850) -- 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: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 10:29:26 -0500, Mark Zelden wrote: On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. It is the LLQ that matters in JCLIN. Consider this example: ++USERMOD(ICEEXIT) REWORK(1996350). ++VER (Z038) FMID (HSM1F00) . ++JCLIN. //ASMLINK JOB (ACCT),CLASS=M //ASMEXEC PGM=ASMBLR //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR // DD DSN=SYS1.ICEUSER,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSPUNCH DD DSN=amp;amp;PUNCH(ICEIEXIT), //SPACE=(TRK,(1,1,1),DISP=(,PASS) //SYSIN DD * ICEIEXIT CSECT END /* //* //LKED EXEC PGM=IEWL,PARM='LET,LIST,NCAL,RENT,XREF' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSLMOD DD DSN=ANYTHING.FRED,DISP=SHR //SYSPUNCH DD *.ASM.SYSPUNCH,DISP=(OLD,DELETE) //SYSINDD * INCLUDE SYSPUNCH(ICEIEXIT) ENTRY ICEIEXIT NAME ICEIEXIT(R) /* ++SRC (ICEIEXIT) DISTLIB(AICESRCE) . ## // DD DSN=TECH.USERMODS.SOURCE(ICEIEXIT),DISP=SHR Will SMP/E try to link to the data set pointed to by a DDDEF (or DDNAME in JCL) of SYSLMOD, or the DSN pointed to by DDDEF or DDNAME of FRED? (FRED) FRED. I believe you and Ed are saying the same thing; I can agree with both of you. The more interesting question concerns the ASM STEP: Will the assembler search for macros in the concatenation of data sets defined by DDDEFs MACLIB and ICEUSER, or in the concatenation defined by DDDEF SYSLIB? -- gil -- 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: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 10:47:20 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: The more interesting question concerns the ASM STEP: Will the assembler search for macros in the concatenation of data sets defined by DDDEFs MACLIB and ICEUSER, or in the concatenation defined by DDDEF SYSLIB? SYSLIB DDDEF. I'm sure it is clearly documented. :-) 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: Consistent Data Set Names (Was: Workable Debuggers ...)
Mark Zelden wrote: It is the LLQ that matters in JCLIN. Consider this example: I can't tell if you're correcting me or agreeing with me and providing additional illustrative examples. O:-) Just to clarify what I said/meant: The LLQ you specify in JCLIN *is* the DDDEF name ... and *not* the LLQ of the data set to which the DDDEF refers. The actual LLQ of the data set is irrelevant! -- 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: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 10:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL / VSAM question. I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Monday, April 14, 2008 11:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. [snip] No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. HTH Peter I could have sworn that doing it that was was our standard. I just double checked and this particular program was last compiled on 04Aug05 in Enterprise COBOL 3.3.1. It definately should have the check for 00 and 97. Oh, well, not my problem. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: C++ Workable Mainframe Debuggers
I have been using z/XDC to debug C++ for years (before it was even called z/XDC). Of course, you have to be able to read assembler to do so without any source code support. The assembler listings from the compiler are pretty much the same as any assembler listing and the compiler code generation becomes quite familiar after awhile. If you developers don't know assembler very well, this may not work for them. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Logan Sent: Monday, April 14, 2008 8:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C++ Workable Mainframe Debuggers Does C Source code support also mean C++? David Logan Manager of Product Development, Pitney Bowes Software, Inc. http://centrus.com -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Sunday, April 13, 2008 5:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C++ Workable Mainframe Debuggers Cole Software's z/XDC - no We are on the verge of publishing C Source code support (c/XDC) to beta testers. More soon. Dave Cole At 4/13/2008 05:53 AM, you wrote: If you're debugging C/C++ on z/OS: 1. There's dbx for UNIX System Services (only): http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html No charge. 2. IBM Debug Tool for z/OS is available. IBM has introduced a new version annually for years now, so you want to stay current and take a fresh look if you remember an old version. Version 7, in particular, introduced some substantial C++ related improvements. Version 8 is current. I see a lot of old Debug Tool installed out there, unfortunately. You can license Debug Tool as MLC or, in the form of the Debug Tool Utilities Advanced Functions superset product, as OTC with subscription. As you prefer. Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTUAF) Version 7, so please try to get your z/OS release updated as soon as you can, at least for the development LPAR(s) where you're most likely to be debugging. You may be able to work with IBM to order DT or DTUAF Version 8 and arrange temporary use of Version 7; can't hurt to ask. Actually, as I write this Debug Tool V7 MLC is still orderable so no harm there, but for reasons of subscription you'll want to order DTUAF V8 if you go the OTC route. For graphical debugging use Rational Developer for System z (or WebSphere Developer Debugger for System z) in conjunction with Debug Tool (or DTUAF). I think those tools also provide graphical debugging with dbx now. Very slick. A certain popular IBM-MAIN training firm has a course on C/C++ debugging. Details here: http://www.trainersfriend.com/C_courses/N735descr.htm 3. There are a number of commercial debugger products for z/OS, most already mentioned. However, many (all?) of them don't support C++. Here's the latest information I have, and someone please correct me if my information is out of date: Cole Software's z/XDC - no CA-InterTest - no Compuware's Xpediter - C yes, C++ ? Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes, C++ ? Macro4's Tracemaster - no MacKinney Systems' Track and Xray - no ASG's (formerly Viasoft's) SmartTest - no Serena's StarTool ATD - product withdrawn? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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 -- 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: COBOL / VSAM question.
On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. 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: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 11:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
New: Programmer toolkits (Ad)
Darren has said I could make occasional announcements to the list, and I have self-limited myself to no more than one a quarter. So this is my announcement for the second quarter. We are trying something new ... We are proud to announce the opening of The Trainer's Friend on-line store where we are offering application programmer toolkits. A programmer toolkit is a collection of libraries and files, customized for each programmer, designed to make development, compiling, debugging, and testing simpler. Right now we have our Base Toolkit available, in two editions: * Personal edition - tailored for a specific programmer * Team edition - tailored for a group; each member of the team runs a simple dialog to have their own personal set of libraries and files built Each base toolkit supports developers who code in Assembler, COBOL, PL/I and C. With over 50 sample programs and relevant customized JCL procedures, programmers can quickly develop new batch applications or modify existing ones. We plan future toolkits for DB2, CICS, Language Environment and much, much more. All of these add on to a Base toolkit, so this is the starting point. Toolkits are inexpensive: * USD 160 for a personal edition base toolkit * USD 800 for a team edition. The link to our store: http://www.trainersfriend.com/TTFStore/index.html Check it out. Order online. Call or email with questions. Watch the store for additional toolkits, coming soon. 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 -- 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
Announcement: XMITIP Version 08.04 posted
I have just posted an update to XMITIP to bring it to version 08.04. The update can be found at: http://www.lbdsoftware.com The changes for this release are: V08.04 - 04/03/08 - exec updates TXT2HTML - Correction in output lrecl calculation (thanks Hartmut) XMITIP - Correct Addressfile use of BCC (broke in 08.01) XMITIPI - Version change only XMITIPTR - Correct capitalization for Septembre for the French translation table XMITIPZP - Update/Correction for use with InfoZip if the output zip DSN is 44 characters then a temp work DSN was 45 XMITZQEN - Update to handle more HTML codes (thanks Hartmut) Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We?re here to make lives better.? ?Never attribute to malice what can be caused by miscommunication.? NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. -- 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: SMF in System Logger
I presented a user session at SHARE Orlando based on experience with our z/OS 1.9 sandbox image. In the meantime, we have migrated SMF Logger to our development system, which gets very busy and therefore creates way more SMF data than the sandbox does. Everything is working fine. I still miss the ability to (a) mark dumped records and (b) delete dumped offload data sets before waiting for log stream retention period to expire. The main problem in managing the log stream(s) is that dumping must be time driven (start/end), and offload data set retention is also time driven; but the two processes have nothing in common other than TOD. Hence records can be dumped over and over--and will be if dumping is not carefully controlled; and offload data sets will continue to occupy space even though they will never be read again. IBM has informally but vocally acknowledged these deficiencies. To alleviate the occupied space problem, I have verified what I had read in the manuals but not tested as of Orlando: offload data sets can be HSM migrated. I doubt that having to recall a migrated data set in order to dump it has any value at all. But migrating an already dumped data set could be a good idea. Especially if you migrate to ML2 (tape), then DASD space is freed up. Best of all, when Logger 'rolls' the offload data sets forward and deletes the oldest one(s) by RETPD, HSM deletes (HDELETEs) a data set without recalling it. As for log stream RETPD, we still use 1 (day) and see no reason to extend it. We dump three times a day by wall clock. We could dump once or 24 times a day. I have no compelling arguments for any interval in between. Three is just such a nice number. We had predicted that offload data sets for one day would occupy around 8,000 cylinders. On busy days they go a little higher; on weekends the number drops. The number of 2275 cylinder data sets vary from twenty something to thirty something according to the amount data generated in the preceding 24 hours. We seem to have enough space available so that we have not implemented HSM migration as described above. A couple of points. I don't have a manual reference, but the CF structure name is entirely your choice. However, the qualifier IFASMF is required on the log stream side, so I use it also in the structure name to tie the pieces together logically. Structure size is a crap shoot. I get rather frequent XCF warnings that the structure is above the high water mark of 80% recommended by IBM, but the system catches up within seconds. I haven't need to take recommended corrective actions, the first of which is to 'consult the CF Sizer'. Nuff said on that. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Jim Holloway [EMAIL PROTECTED] E.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU SMF in System Logger 04/13/2008 07:17 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU We are beginning to test SMF in logstreams and so far, so good. Like others have mentioned, I really, really want the ability to delete records from the logstream programmatically after I've extracted them, but I can wait. Based on our experiences with VSAM SMF recording over the years we've decided to use a 2 day RETPD for SMF. I do, however, have some nits to pick: 1.) Logstream Structure Names: The doc is vague on what to name the structures. Every CF structure I've
Moving DASD Volumes from Mod3 to Mod9
This is just a curiosity question. We will be upgrading our Storage array and at that time the dasd will be carved out as MOD 9's. Currently we are 99% Mod 3s. Is there a way without taking an outage to move 3 MOD 3s onto one mod 9? I was hoping that TDMF, or DFDSS might work but I think they need control of the files. Any suggestions? Lizette -- 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: Moving DASD Volumes from Mod3 to Mod9
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Monday, April 14, 2008 12:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Moving DASD Volumes from Mod3 to Mod9 This is just a curiosity question. We will be upgrading our Storage array and at that time the dasd will be carved out as MOD 9's. Currently we are 99% Mod 3s. Is there a way without taking an outage to move 3 MOD 3s onto one mod 9? I was hoping that TDMF, or DFDSS might work but I think they need control of the files. Any suggestions? Lizette DFDSS will only move files when it can get exclusive access to the files. I think TDMF or FDRPAS will move files while they are in use, but only to like sized volumes. I think that TDMS and FDRPAS work like a mirror-ing controller, updating both DASD units simultaneously. But this does require identical device geometries. That said, they may support moving from a -3 to a -9, but not a consolidation of 3 -3s onto one -9. That is simply not possible (justwatch somebody will prove me wrong!) -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
TWS: how to submit a standalone job
How can I submit a job from TWS without setting the depended jobs? In CTM, you can remove all out condition, but in TWS there are no conditions... So, How can I block TWS to run the dependent jobs? Regards, Itschak Mugzach, Director SecuriTeam Software ltd. Tel: +972 (522) 986404 Skype: Securiteam-Software Email: [EMAIL PROTECTED] Gmail: [EMAIL PROTECTED] for large mails -- 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: DCF (was Re: System z10 announcement (in English))
I don't really know the answer. It was always surprising to me that BookMaster and BookManager were owned by different functional organization than DCF. I don't support those or know what their official status is. For DCF, we do still fix defects. As far as I know, it is also still possible to submit new requirements for DCF. All requests for new function are processed through the marketing people. I think their general mindset is how many more licenses will it sell when looking at any request for new function. It's been a long time since we geared up for a whole new release, but sometimes a new function was added by an individual APAR. It's been a while since the last one of those too, but nobody has told me it's impossible. Roger Bolan Software Engineer e-mail: [EMAIL PROTECTED] infoprint.com Boulder, Colorado, USA P Think before you print Shmuel Metz (Seymour J.) [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 04/13/2008 05:11 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: DCF (was Re: System z10 announcement (in English)) In [EMAIL PROTECTED], on 03/04/2008 at 06:26 PM, Roger Bolan [EMAIL PROTECTED] said: Would you guys stop talking about DCF (Document Composition Facility, 5748-XX9) a.k.a. Script in the past tense? It is still available for z/OS, z/VM, and z/VSE. Yes, but aren't DCF, BookMaster and BookManager MVS all functionally stabilized? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [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: Moving DASD Volumes from Mod3 to Mod9
We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Monday, April 14, 2008 12:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Moving DASD Volumes from Mod3 to Mod9 This is just a curiosity question. We will be upgrading our Storage array and at that time the dasd will be carved out as MOD 9's. Currently we are 99% Mod 3s. Is there a way without taking an outage to move 3 MOD 3s onto one mod 9? I was hoping that TDMF, or DFDSS might work but I think they need control of the files. Any suggestions? Lizette -- 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: Installers (Was: IBM announcements)
On Mon, 14 Apr 2008 07:50:47 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: On 04/10/2008 at 08:08 AM, Edward Jaffe [EMAIL PROTECTED] said: Keep in mind that ServerPac is an SMP/E bypass. It _restores_ SMP/E zones rather than installing into them. Keep in mind that you are talking about a specific step within ServerPac, not about the services that ServerPac provides for constructing dialogs. I don't believe that Art suggested that ISV's should use the existing ServerPac jobs, just the structure that manages them. A subtle point I had in mind, but wasn't sure how to express it. I did not mean to suggest every vendor follow the exact same process, job for job. However, the architecture repository is there for product installs, PDO's, ServerPac, SystemPac, whatever. Of course, this requires IBM to open up the the interfaces enough for ISVs to exploit. As I said, some ISVs do a good job already, but it would be *nice* to have a common database template. Regards, Art Gutowski Ford Motor Company -- 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: Moving DASD Volumes from Mod3 to Mod9
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kammer, Charles Sent: Monday, April 14, 2008 12:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving DASD Volumes from Mod3 to Mod9 We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer Consolidations of multiple -3s onto a single -9? Or 1:1 from -3 to -9? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Moving DASD Volumes from Mod3 to Mod9
One thing that bit us was the size of the VTOC's. When you move a mod-3, 15 track VTOC to a mod-9 and use it within SMS or HSM, you will blow out the VTOC. Please make sure you check what the volume will be used for. Something I inherited...Been there done that. Just another FYI. Claude Richbourg Florida Department of Corrections Systems Programmer 850-921-1383 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kammer, Charles Sent: Monday, April 14, 2008 1:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving DASD Volumes from Mod3 to Mod9 We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Monday, April 14, 2008 12:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Moving DASD Volumes from Mod3 to Mod9 This is just a curiosity question. We will be upgrading our Storage array and at that time the dasd will be carved out as MOD 9's. Currently we are 99% Mod 3s. Is there a way without taking an outage to move 3 MOD 3s onto one mod 9? I was hoping that TDMF, or DFDSS might work but I think they need control of the files. Any suggestions? Lizette -- 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: Moving DASD Volumes from Mod3 to Mod9
Kammer, Charles wrote: We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Did you consolidate them three-to-one??? That's what she wants to do. -- 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: Moving DASD Volumes from Mod3 to Mod9
As far as I know, TDMF will move Mod3s to Mod-9s while the files are open. The only caveat was with page datasets. Bob Shannon Rocket Software -- 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: Moving DASD Volumes from Mod3 to Mod9
1:1 from a Mod3 to a Mod9. We were migrating from an older RAMAC to a Shark and needed to increase the amount of storage we had available for certain SMS groups and each Mod3 we took to a Mod9 added the equivalent of two additional volumes without having to add physical volumes to the group. Charles S. Kammer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 12:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving DASD Volumes from Mod3 to Mod9 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kammer, Charles Sent: Monday, April 14, 2008 12:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving DASD Volumes from Mod3 to Mod9 We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer Consolidations of multiple -3s onto a single -9? Or 1:1 from -3 to -9? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Moving DASD Volumes from Mod3 to Mod9
PS. Is there a reason you are only going to Mod-9s? Bob Shannon Rocket Software -- 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: Moving DASD Volumes from Mod3 to Mod9
Have used FDRPAS for straight volume to volume migrations, including mod3 to mod9. Have used FDRMOVE to do volume consolidations, so 3 mod3 to 1 mod9. Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- 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: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 11:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years -jc- -- 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: Moving DASD Volumes from Mod3 to Mod9
We also migrated from MOD-3 to Mod-9s to help us reduce UCB's and get back PAVs. We used FDRPAS and this worked out nicely for us. The migration was smooth enough to run during our production day Rich Lopez -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Kammer, Charles Sent: Monday, April 14, 2008 1:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Moving DASD Volumes from Mod3 to Mod9 We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer -SNIP -- 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: SMF in System Logger
On 04/14/2008 01:20 PM, Skip Robinson wrote: I presented a user session at SHARE Orlando based on experience with our z/OS 1.9 sandbox image. In the meantime, we have migrated SMF Logger to our development system, which gets very busy and therefore creates way more SMF data than the sandbox does. Everything is working fine. I still miss the Snip Skip, Thanks for the feedback. I couldn't find a manual reference for SMF Structure names either. But I am curious as to the structure sizing you're using for your development environment(If you're using the CF). I have three structures defined, type 30s, type 80s, and everything else. The lab environment I'm on is our smallest lab sysplex used for DASD Mirroring testing. So there are no type 110s or type 101s and in reality not much happens in this plex. Our primary labs have CICS and DB/2 so the volume should go up. In production, which is fairly busy, our capacity folks have reserved 8Gig in our external CFs for SMF. The SYSPLEX is a 5 system sysplex and we're looking at having five structures/logstreams per system. Also, if you are using the CF, are you duplexing the data into staging datasets? We are considering this as a Belt and Suspenders solution to help insure against dataloss. Jim Holloway Sr. Software Systems Engineer Operating Systems Automation - RISC - Troy, NY (518)285-2646 [Voice] (518)281-9686 [Cell Phone] (419)730-0857 [FAX] MetNet Lotus Notes: mailto:jholloway Internet: mailto:[EMAIL PROTECTED] The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- 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: COBOL / VSAM question.
On Mon, 14 Apr 2008 12:14:03 -0500, McKown, John [EMAIL PROTECTED] wrote: I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? Of course. Always guilty until proven innocent, especially after some kind if install or infrastructure change. Last year when I upgraded one of our small monoplex LPARs from z/OS 1.6 to z/OS 1.8 the *exact* same thing happened (old program, but never changed) and the programmer wanted to blame the z/OS 1.8 upgrade. 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: SMF in System Logger
On Mon, 14 Apr 2008 10:20:02 -0700, Skip Robinson [EMAIL PROTECTED] wrote: Structure size is a crap shoot. I get rather frequent XCF warnings that the structure is above the high water mark of 80% recommended by IBM, but the system catches up within seconds. See past rants ... er ..posts on FULLTHRESHOLD(0) in your CFRM policy from Barbara Nitz. 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: COBOL / VSAM question.
On 14 Apr 2008 11:14:24 -0700, [EMAIL PROTECTED] (Chase, John) wrote: It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. Or just assume '97' is a valid open (which it is) and continue. -- 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: COBOL / VSAM question.
On Mon, 14 Apr 2008 13:13:58 -0500, Chase, John [EMAIL PROTECTED] wrote: And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years You're right. There would be no reason to run the manual VERIFY after the file status 97. Just re-run the program and it will magically disappear. 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: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 1:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 13:13:58 -0500, Chase, John [EMAIL PROTECTED] wrote: And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years You're right. There would be no reason to run the manual VERIFY after the file status 97. Just re-run the program and it will magically disappear. Mark -- Well, given that the file actually is OPEN to CICS at the time, I don't think that just rerunning the job would fix the 97. Or would it? I have come to __HATE__ VSAM here. Especially here, where we're too elided cheap to get a database on z/OS. Better 1000s of MS-SQL squatty boxes than one enterprise class server! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Another stupid sysplex question.
Two TSO users on a single image can communicate via TSO SEND. Is there any way for a TSO user on system1 to send a message to a TSO user on system2? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Another stupid sysplex question.
Works just fine on my PLEX via the TSO SEND command. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 2:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Another stupid sysplex question. Two TSO users on a single image can communicate via TSO SEND. Is there any way for a TSO user on system1 to send a message to a TSO user on system2? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Another stupid sysplex question.
From TSO Command Reference: In a sysplex, SEND can be used to send a message from one user to another user in the same JESPLEX. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 3:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Another stupid sysplex question. Two TSO users on a single image can communicate via TSO SEND. Is there any way for a TSO user on system1 to send a message to a TSO user on system2? *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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: Another stupid sysplex question.
On Mon, 14 Apr 2008 14:01:49 -0500, McKown, John [EMAIL PROTECTED] wrote: Two TSO users on a single image can communicate via TSO SEND. Is there any way for a TSO user on system1 to send a message to a TSO user on system2? -- Is system 2 in the same MAS? 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: Another stupid sysplex question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Imbriale, Donald Sent: Monday, April 14, 2008 2:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another stupid sysplex question. From TSO Command Reference: In a sysplex, SEND can be used to send a message from one user to another user in the same JESPLEX. Don Imbriale Hum, strange. According to one of our Production Control people, who maintains some CA-OPS/MVS rules, a message rule on SYS1 which does a ADDRESS TSO SEND ... does not send the message to the people on SYS2. I simply assumed she was telling me the truth. Yes, we are on the same JESPLEX. And I just tested it with a coworker and it worked. I wonder what her problem really is? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Another stupid sysplex question.
Dennis Trojak wrote: Works just fine on my PLEX via the TSO SEND command. The TSO/E SEND command does not support sysplex. It allows you to send to another user in the same JESPlex only. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4C580/1.41 IBM Documentation 1.41 SEND command SEND can be used to send a message from one user to another user in the same JESPLEX. /IBM Documentation If you attempt to send to another user in the sysplex, but not in the current JESplex, you will receive: IKJ55072I USER(S) xxx NOT LOGGED ON OR TERMINAL DISCONNECTED, MESSAGE CANCELLED -- 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
Has z/Journal gone to the dark side
I just got an email titled “Legacy Modernization Spotlight”. When I clicked on the links in it they took me to articles that look like they’re in the online version of z/Journal but they’re sponsored by Microsoft and talk about converting from the mainframe to Microsoft servers. Is z/Journal dropping the z and becoming Widows Journal, or am I reading the articles wrong? Here is a web link that ends up going to the same articles. Once you get to the main page click on one of the articles under the heading “In‑Depth”. http://zjournal.tcipubs.com/issues/LegacyModernization04-08.html Tom Kelman Commerce Bank of Kansas City (816) 760-7632 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. *
SPFLOG
I hate to ask this question, but I have searched and searched and can not find where the SPFLOG list dataset name is defined. I have 2 systems sharing data, and I want to rename the *userid*.SPFLOG1.LIST dataset to something system specific so that I can log on the each system with the same userid at the same time. -- 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: Has z/Journal gone to the dark side
Tom, I just got the same e-mail and thought the same thoughts. With friends like these Kelman, Tom wrote: I just got an email titled “Legacy Modernization Spotlight”. When I clicked on the links in it they took me to articles that look like they’re in the online version of z/Journal but they’re sponsored by Microsoft and talk about converting from the mainframe to Microsoft servers. Is z/Journal dropping the z and becoming Widows Journal, or am I reading the articles wrong? Here is a web link that ends up going to the same articles. Once you get to the main page click on one of the articles under the heading “In‑Depth”. http://zjournal.tcipubs.com/issues/LegacyModernization04-08.html Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -- 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
RES: SPFLOG
Take a look at ISPCCONF command. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Engenharia de Software - Sistemas Operacionais Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 |-Mensagem original- |De: IBM Mainframe Discussion List |[mailto:[EMAIL PROTECTED] Em nome de Mark Pace |Enviada em: segunda-feira, 14 de abril de 2008 16:35 |Para: IBM-MAIN@BAMA.UA.EDU |Assunto: SPFLOG | |I hate to ask this question, but I have searched and searched |and can not find where the SPFLOG list dataset name is |defined. I have 2 systems sharing data, and I want to rename |the *userid*.SPFLOG1.LIST dataset to something system specific |so that I can log on the each system with the same userid at |the same time. | |-- |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 | | HTMLfont face=Tahoma size=1HRAVISO LEGAL brEsta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. HTMLfont face=Tahoma size=1HRLEGAL ADVICE brThis message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- 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: Another stupid sysplex question.
On Mon, 14 Apr 2008 14:18:38 -0500, McKown, John [EMAIL PROTECTED] wrote: simply assumed she was telling me the truth. Yes, we are on the same JESPLEX. And I just tested it with a coworker and it worked. I wonder what her problem really is? Trust, but verify. Except in the case of operations, application programmers and end users. Then just assume they don't know WTF they are talking about. :-) Mark p.s. I'm joking. I don't need a bunch of emails from all you operators, application programmers and end users who monitor this list. -- 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: SPFLOG
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pace Sent: Monday, April 14, 2008 2:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: SPFLOG I hate to ask this question, but I have searched and searched and can not find where the SPFLOG list dataset name is defined. I have 2 systems sharing data, and I want to rename the *userid*.SPFLOG1.LIST dataset to something system specific so that I can log on the each system with the same userid at the same time. -- Mark Pace You need to install ISPEXIT number 16. I already have such a thing which creates DSNs of userid.SYSSYSNAME. However, this may not be all that you need. You also need to use a different ISPF profile dataset on each system. That's because ISPF does an SPFEDIT global ENQ on the ISPF profile dataset. Well really on a number of members in the profile dataset. But it ends up doing the same thing: On the second system you cannot get into ISPF due to the ENQ. I am, of course, assuming that you are in a GRSPlex or MIMPlex and passing SPFEDIT around the 'plex. Ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/isppla03/3.16 My exit is only 89 lines long. If you want, I can email it to you. Note to others: if you want the exit as well, please, please, please email me directly at mailto:[EMAIL PROTECTED] and don't reply to this email on the list. I really get P.O.'ed at people who do that! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: TN3270 server OBEYFILE processing?
On Fri, 11 Apr 2008 14:48:01 -0400, Mark Pace [EMAIL PROTECTED] wrote: I've also found, and I may just be doing it wrong, but the tn3270 server is not handled like any other server. Meaning that TCPIP does not automatically start TN3270 when it comes up, and it does not automatically stop TN3270 when you shutdown TCPIP. ... I believe you can have the Tn3270 server started through Autolog processing (or whatever it is called), but you are right that the stack makes no attempt to shut down the Tn3270 server when the stack is brought down, and the server does not bring itself down when the stack goes down from underneath it. We start and stop the Tn3270 server with out automation product. I think this behavior of the Tn3270 server was fully intensional. The reason for moving the the Tn3270 server out of the TCP/IP address space was to satisfy customer requests (read demands) for isolation fo the server - to make sure problems wih the server did not spill over into the stack's address space. IBM went one step further: a crash of the address space does not require a restart of server's address space. (Obviously, all the sockets would have to be reopened, but the server would not have to reprocess possibly thousands of Tn3270 definitions.) I think this was done to speak up recovery time. There were some very lively discussions between customers and developers at SHARE when this Requirement was submitted. 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: Has z/Journal gone to the dark side
Here is a response to this post from Bob Thomas, the publisher of z/Journal: To some mainframe users we will be considered untrustworthy mainframe bigots in IBM's pocket. While others will think we are selling out and in Microsoft's pocket. Hard to win sometime! But, what we really want to be is an independent source of information for users of IBM mainframe systems. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Samson Sent: Monday, April 14, 2008 2:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Has z/Journal gone to the dark side Tom, I just got the same e-mail and thought the same thoughts. With friends like these Kelman, Tom wrote: I just got an email titled “Legacy Modernization Spotlight”. When I clicked on the links in it they took me to articles that look like they’re in the online version of z/Journal but they’re sponsored by Microsoft and talk about converting from the mainframe to Microsoft servers. Is z/Journal dropping the z and becoming Widows Journal, or am I reading the articles wrong? Here is a web link that ends up going to the same articles. Once you get to the main page click on one of the articles under the heading “In‑Depth”. http://zjournal.tcipubs.com/issues/LegacyModernization04-08.html Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -- 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
CTC Disconnect Time
Hi list, I have a situation I don't fully understand... I have a shared Escon channel used as CTC between 2 Lpars. The CTC is used for XCF and VTAM communication. For XCF there are 2 Devices defined on each system (in and out) and for VTAM there is 1 device defined on each system. Looking on RMF report I see the following info: Channel utilization is low - about 10% Device Disconnect time for the IN device (on both systems) is huge - about 5000ms (the out devices numbers are fine). The in device utilization is almost at all time near 100%. I don't think that this is a normal situtation, but except from GRS delay for XCF (about 5%) It doesn't seemes to have any performance effect or am I wrong? Any help would be appricated. Thanks Magen -- 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: Moving DASD Volumes from Mod3 to Mod9
You had it correct 3 MOD3s to one MOD9. Lizette We just finished moving about 12 Mod3's to Mod9's using FDRPAS without any problems or outages. Many of these volumes were high usage SMS type volumes and most were completed in 7 minutes or less. Charles S. Kammer Consolidations of multiple -3s onto a single -9? Or 1:1 from -3 to -9? -- 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: COBOL / VSAM question.
I have an interesting observation. I ran an IDCAMS jobs to print 1 record from a VSAM file which I know is OPEN to CICS. If I run it on the same LPAR as the CICS region, I get NO messages, just the output. When I run it on a different LPAR, then I get the messages: IEC161I 056-084,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 170 IEC161I MSHPV.NASE.CICSPIF.DATA,CATALOG.ICF.VPRDH01 IEC161I 056-084,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 171 IEC161I MSHPV.NASE.CICSPIF.INDEX,CATALOG.ICF.VPRDH01 IEC161I 062-086,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 172 IEC161I MSHPV.NASE.CICSPIF.DATA,CATALOG.ICF.VPRDH01 as well as the IDCAMS output: IDC3300I ERROR OPENING MSHPV.NASE.CICSPIF IDC3351I ** VSAM OPEN RETURN CODE IS 118 So, on my z/OS 1.8 system, I get different actions depending on which LPAR I run on. Should I be propagating something more across the GRSPlex? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Cannot edit ZTEMPF
It sounds as if the configuration at your installation has been changed
to use temporary datasets instead of permanent dataset names.
Datasets with names like SYSyyddd. are temporary, are deleted at the
end of your TSO session and are not catalogued.
You should be replace the statement
ispexec edit dataset(ztempf)
with the statements:
address ispexec 'vget (ztempn)'
address ispexec 'lminit dataid(tid) ddname('ztempn')'
address ispexec 'browse dataid('tid')'
address ispexec 'lmfree dataid('tid')'
Also, more people will see your post if you post to the listserv.
See the messages which appear at end of this post for more information.
Bill
On Apr 14, 1:39 pm, [EMAIL PROTECTED] wrote:
Working on MVS.
In my REXX exec I have a statement
ispexec edit dataset ('ztempf')
This exec generates a Compile JCL and gives user option to view/edit
the JCL before submitting.
All of a sudden this statement has started to error out saying
ISRD028
Data set not cataloged
'SYS08105.T131854.RA000.PGM687.R0232968' was not found in catalog.
While I wait for the Systems folks to tell me what's wrong, I thought
I'd post in this forum.
Any suggestions? It has been working fine for years.
Thanks
--
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: Search for a textstring i a lot of datasets
In [EMAIL PROTECTED], on 04/10/2008 at 11:42 AM, Frank Allan Rasmussen [EMAIL PROTECTED] said: We have a requirement to search for a textstring i a lot of datasets Will grep do what you need? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SPFLOG
On Mon, 14 Apr 2008 14:58:08 -0500, McKown, John [EMAIL PROTECTED] wrote: You need to install ISPEXIT number 16. I already have such a thing which creates DSNs of userid.SYSSYSNAME. However, this may not be all that you need. You also need to use a different ISPF profile dataset on each system. That's because ISPF does an SPFEDIT global ENQ on the ISPF profile dataset. Well really on a number of members in the profile dataset. But it ends up doing the same thing: On the second system you cannot get into ISPF due to the ENQ. I am, of course, assuming that you are in a GRSPlex or MIMPlex and passing SPFEDIT around the 'plex. You don't need exit 16 to do that since OS/390 R10. See the $SNGLTSO doc on my web site for CBT file 434 for details. 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
