Re: FW: GETMAIN/FREEMAIN and virtual storage backing up
Sorry, I spelled your name wrong.. I've survived it ;-) -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GETMAIN/FREEMAIN and virtual storage backing up
Keep in mind that MVS is permitted to move a unfixed backed DREF page to another real frame, so do not assume that the real address of an unfixed backed DREF page will not change. ...which makes DREF storage behave more like pageable storage than fixed (like xxSQA): It is not backed until referenced, it can be paged out (when there is ESTOR, so not on z/OS). -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MAS from Bus-Tech
Hi Walter, Several of our customer sites are using the MAS (I think they number over 30). I wrote several utility programs that are now offered with the MAS, and I have some others that they (as yet) don't include with the product. One of them (since you're z/OS.e) is a very quite (4 step) process that eliminates the necessity of you needing a tape management system to keep the MAS and your catalogs in sync. I've been impressed with the MAS, it has a lot of features that are very useful, and when it's a fit for your site, it can work out very well. One thing to keep in mind though is that if it doesn't fit, don't try to force it to work for you. There are some more sophisticated VTS's out there for sites that need all of the extra features, but if you don't, it can be a very cost effective unit. If you want to discuss it, please feel free to contact me offline. Brian Westerman -- 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: CRON Question
Why does z/OS-1.4 USS cron die/stop/go away without any trace of a cause? How do you recognize it's gone. How do you start it? Any BPX messages in SYSLOG? -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GETMAIN/FREEMAIN and virtual storage backing up
Peter, My understanding for what Jim said is a little different. Actually Jim wrote something about DREF three years ago and I happened to find it in the archive: --- There are some important differences between *DREF* and fixed storage even when there is no expanded storage. 1. *DREF* storage does not get backed until it is referenced (other than the first page of the Getmain request). 2. The real storage address backing a *DREF* page can be changed at the whim of RSM. The real address backing a fixed page can only be changed by swap processing (and thus cannot change while you are non-swappable, or holding serialialization which prevents you from being swapped (like your local lock or by being disabled). - So my understanding is: After your first reference to a DREF page, the frame *can be copied to ESTOR if you have that stuff. Even if we don't have ESTOR, something still can be done by RSM for DREF frame which is impossible for FIXED frame. That is, RSM can directly copy the DREF frame to another frame. So the real address for a DREF page can change even without ESTOR and swapping out. On 10/9/07, Hunkeler Peter (KIUK 3) [EMAIL PROTECTED] wrote: Keep in mind that MVS is permitted to move a unfixed backed DREF page to another real frame, so do not assume that the real address of an unfixed backed DREF page will not change. ...which makes DREF storage behave more like pageable storage than fixed (like xxSQA): It is not backed until referenced, it can be paged out (when there is ESTOR, so not on z/OS). -- Peter Hunkeler Credit Suisse -- Best Regards, Johnny Luo -- 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: Hipersockets performance
STOR 'NULLFILE' 125 Storing data set NULLFILE ... I wonder where it went? Would that not be the equivalent of a dummy file? I seem to remember that //NONO DD DSN=NULLFILE is the same as //NONO DD DUMMY 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: Hipersockets performance
Jan MOEYERSONS wrote: STOR 'NULLFILE' 125 Storing data set NULLFILE ... I wonder where it went? Would that not be the equivalent of a dummy file? I seem to remember that //NONO DD DSN=NULLFILE is the same as //NONO DD DUMMY It is the same. However NULLFILE can be used in FTP (as file name), while DD DUMMY would require special syntax. What's funny, NULLFILE requires RACF authorization. At least in ftp. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: CRON Question
I haven't seen it do that. Did you check the cron log and the USS syslog? You may wish to post to MVS-OE for USS questions; see http://www.marist.edu/htbin/wlvindex?mvs-oe for archives subscription info. Bill On Mon, 8 Oct 2007 11:56:42 -0500, Adam Floro [EMAIL PROTECTED] wrote: Why does z/OS-1.4 USS cron die/stop/go away without any trace of a cause? -- 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
Access account info (SMF 30) for running USS process
Hi I would like to access the accounting info's (SMF 30 records) for running USS processes. I'm testing now the ERBDSQRY and ERBDSREC interface from RMF, but not very satisfied with the results: - the RMF SMF data buffer option should be on - I can retrieve the SMF 30 records, but I have to select from a large list the records for a given address space or jobname - for a started task USS server address space I didn't find the proper info although the the SMF STC INTVAL is set I also tested the ERB2XDGS to get the RMF records, but for USS I found the SMF 30 USS section contains more usable info's as the SMF 79 records. If someone has maybe a better idea. -- 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: SLIP sliding away
ENABLED(INACTIVE) means that there is already a PER type slip active in the system. No it doesn't. It means that SLIP was unable to find the module in one of the address spaces, and thus is waiting for a subsequent load of that module to occur at which point the trap could/would be activated. Note that if you specify multiple ASIDs, and the module is not at the same address in both ASIDs, you'll get a trap set at the first address range it found in one of those address spaces. One SLIP trap cannot cover two different ranges. It wasn't the case here, apparently, but if the module was loaded via LOAD with ADDR= and DE= I doubt that SLIP would find a matching PVTMOD as there is no CDE maintained for that module. Peter Relson z/OS Core Technology 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
Re: Dynamic load module name extraction?
In [EMAIL PROTECTED], on 10/08/2007 at 01:30 PM, Craddock, Chris [EMAIL PROTECTED] said: Clearly it won't tell you which entry point was used since that is completely un-knowable. No it isn't; you can sometimes tell by looking at the CDE chained off the PRB. but it's entirely possible that no formal interface at all was used. Lot's of things are possible. Most of them are irrelevant. I had a reason for writing Depending on what the OP needs: it really does change the appropriate answer. However, everything that -is- knowable is returned by CSVQUERY, No, because it doesn't know which, if any, minor CDE is relevant. Looking at the PRB can give you information that you can't get with just CSVQUERY. -- 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: z/OS 1.4 upgrade to allow operation on a z9.
It's ancient history now (about 18 months ago) but we upgraded from a 7060 to a z9 running z/OS 1.4. As others have stated, it was merely getting the exploitation feature and installing it. The upgrade went smoothly and I don't recall any issues. We're still running the 1.4 code and still have no issues, although a caveat is that we're running a pretty vanilla machine. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Murray M. Robinson Sent: Monday, October 08, 2007 3:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: z/OS 1.4 upgrade to allow operation on a z9. Some days ago I noticed a request as to how difficult the move from a z900 to a z9 with the now unsupported release of z/OS 1.4. It looked like you just had to apply the appropriate compatibility PTFs and PSP buckets. However, I either did not see or missed if this was done using the ORDERABLE comparability functions while z/OS 1.4 was still supported. The only way now is to download the z990 Exploitation Support for z/OS V1.4 from the web. This has the compatibility functions bundled in with other exploitation changes (which I don't really need). Has anyone used this method to get there operating system ready for a new machine, and if so how bad was the maintenance process. We don't have to run the z/OS 1.4 image for long on the new machine but we have a push pull machine change so have to feel comfortable about image coming up. It is also part of an existing SYSPlex contained on the one machine ( the others being z/OS 1.7 so only PSP bucket fixes for them), don't know if that complicates matters or not. Thanks. This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Murray Robinson ACI Worldwide, Inc. [EMAIL PROTECTED] (402)-778-1930 -- 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: IBM Google to promote computer programming for clouds
Client/Server clusters? GDPS? Grid Computing? This is the next new thing? Sounds to me they're trying to do for the PC what RAID did for DASD. Again. Using a proven mainframe model, without crediting it. Again. Maybe this time they'll succeed, without using up so much network bandwidth as to make the whole setup too costly or unfeasible. My 2 cents. Gary Diehl MVS Support The glass is neither half full or half empty; the engineer who designed the glass simply allowed for a 100% increase in fluid storage. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Monday, October 08, 2007 12:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IBM Google to promote computer programming for clouds -- 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
DFHSM :ARC0560E - Message Clarity
Good Day To All, I was investigatin problem ARC0521I - the PRIMARY SPACE MANAGEMENT ended due to a ARC0521I COMPLETION, RESOURCES NOT AVAILABLE. I found the message ARC0560E MIGRATION LIMITED: NO MIGRATION LEVEL 1 SPACE AVAILABLE, followed by subsequent messages : ARC0559I SPACE MANAGEMENT OF PROM116 WILL NOT TARGET 708 ARC0559I (CONT.) MIGRATION LEVEL 1 UNTIL THE REQUESTED VOLUME TYPE I ARC0559I (CONT.) MADE AVAILABLE I checked the message ARC0560E explanation but it didn't tell me much only to say that the there was a lack of available space for LEVEL 1. I added a level 1 volume but the problem didn't clear. I added another one still the problem persisted. Finally, I shutdown the STC and brought it up again. For some reason the problem was fixed. However, I am at a loss as to why this happened. Were my actions correct? Is there something else that I should have tried? Please let me know. - Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. -- 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: ADABAS vs IMS vs DB2 Who is faster?
snip Subject: ADABAS vs IMS vs DB2 Who is faster? I spoke few days ago with an ADABAS specialist that claimed that ADABAS is much faster and has low overhead compared to IMS and DB2. Is this true? /snip As with most things in this business, it depends. The first question to ask is What source are you citing to support your claim? Depending on the configuration and tuning options ADABAS may or may not be faster than DB2. DB2 may or may not have a smaller footprint than ADABAS. Because IMS uses an entirely different technique to access data, it *most likely* is somewhat faster than either IMS or DB2. In order to obtain this speed, the flexibility of using SQL is sacrificed. (Actually it is the other way around IMS preceded DB2/ADABAS by several years. The relative speed that is important is the one for *YOUR* workload. Anything else is meaningless noise. Thoroughly research the *features* important to you and go with the product that provides the best feature to price ratio for you. HTH, -- 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 Google to promote computer programming for clouds
On Tue, 2007-10-09 at 07:38 -0500, Diehl, Gary (MVSSupport) wrote: Client/Server clusters? GDPS? Grid Computing? This is the next new thing? Don't be like that Gary. I twigged on this bit; quote Six universities will initially participate in a pilot program to work out the kinks: the University of Washington, Stanford University, University of California-Berkeley, Carnegie Mellon University, Massachusetts Institute of Technology and University of Maryland. /quote Even lost in the wilds of the Aussie bush, I've heard of a couple of those. Might all come to nought, but that lot have got the right credentials ... 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: DFHSM :ARC0560E - Message Clarity
Did you release migration after you added the ML1 volume? The message MIGRATION LIMITED means that it held migration. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, October 09, 2007 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM :ARC0560E - Message Clarity Good Day To All, I was investigatin problem ARC0521I - the PRIMARY SPACE MANAGEMENT ended due to a ARC0521I COMPLETION, RESOURCES NOT AVAILABLE. I found the message ARC0560E MIGRATION LIMITED: NO MIGRATION LEVEL 1 SPACE AVAILABLE, followed by subsequent messages : ARC0559I SPACE MANAGEMENT OF PROM116 WILL NOT TARGET 708 ARC0559I (CONT.) MIGRATION LEVEL 1 UNTIL THE REQUESTED VOLUME TYPE I ARC0559I (CONT.) MADE AVAILABLE I checked the message ARC0560E explanation but it didn't tell me much only to say that the there was a lack of available space for LEVEL 1. I added a level 1 volume but the problem didn't clear. I added another one still the problem persisted. Finally, I shutdown the STC and brought it up again. For some reason the problem was fixed. However, I am at a loss as to why this happened. Were my actions correct? Is there something else that I should have tried? Please let me know. -- 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: DFHSM :ARC0560E - Message Clarity
No, I didn't. I didn't see the message that the MIGRATION was held. I will take note of this to add to my procedures. Would you know if there is something else I should have done besides adding the disks? I thought of doing a MIGRATE1 to MIGRATE2. Would that have been a good move? Adams, Rick [EMAIL PROTECTED] wrote: Did you release migration after you added the ML1 volume? The message MIGRATION LIMITED means that it held migration. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, October 09, 2007 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM :ARC0560E - Message Clarity Good Day To All, I was investigatin problem ARC0521I - the PRIMARY SPACE MANAGEMENT ended due to a ARC0521I COMPLETION, RESOURCES NOT AVAILABLE. I found the message ARC0560E MIGRATION LIMITED: NO MIGRATION LEVEL 1 SPACE AVAILABLE, followed by subsequent messages : ARC0559I SPACE MANAGEMENT OF PROM116 WILL NOT TARGET 708 ARC0559I (CONT.) MIGRATION LEVEL 1 UNTIL THE REQUESTED VOLUME TYPE I ARC0559I (CONT.) MADE AVAILABLE I checked the message ARC0560E explanation but it didn't tell me much only to say that the there was a lack of available space for LEVEL 1. I added a level 1 volume but the problem didn't clear. I added another one still the problem persisted. Finally, I shutdown the STC and brought it up again. For some reason the problem was fixed. However, I am at a loss as to why this happened. Were my actions correct? Is there something else that I should have tried? Please let me know. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Check out the hottest 2008 models today at Yahoo! Autos. -- 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: SLIP sliding away
Rick Fochtman wrote: I can't help it; I've got to butt in here with one of my pet peeves. We'va all used GTF and SLIP at one time or another to try and debug system problems and, perhaps less often, application problems. I write almost all my code in Assembler and the lack of debugging tools that I can imbed into a product is one of my pet peeves. GTF quite often uses the MC instruction (like in GTRACE expansion) to hook into various routines at selected points. Why, in the name of all that's holy, can't application programmers, get access to the same kinds of interfaces? Freely granted, there's lots of room for abuse; freely granted that misuse, or overuse, can lead to severe performance issues. But a fast path mechanism through SPIE/ESPIE, just for MC interrupts, could be expanded into a wonderful debugging mechanism. And with all the skills represented on this list, it could catch on like wildfire for Assembler-language developers. Most serious assembler language developers I know use this: http://www.colesoft.com/about.shtml There is also IDF from the High Level Assembler Toolkit which has some nice features, but doesn't debug authorized, cross memory, or SRB mode code. The entire HLASM toolkit -- including the debugger -- is only $99/month. -- 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: SLIP sliding away
snip No it doesn't. It means that SLIP was unable to find the module in one of the address spaces, and thus is waiting for a subsequent load of that module to occur at which point the trap could/would be activated. Note that if you specify multiple ASIDs, and the module is not at the same address in both ASIDs, you'll get a trap set at the first address range it found in one of those address spaces. One SLIP trap cannot cover two different ranges. It wasn't the case here, apparently, but if the module was loaded via LOAD with ADDR= and DE= I doubt that SLIP would find a matching PVTMOD as there is no CDE maintained for that module. -unsnip-- I can't help it; I've got to butt in here with one of my pet peeves. We'va all used GTF and SLIP at one time or another to try and debug system problems and, perhaps less often, application problems. I write almost all my code in Assembler and the lack of debugging tools that I can imbed into a product is one of my pet peeves. GTF quite often uses the MC instruction (like in GTRACE expansion) to hook into various routines at selected points. Why, in the name of all that's holy, can't application programmers, get access to the same kinds of interfaces? Freely granted, there's lots of room for abuse; freely granted that misuse, or overuse, can lead to severe performance issues. But a fast path mechanism through SPIE/ESPIE, just for MC interrupts, could be expanded into a wonderful debugging mechanism. And with all the skills represented on this list, it could catch on like wildfire for Assembler-language developers. (Never mind that I'm getting awful tired of trapping a EX of a EX instruction just to install a breakpoint!! :-) ) Any comments, Peter or Jim? -- 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 Google to promote computer programming for clouds
Shane, I guess you're right. I need more coffee this morning! =) Thanks, Gary Diehl MVS Support The glass is neither half full or half empty; the engineer who designed the glass simply allowed for a 100% increase in fluid storage. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shane Sent: Tuesday, October 09, 2007 8:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM Google to promote computer programming for clouds On Tue, 2007-10-09 at 07:38 -0500, Diehl, Gary (MVSSupport) wrote: Client/Server clusters? GDPS? Grid Computing? This is the next new thing? Don't be like that Gary. I twigged on this bit; -- 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: Hipersockets performance
On Tue, 9 Oct 2007 11:01:28 +0200, R.S. wrote: Jan MOEYERSONS wrote: STOR 'NULLFILE' 125 Storing data set NULLFILE ... I wonder where it went? Would that not be the equivalent of a dummy file? I seem to remember that //NONO DD DSN=NULLFILE is the same as //NONO DD DUMMY True, unless John G. is lurking to dispute what it says in the RM. It is the same. However NULLFILE can be used in FTP (as file name), while DD DUMMY would require special syntax. What's funny, NULLFILE requires RACF authorization. At least in ftp. My puzzlement arose when I discovered that some UNIX-like utilities such as ftp and cp fail when //'NULLFILE' is supplied as a source file, but (ftp at least) can use it as a target file. RACF seems not to be the answer because I don't believe RACF supports allowing write access to a data set while prohibiting read access. My conjecture now is that such utilities will supply default DCB attributes for an output data set, but not for an input data set: it makes little sense to try to guess characteristics of an input data set which has never been opened, while a reasonable guess can be made for creating a new data set. It's disappointing that such utilities don't follow through with their support of Classic data sets by displaying Classic messages such as IEC141I 013-nn which are well described in MC. (I'm guessing at the code; LOOKAT seems broken just now.) -- 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: SLIP sliding away
On Tue, 9 Oct 2007 09:07:12 -0500 Rick Fochtman [EMAIL PROTECTED] wrote: :I write :almost all my code in Assembler and the lack of debugging tools that I :can imbed into a product is one of my pet peeves. How would you like to imbed it? How would you expect that the end user would enable it? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: GETMAIN/FREEMAIN and virtual storage backing up
In [EMAIL PROTECTED], on 10/03/2007 at 10:18 AM, Tom Marchant [EMAIL PROTECTED] said: Just to nit pick a little... It is not a 0C4, but a PIC 4. No; 4 is protection. You'll get a page or segment[1] exception for an unallocated page, depending on whether the segment is allocated. [1] Or 64-bit equivalent. -- 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: GETMAIN/FREEMAIN and virtual storage backing up
In [EMAIL PROTECTED], on 10/03/2007 at 10:36 AM, Wayne Driscoll [EMAIL PROTECTED] said: This is an extremely complicated process, based on a number of factors, many of which your program has no control. However, your guess is usually correct, in that if the page returned has never been allocated to your program, then no real or aux storage will be allocated. On the first reference, the hardware will recognize an 0C4, No, a PIC 0010 or 0011, unless there's something new in 64-bit mode. 0C4 is an overloaded ABEND code that can mean any of PIC 4, 10 or 11 in an unexpected context. -- 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: IBM Tivoli License Compliance Manager for z/OS
Bill, Yes to both. I am not the end user, but am told that the group responsible for it is quite happy with its functionality. Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Johnson Sent: Friday, October 05, 2007 9:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IBM Tivoli License Compliance Manager for z/OS We are doing some initial information gathering on IBM's Tivoli License Compliance Manager for z/OS and was looking for any recommendations and/or feedback from shops that might be using it currently. Is it doing what it claims and how happy are you with it? TIA, Bill Johnson Systems Programmer Antares Management Solutions Cleveland, Ohio LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: GETMAIN/FREEMAIN and virtual storage backing up
On Tue, 9 Oct 2007 07:39:49 -0300 Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: :In [EMAIL PROTECTED], on :10/03/2007 : at 10:36 AM, Wayne Driscoll [EMAIL PROTECTED] said: : :This is an extremely complicated process, based on a number of factors, :many of which your program has no control. However, your guess is :usually correct, in that if the page returned has never been allocated to :your program, then no real or aux storage will be allocated. On the :first reference, the hardware will recognize an 0C4, : :No, a PIC 0010 or 0011, unless there's something new in 64-bit mode. 0C4 :is an overloaded ABEND code that can mean any of PIC 4, 10 or 11 in an :unexpected context. Now there is region 1st, 2nd 3rd (39-3B) as well. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SLIP sliding away
Rick said; I can't help it; I've got to butt in here with one of my pet peeves. We'va all used GTF and SLIP at one time or another to try and debug system problems and, perhaps less often, application problems. I write almost all my code in Assembler and the lack of debugging tools that I can imbed into a product is one of my pet peeves. GTF quite often uses the MC instruction (like in GTRACE expansion) to hook into various routines at selected points. Why, in the name of all that's holy, can't application programmers, get access to the same kinds of interfaces? Dude... check out the GTRACE macro, http://preview.tinyurl.com/2wfyrk GTRACE is the GTF interface and even though it is documented in the Auth guides, the MC interface does not require authorization AT ALL. The down side is that all other aspects of GTF require some local authority, to start GTF traces, and to get access to the trace dataset and/or IPCS to process the output. In a lot of places those are practically impossible for application people to get, but that's a site choice. If you had a gnarly problem you might be allowed access. But if you just want first class real time debugging and you don't have your own VM sandbox... Dave Cole's XDC is the only game in town. CC -- 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: problem with automatic handling of message IEC534D
Dan, I have installed the current version of the MPFXTALL from Glen. Now it works as desired. Only 2 messages are issued that the first message is not a WTOR and therefore no reply is issued. I have suppressed them. Thanks for your hints. kind regards Franz Josef Pohlen Dan D schrieb: As it's from CBT, I suggest you either contact the author (Glenn Siegel) or see if someone else knows this utility. It may have the capability now of GETing the next part of the message when the first IEC534D is seen. After a quick peek at the code, I noticed that Glen has made other updates for users. Maybe he'll add another keyword like REPLYWTOR so that it will only reply when the message is a WTOR, and ignore messages that are not. Glen's email address is in the CBT file as well as his web site (google MPFXTALL). Good luck. Dan D fjpohlen wrote: It is the MPFXTALL from CBT. Where do I have to specify the parameter list and how is it coded? kind regards Franz Josef Pohlen -- 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: GETMAIN/FREEMAIN and virtual storage backing up
Binyamin Dissen wrote: On Tue, 9 Oct 2007 07:39:49 -0300 Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: :No, a PIC 0010 or 0011, unless there's something new in 64-bit mode. 0C4 :is an overloaded ABEND code that can mean any of PIC 4, 10 or 11 in an :unexpected context. Now there is region 1st, 2nd 3rd (39-3B) as well. But not for storage acquired via GETMAIN or STORAGE OBTAIN. Only storage acquired via IARV64 is subject to region table exceptions. -- 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: Dumping SMF directly to TAPE
On October 7,2007 12:14 AM George Dranes wrote: Actually our SMF dump job dumps to a daily tape which in the next step is mod on to a weekly tape using IEBGENER (actually ICEGENER in our case). This weekly tape is then concatenated to a monthly tape once a week. I keep multiple generations of the daily and weekly files so I can easily rebuild if needed. Does this sound ok? Here I've set up the SMF rollup system to dump to a DASD dataset from the MAN files as they fill up during the day. Then just after midnight the automated ops system issues a final I SMF command. The dump datasets are then rolled up to daily dataset on virtual tape. After the daily run on Sunday morning the dailies are rolled up to weekly dataset on physical tape. We don't roll up to monthly datasets but keep 106 (2 years) of weekly generations. We use IFASMFDP to do our copying from dump to daily to weekly. I've also written a little SAS routine to keep the input generations in ascending numeric order. The first step of the roll up job creates an IDCAMS LISTCAT listing of the input which is read by the SAS program that creates the input DD statements. I've also split the daily and weekly SMF records into multiple groups based on how we process - one tape has CICS (SMF 110), another has DB2 (SMF 100-102), another has WLC required records (SMF 30, 70-79, and 89), and the last one has everything else. * 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. * -- 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: ADABAS vs IMS vs DB2 Who is faster?
Allan, Please can you explain to your audience how long have you been around and how long have you been workling with Adabas, IMS and DB2 ? Please define also what type of work have you been doing with all these Database software packages, if you can still remember.. Why ? In the USA there is lots of people that claim that they are experts.. specially if they work in a cage for a big company. Anton On Tue, 9 Oct 2007 08:11:23 -0500, Staller, Allan [EMAIL PROTECTED] wrote: snip Subject: ADABAS vs IMS vs DB2 Who is faster? I spoke few days ago with an ADABAS specialist that claimed that ADABAS is much faster and has low overhead compared to IMS and DB2. Is this true? /snip As with most things in this business, it depends. The first question to ask is What source are you citing to support your claim? Depending on the configuration and tuning options ADABAS may or may not be faster than DB2. DB2 may or may not have a smaller footprint than ADABAS. Because IMS uses an entirely different technique to access data, it *most likely* is somewhat faster than either IMS or DB2. In order to obtain this speed, the flexibility of using SQL is sacrificed. (Actually it is the other way around IMS preceded DB2/ADABAS by several years. The relative speed that is important is the one for *YOUR* workload. Anything else is meaningless noise. Thoroughly research the *features* important to you and go with the product that provides the best feature to price ratio for you. HTH, -- 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: DFHSM :ARC0560E - Message Clarity
Either adding space to ML1 or migrating some data off to ML2 would have cleared the issue. In either case you needed to release migration to start the migration process again! ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, October 09, 2007 8:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFHSM :ARC0560E - Message Clarity No, I didn't. I didn't see the message that the MIGRATION was held. I will take note of this to add to my procedures. Would you know if there is something else I should have done besides adding the disks? I thought of doing a MIGRATE1 to MIGRATE2. Would that have been a good move? Adams, Rick [EMAIL PROTECTED] wrote: Did you release migration after you added the ML1 volume? The message MIGRATION LIMITED means that it held migration. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, October 09, 2007 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM :ARC0560E - Message Clarity Good Day To All, I was investigatin problem ARC0521I - the PRIMARY SPACE MANAGEMENT ended due to a ARC0521I COMPLETION, RESOURCES NOT AVAILABLE. I found the message ARC0560E MIGRATION LIMITED: NO MIGRATION LEVEL 1 SPACE AVAILABLE, followed by subsequent messages : ARC0559I SPACE MANAGEMENT OF PROM116 WILL NOT TARGET 708 ARC0559I (CONT.) MIGRATION LEVEL 1 UNTIL THE REQUESTED VOLUME TYPE I ARC0559I (CONT.) MADE AVAILABLE I checked the message ARC0560E explanation but it didn't tell me much only to say that the there was a lack of available space for LEVEL 1. I added a level 1 volume but the problem didn't clear. I added another one still the problem persisted. Finally, I shutdown the STC and brought it up again. For some reason the problem was fixed. However, I am at a loss as to why this happened. Were my actions correct? Is there something else that I should have tried? Please let me know. -- 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: IBMLink is UP - just kidding
On 5 Oct 2007 11:39:50 -0700, [EMAIL PROTECTED] (Kelman, Tom) wrote: Just try Indiana. At least Arizona can agree on how to set their clocks state wide. Indiana can't even do that. Some of the state goes to Daylight Saving Time and some doesn't. On 5 Oct 2007 1:57 PM, Howard Brazee wrote: I thought I read that Indiana finally gave in.And I believe the big Navaho reservation is different from the rest of Arizona. Well, I did look it up and you are right. The Navaho reservation does observe Daylight Saving Time, the rest of Arizona doesn't. Also, now all of Indiana does observe it. That state is just divided between Eastern Time and Central Time, but there are other states split between time zones. Other states/territories of the USA that don't observe DST are Hawaii, Puerto Rico, The Virgin Islands, American Samoa, and Guam. Just a little trivia for this Tuesday that's a Monday for me since banks got the day off yesterday for Columbus Day. :) * 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. * -- 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: Enquiry!
On Tue, 09 Oct 2007 08:31:42 -0700, in bit.listserv.ibm-main you wrote: May I know the server name for thisgroup??? This group is a copy of a list server. If you are wanting to participate, subscribing would make sure any messages you sent get read by everybody. I have my participation set to not send me messages as e-mail, so I can read them from the newsgroup - but I try to send my messages to the list server. So the two locations (e-mail and Usenet) are different things - what are you actually looking to do? -- 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: ADABAS vs IMS vs DB2 Who is faster?
snip Please can you explain to your audience how long have you been around and how long have you been workling with Adabas, IMS and DB2 ? /snip I have been a MVS systems programmer for about 35 years. I have worked with IMS and DB2 for about 5 years. I have never worked with ADABAS. I have no aversion or affinity (currently) to any of the products above. None are in my current environment. IMS is a hierarchal database, and thus uses vastly different data storage/retrieval paradigms when compared to ADABAS or DB2. For single record update/retrieval (e.g. a banking deposit, account inquiry) IMS may be very much faster than ADABAS/DB2. For a report type application, (e.g. show all accounts with activity yesterday) ADABAS/DB2 may very well be faster that IMS. *IT DEPENDS*. My reply intent is to say the only right answer is the one that works for you. In other words caveat emptor. I did not mean to disparage the expert in your OP. I do not know if the expert in the OP was a sales engineer, one of your co-workers, or a true expert in ADABAS. Regardless s/he should be able to produce supporting documentation to back up his/her claim. (e.g. Transactions rates supported, resources consumed, ) As with most things in this business, *IT DEPENDS*. Anytime a blanket statement such as X is faster (or better) than Y, objective evidence is required before a decision is made on that basis alone. This does not preclude the fact that X may be still be chosen over Y, but the decision should be based on objective evidence (e.g. Benchmarks, publications by neutral parties, etc.), not on unsupported claims of superiority. -- 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: SLIP sliding away
--snip--- Dude... check out the GTRACE macro, http://preview.tinyurl.com/2wfyrk GTRACE is the GTF interface and even though it is documented in the Auth guides, the MC interface does not require authorization AT ALL. The down side is that all other aspects of GTF require some local authority, to start GTF traces, and to get access to the trace dataset and/or IPCS to process the output. In a lot of places those are practically impossible for application people to get, but that's a site choice. If you had a gnarly problem you might be allowed access. But if you just want first class real time debugging and you don't have your own VM sandbox... Dave Cole's XDC is the only game in town. unsnip--- I'm very familiar with GTRACE, having used it, and imbedded it within various SMF exits that I've written and installed. But I don't believe that a user (That's a four-letter word, I know.) should have to have the authority to use such tools to debug what is essentially an application program. I've looked at XDC, but it doesn't seem to lend itself easily to imbedding in an application that might very well be a OEM Software Product. It appears to be a great debugging tool, but I question the advisability of imbedding it in a fee-based product. If I execute a GTRACE macro in a product and GTF isn't active, it returnes directly to the code that executed it. I'd like to see a way to redirect it to my code, with a parm list similar (not necessarily exactly the same, but along the lines) to a SPIE/ESPIE exit, where I can examine the instruction and the code immediately after it and from that determine what storage areas may need to be displayed, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADABAS vs IMS vs DB2 Who is faster?
Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. Anton On Tue, 9 Oct 2007 11:22:57 -0500, Staller, Allan [EMAIL PROTECTED] wrote: snip Please can you explain to your audience how long have you been around and how long have you been workling with Adabas, IMS and DB2 ? /snip I have been a MVS systems programmer for about 35 years. I have worked with IMS and DB2 for about 5 years. I have never worked with ADABAS. I have no aversion or affinity (currently) to any of the products above. None are in my current environment. -- 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: SLIP sliding away
On Tue, 9 Oct 2007 11:26:51 -0500 Rick Fochtman [EMAIL PROTECTED] wrote: ::I write ::almost all my code in Assembler and the lack of debugging tools that I ::can imbed into a product is one of my pet peeves. :How would you like to imbed it? :---unsnip- :I don't really care whether it's via SPIE/ESPIE, STAE/ESTAE, or some PC :mechanism, as long as it's a reasonably fast mechanism. I suggested a :fast path via SPIE/ESPIE simply because I figure that a PC interrupt :should be fairly easy to trap through the SPIE/ESPIE mechanism in :Program Interrupt FLIH. It should NOT be a mechanism that requires :program authorization via the classic mechanism, thus available to the :general case application programmer. Even using the TRAP instructions :wouild be acceptable, if there's a mechanism to examine registers and/or :inline parameter lists and make approproate return adjustments to bypass it. :--snip--- :How would you expect that the end user would enable it? :unsnip--- :A PARM field, a control statement, or the inclusion of a special DD :statement; to me, any one of these would be acceptable. Obviously, each :has advantages and drawbacks but these can be taken into consideration :during the code development/generation process. :I'm currently working on a new version of the ARCHIVER (CBT File 147) :and because of the nature of the beast, I can't always visualze all :the possibilities that might lead to abends. But if someone is using it :and encounters a problem, being able to have him turn on a trace/debug :mechanism and recreate the problem would be of great advantage in :solving problems and improving the product. :I'm also working on tools for RACF reporting which I hope to market for :a very modest fee, and tools that help me debug newly-encountered :conditions would be of inestimable value, to me and to my prospective :customers. And let's face it, security is going to be a major concern in :computing for the foreseeable future, both in maintenance and auditing. :In my experience, (which I grant freely is NOT all-encompassing,) :reporting and auditing tools in this area are not optimal, to say the :least. (I remind the list of a previous post concerning a RACF auditor, :unnamed, who bought me a number of steak lunches, because of his lack of :experience and IMHO adequate training. Not his fault, but rather a :reflection of industry's attidute toward security at the time.) So why doesn't the very straightforward solution of a DEBUG parm and calls to debug logic in the code work? You can have multiple debug flags (routine entry exit, record read, etc.). -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SLIP sliding away
-snip :I write :almost all my code in Assembler and the lack of debugging tools that I :can imbed into a product is one of my pet peeves. How would you like to imbed it? ---unsnip- I don't really care whether it's via SPIE/ESPIE, STAE/ESTAE, or some PC mechanism, as long as it's a reasonably fast mechanism. I suggested a fast path via SPIE/ESPIE simply because I figure that a PC interrupt should be fairly easy to trap through the SPIE/ESPIE mechanism in Program Interrupt FLIH. It should NOT be a mechanism that requires program authorization via the classic mechanism, thus available to the general case application programmer. Even using the TRAP instructions wouild be acceptable, if there's a mechanism to examine registers and/or inline parameter lists and make approproate return adjustments to bypass it. --snip--- How would you expect that the end user would enable it? unsnip--- A PARM field, a control statement, or the inclusion of a special DD statement; to me, any one of these would be acceptable. Obviously, each has advantages and drawbacks but these can be taken into consideration during the code development/generation process. I'm currently working on a new version of the ARCHIVER (CBT File 147) and because of the nature of the beast, I can't always visualze all the possibilities that might lead to abends. But if someone is using it and encounters a problem, being able to have him turn on a trace/debug mechanism and recreate the problem would be of great advantage in solving problems and improving the product. I'm also working on tools for RACF reporting which I hope to market for a very modest fee, and tools that help me debug newly-encountered conditions would be of inestimable value, to me and to my prospective customers. And let's face it, security is going to be a major concern in computing for the foreseeable future, both in maintenance and auditing. In my experience, (which I grant freely is NOT all-encompassing,) reporting and auditing tools in this area are not optimal, to say the least. (I remind the list of a previous post concerning a RACF auditor, unnamed, who bought me a number of steak lunches, because of his lack of experience and IMHO adequate training. Not his fault, but rather a reflection of industry's attidute toward security at the time.) -- 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: SLIP sliding away
At 10/9/2007 12:36 PM, Rick Fochtman wrote: [snip] But I don't believe that a user (That's a four-letter word, I know.) should have to ... [snip] I've looked at XDC, but it doesn't seem to lend itself easily to imbedding in an application that might very well be a OEM Software Product. It appears to be a great debugging tool, but I question the advisability of imbedding it in a fee-based product. Dude! Here's another four letter word: HOOK! z/XDC allows you, at execution time, to dynamically insert a hook into live code that creates a debugging session on the fly! There is no need to modify product code (either source or object) if you don't want to... Talk to Bob. Take one of his classes. He will show you how to do it... Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 Bob Shimizu [EMAIL PROTECTED] 800-XDC-5150 -- 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: SLIP sliding away
On Tue, 9 Oct 2007 13:13:57 -0400 David Cole [EMAIL PROTECTED] wrote: :At 10/9/2007 12:36 PM, Rick Fochtman wrote: :[snip] :But I don't believe that a user (That's a four-letter word, I know.) :should have to ... :[snip] :I've looked at XDC, but it doesn't seem to lend itself easily to :imbedding in an application that might very well be a OEM Software :Product. It appears to be a great debugging tool, but I question :the advisability of imbedding it in a fee-based product. :Dude! Here's another four letter word: HOOK! :z/XDC allows you, at execution time, to dynamically insert a hook :into live code that creates a debugging session on the fly! There is :no need to modify product code (either source or object) if you don't :want to... :Talk to Bob. Take one of his classes. He will show you how to do it... I don't think that he can count on his end-users having an XDC license. Do you provide a license where he can supply some run-time material for his clients? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SLIP sliding away
At 10/9/2007 01:19 PM, Binyamin Dissen wrote: I don't think that he can count on his end-users having an XDC license. Do you provide a license where he can supply some run-time material for his clients? We can do that. Talk to Bob. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: ADABAS vs IMS vs DB2 Who is faster?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton Britz Sent: Tuesday, October 09, 2007 11:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ADABAS vs IMS vs DB2 Who is faster? Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. SNIP PLUNK! -- 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: ADABAS vs IMS vs DB2 Who is faster?
I supported ADABAS for 2 years about 20 years ago. What I remember was the SVC that modified itself and still running with 24 bit addressability. Don't get me wrong - I could write amazing programs in Natural in just a couple of hours but the other restrictions were painfull. Went on an interview for a DB2 job and discovered they still had ADABAS - asked how they managed it - basically they created a new ADABAS collection for every application area that wanted it. You have to backup the entire database - can't select one application and create a backup point. Started working as IMS DBA with 1.1.5 - I think - been applications, system DBA and sysprog. Never did past path but all combinations of HDAM, HIDAM, SHISAM, etc It is very difficult to beat the performance of a properly designed HDAM application unless the users require a half dozen secondary indexes. Problem was the 2G/4G dataset limit - IBM didn't release partitioned database until V9. Yes, you could move segments to a separate dataset (max of 10) but it created performance problems as often as solving them. People did all kinds of unusual design work to support more than 4G of data. One place had a dozen PCB's that were selected by application based on key range. first supported DB2 as sysprog on 1.2. My mistake of being in the IMS group and saying it isn't that hard - just another database -setup 1,2,3 write a userid exit and let the applications groups go. SQL is different. It requires a different type of design. I think it is harder to build a good SQL design than IMS because you have so many choices and the SQL hides the performance impact of those choices.The ability to use big bufferpools can also hide bad design. It can still meet response time goals but use more resources than it should. The other part is that DB2 started with a 64G limit and has expanded that multiple times. ADABAS does use less memory and disk space than DB2 but it doesn't scale to really large applications the way DB2 does and it doesn't let you keep the database up while some portion of the database is having utilities run. Mike On 10/7/07, Itschak Mugzach [EMAIL PROTECTED] wrote: I spoke few days ago with an ADABAS specialist that claimed that ADABAS is much faster and has low overhead compared to IMS and DB2. Is this true? Itschak -- 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 -- Mike -- 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: ADABAS vs IMS vs DB2 Who is faster?
Thank goodness our moral compass is still around... -Original Message-From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton BritzSent: Tuesday, October 09, 2007 12:37 PMTo: [EMAIL PROTECTED]: Re: ADABAS vs IMS vs DB2 Who is faster? Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. Anton -Original Message-From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton BritzSent: Tuesday, October 09, 2007 12:37 PMTo: [EMAIL PROTECTED]: Re: ADABAS vs IMS vs DB2 Who is faster? Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. Anton _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews -- 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: About CA-Allocate and High Water Mark postings
Duane, Snip First, I work for DTS but the important difference between products that reduce out of space conditions is when is the data set selected to be a candidate for recovery. Snip CA-Allocate works the same way as Stop X37 and SRS. It intercepts the X37. I worked with the CA-Allocate for 10 years. You can increase/decrease primary or secondary whenever a new extent is obtained and add volumes one by one at EOV. All the accounting info, access method including EXCP and lots of other attributes are all available via variables so you can decide if the allocation can be changed. The product is also aware of well known products and prevents changes where these are not supported. Tony. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.5/1058 - Release Date: 08/10/2007 16:54 -- 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: SLIP sliding away
snip-- So why doesn't the very straightforward solution of a DEBUG parm and calls to debug logic in the code work? You can have multiple debug flags (routine entry exit, record read, etc.). --unsnip--- In many, probably most, cases, that will work just fine; certainly for ARCHIVER or my RACF report goodies. I was hoping to find/develop a more elegant mechanism that would be less dependant on imbedded code, mainly because of size and re-entranterability considerations. I had even considered the use of S-Cons to keep parm lists short! My aim was/is a generalized mechanism to dump registers and selected storage areas at specific points in the code, like parm flags, storage buffers, selected control blocks etc. A single SPIE/ESPIE/STAE/ESTAE parm list and a single exit routine might satisfy all these needs, whereas a CALL to another routine would (PROBABLY) destroy registers 14 and 15, and possibly 0 and 1. At one time, I even considered using SDUMP's and a special processor for AMDPRDMP! -- 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: ADABAS vs IMS vs DB2 Who is faster?
Did I stumble into a dark closet and find myself trapped in a job interview? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of CICS Guy Sent: Tuesday, October 09, 2007 1:30 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ADABAS vs IMS vs DB2 Who is faster? Thank goodness our moral compass is still around... -Original Message-From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton BritzSent: Tuesday, October 09, 2007 12:37 PMTo: [EMAIL PROTECTED]: Re: ADABAS vs IMS vs DB2 Who is faster? Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. Anton -Original Message-From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton BritzSent: Tuesday, October 09, 2007 12:37 PMTo: [EMAIL PROTECTED]: Re: ADABAS vs IMS vs DB2 Who is faster? Hi, Summarized : a) So you never worked with ADABAS in your life b) You only worked with IMS and DB2 for 5 years... maybe as a user but you are talking about : a) SQL b) Database access methods c) Which Database people should be using Summarized : Are you working for the 'White house maybe because everybody there is also experts but the funny part ? your post your findings to an IBM technical list... Tell me , what should I invest my money in ? I need investment advice too.. Anton _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailn ews -- 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: SLIP sliding away
On Oct 9, 2007, at 12:13 PM, David Cole wrote: At 10/9/2007 12:36 PM, Rick Fochtman wrote: [snip] But I don't believe that a user (That's a four-letter word, I know.) should have to ... [snip] I've looked at XDC, but it doesn't seem to lend itself easily to imbedding in an application that might very well be a OEM Software Product. It appears to be a great debugging tool, but I question the advisability of imbedding it in a fee-based product. Dude! Here's another four letter word: HOOK! z/XDC allows you, at execution time, to dynamically insert a hook into live code that creates a debugging session on the fly! There is no need to modify product code (either source or object) if you don't want to... Talk to Bob. Take one of his classes. He will show you how to do it... Not speaking for Rick, but in agreement with him. As he mentioned the viability of putting into production a $$ tool . I have seen various programmers try to put various debugging tools into production and have seen it slip by (into production once or twice) don't go there. Being called (as a sysprog) at xx AM because the tool doesn't work or its causing production stoppage is not fun and it gets really nasty when it comes to politics at someone else on the list says BTDTGTS . IF you let the tool run loose heaven help you if the tool expires at xx AM and trying to get a hold of the vendor that does 9-5 in another time zone or even worse in on the other side of the pond (Atlantic or Pacific). NO THANKS and another BTDTGS. Ed -- 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: Zos 1.7
Thanks to all who replied. It turned out to be a grs problem Thank You... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Skip Robinson Sent: Monday, October 08, 2007 3:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Zos 1.7 I'm having trouble tying this 'problem' to a specific z/OS level, but we discovered in early 2005 that one system in the enterprise was seeing hugely elongated execution times for some catalog intensive jobs. Like 10 - 20 longer (!) on a massively configured production LPAR vs. even a puny little sandbox. Diagnostic data--sorry I don't remember the mechanism--point to GRS. The one obvious difference was that the problem system was the only full parallel sysplex *not* using GRS star. This system had been sysplexed some time earlier in order to debug some DB2 issues, but the 'other' member was not being IPLed on a regular basis. In other words, a single parallel sysplex capable system running in practice by itself in GRS ring mode. Taking the duh! approach, we converted the problem system/sysplex to GRS star. The GRS delays disappeared immediately, making the system look just like all the rest. Just another thing to look at. . . 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] Carroll, William [EMAIL PROTECTED] To NSURANCE.COM IBM-MAIN@BAMA.UA.EDU Sent by: IBM cc Mainframe Discussion List Subject [EMAIL PROTECTED] Re: Zos 1.7 .EDU 10/08/2007 12:14 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU I am 99% sure its within dfsms.. On a catalog report all numbers Across the board are extremely higher..especially the mvs and bcs allocate. Bill -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Monday, October 08, 2007 3:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: RES: Zos 1.7 Are you sure is it a catalog problem ? What is your main delay reported by RMF ? 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 Carroll, William Enviada em: segunda-feira, 8 de outubro de 2007 15:01 Para: IBM-MAIN@BAMA.UA.EDU Assunto: Zos 1.7 We converted to 1.7 over the weekend, mostly good, but a couple of really weird problems. Job used to execute in 4 minutes now Takes 20...Only that one job. A couple of jobs running snap, are taking a bit longer as well. Is everybody running with the Catalog auto tune on? I am just grabbing at straws. Any insight or thoughts would be greatly appreciated. Thank You Bill Carroll -- 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 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
Re: SLIP sliding away
Ed Gould wrote: Not speaking for Rick, but in agreement with him. As he mentioned the viability of putting into production a $$ tool . I have seen various programmers try to put various debugging tools into production and have seen it slip by (into production once or twice) don't go there. Being called (as a sysprog) at xx AM because the tool doesn't work or its causing production stoppage is not fun and it gets really nasty when it comes to politics at someone else on the list says BTDTGTS . IF you let the tool run loose heaven help you if the tool expires at xx AM and trying to get a hold of the vendor that does 9-5 in another time zone or even worse in on the other side of the pond (Atlantic or Pacific). NO THANKS and another BTDTGS. What Dave was trying to say was that z/XDC is not linked with or installed with your code at all. The risks you allude to don't exist. When you decide you want to debug a program, you can HOOK it on the fly (even if it hasn't been LOADed yet). The debugger dynamically overlays part of your program with a sequence of instructions that allows it to gain control and pause your program. After it gets control, it restores the instructions that were there to begin with. Then, you can step through your program instruction-by-instruction and, if you keep your ADATA around for the module being debugged, you can even use full source-level debugging (like stepping through an assembler source listing). You can change registers on the fly, change data on the fly, change instructions on the fly, take branches, don't take them, jump anywhere in the code ... you name it! -- 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: SLIP sliding away
At 10/9/2007 03:06 PM, Edward Jaffe wrote: What Dave was trying to say was that z/XDC is not linked with or installed with your code at all. The risks you allude to don't exist. When you decide you want to debug a program, you can HOOK it on the fly (even if it hasn't been LOADed yet). The debugger dynamically overlays part of your program with a sequence of instructions that allows it to gain control and pause your program. After it gets control, it restores the instructions that were there to begin with. Then, you can step through your program instruction-by-instruction and, if you keep your ADATA around for the module being debugged, you can even use full source-level debugging (like stepping through an assembler source listing). You can change registers on the fly, change data on the fly, change instructions on the fly, take branches, don't take them, jump anywhere in the code ... you name it! Well said, Ed. I couldn't have said it better myself. (In fact I didn't say it nearly as well.) Thanks, Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: SLIP sliding away
At 10/9/2007 02:53 PM, Ed Gould wrote: Not speaking for Rick, but in agreement with him. As he mentioned the viability of putting into production a $$ tool . I have seen various programmers try to put various debugging tools into production and have seen it slip by (into production once or twice) don't go there. Being called (as a sysprog) at xx AM because the tool doesn't work or its causing production stoppage is not fun and it gets really nasty when it comes to politics at someone else on the list says BTDTGTS . IF you let the tool run loose heaven help you if the tool expires at xx AM and trying to get a hold of the vendor that does 9-5 in another time zone or even worse in on the other side of the pond (Atlantic or Pacific). NO THANKS and another BTDTGS. Ed Hi Ed, Perhaps I've been reading things too hurriedly. Maybe I missed the thrust of Rick's comment. What you are concerned about is the possibility of letting a distribution copy of a product get out the door with a debugging interface still activated. That, of course, can lead to unhappy situations at customer sites should the debugging interface get executed. I agree. That sort of thing must never be allowed to happen. But to my mind, avoiding such a situation is very easy: Just make the debugging interface fail-safe. Code it so as to require some additional action of environmental characteristic without which the interface simply does nothing, NOPs as if it did not exist. And there are any number of ways to do that: One way is to code a closed permanent branch around the interface activation code. Then a manual zap by the developer would be required, without which the code could never be executed. Another might be to require the presence of a secret keyword ddname, example //DEBUGME DD DUMMY. Then a simple TIOT scan would be all that was needed for the debugging interface to know whether it should allow debugging or just step aside. Another might be to check the environment for your own computer's local SYSPLEX name, SMF name, CPU id/serial#, TSO userid, RACF ownerid, ... whatever. Absent the right value, the debugging interface would not permit debugging. I really don't see that there is a serious problem here. (Or am I still missing the point?) Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: ADABAS vs IMS vs DB2 Who is faster?
Hi, Come on Cics guy... There is a lot of us reading most of this junk on IBM-MAIN and : a) Asking a question b) Making a statement on what you really know well is acceptably to most... but how big is your World if you make a signon called Cics Guy and then want to talk about morality ? Oh, I get it.. you do not like me referring to the people you voted for. Anton Britz ( this is my real name ) On Tue, 9 Oct 2007 14:30:05 -0400, CICS Guy [EMAIL PROTECTED] wrote: Thank goodness our moral compass is still around... -- 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: SLIP sliding away
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Tuesday, October 09, 2007 2:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SLIP sliding away SNIP I really don't see that there is a serious problem here. (Or am I still missing the point?) SNIP Because there isn't one. Take it from someone who HAS used (and still does) XDC. I am not allowed (because of Non-Disclosure Agreements for starters) to divulge what ISV products are developed (or were) and maintained using XDC. AND are shipped with XDC hooks embedded so that IFF the customer site has XDC, it can be debugged remotely. IT WORKS. And, IFF you have the right authorization, you can debug your code right into SCP code. Take the class from Bob. You will be very glad you did. And trust me, it is a better tool than TSO TEST, TEST AUTH or CP's AD STOP, and FAR better than SLIP/IPCS. Regards, Steve Thompson -- Opinions expressed are strictly my own. -- -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SLIP sliding away
On Oct 9, 2007, at 2:06 PM, Edward Jaffe wrote: Ed Gould wrote: Not speaking for Rick, but in agreement with him. As he mentioned the viability of putting into production a $$ tool . I have seen various programmers try to put various debugging tools into production and have seen it slip by (into production once or twice) don't go there. Being called (as a sysprog) at xx AM because the tool doesn't work or its causing production stoppage is not fun and it gets really nasty when it comes to politics at someone else on the list says BTDTGTS . IF you let the tool run loose heaven help you if the tool expires at xx AM and trying to get a hold of the vendor that does 9-5 in another time zone or even worse in on the other side of the pond (Atlantic or Pacific). NO THANKS and another BTDTGS. What Dave was trying to say was that z/XDC is not linked with or installed with your code at all. The risks you allude to don't exist. When you decide you want to debug a program, you can HOOK it on the fly (even if it hasn't been LOADed yet). The debugger dynamically overlays part of your program with a sequence of instructions that allows it to gain control and pause your program. After it gets control, it restores the instructions that were there to begin with. Then, you can step through your program instruction-by- instruction and, if you keep your ADATA around for the module being debugged, you can even use full source-level debugging (like stepping through an assembler source listing). You can change registers on the fly, change data on the fly, change instructions on the fly, take branches, don't take them, jump anywhere in the code ... you name it! Ed, In this case maybe but I have seen this happen with other products (3 come to mind) . One was dynamic but it depended on other software in CICS to get it to work. The CICS (batch or CICS) debugger was very MVS release dependent, often the issues did not show up until the system was heavily loaded. I am extremely suspicious of any debugger that makes claims. I have heard lots of good stuff about the product, but until I have witnessed it personally I will reserve judgement. Ed -- 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: SLIP sliding away
On Tue, 9 Oct 2007 13:36:41 -0500 Rick Fochtman [EMAIL PROTECTED] wrote: :snip-- :So why doesn't the very straightforward solution of a DEBUG parm and :calls to debug logic in the code work? You can have multiple debug flags :(routine entry exit, record read, etc.). :--unsnip--- :In many, probably most, cases, that will work just fine; certainly for :ARCHIVER or my RACF report goodies. I was hoping to find/develop a more :elegant mechanism that would be less dependant on imbedded code, :mainly because of size and re-entranterability considerations. I had :even considered the use of S-Cons to keep parm lists short! My aim :was/is a generalized mechanism to dump registers and selected storage :areas at specific points in the code, like parm flags, storage buffers, :selected control blocks etc. A single SPIE/ESPIE/STAE/ESTAE parm list :and a single exit routine might satisfy all these needs, whereas a CALL :to another routine would (PROBABLY) destroy registers 14 and 15, and :possibly 0 and 1. At one time, I even considered using SDUMP's and a :special processor for AMDPRDMP! If it is problem state code, you can have the end user run it in the background TMP under TSO TEST with a script. TEST 'program' 'parameters' AT location (L whatever;GO) {defer} . . GO L 15R END and SYSTSPRT will have the debug output. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: ADABAS vs IMS vs DB2 Who is faster?
Hi, I am 100% convinced, the computer world in the USA is like another Iraq story... Here we have another person that worked with Adabas 20 years a'go and he wants to compare Databases. You can be succesful in the USA ... hang in there.. stay the course. Anton Britz 7 13:23:49 -0500, Mike Bell [EMAIL PROTECTED] wrote: I supported ADABAS for 2 years about 20 years ago. What I remember was the -- 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: ADABAS vs IMS vs DB2 Who is faster?
Hello Mike, Most of the restrictions in the classes you mentioned disappeared from ADABAS years ago. In our shop we yo-yo the ADABAS databases weekly - though I know many shops that yo-yo the database only when an IPL is required. We run backups every day - this can be done on only those blocks that have changed, only certain files, while in use ... Production changes can be implemented on the fly - new fields, new indexes ... can be made while the file being modified is in use. ADABAS fully supports a sysplex and can actually scale quite well. I have practically no DB2 or IMS experience so am not able to compare. An optional optimizing compiler can be purchased for Natural. I've seen the code it generates (it's good) and benchmarked it against optimized COBOL - Natural won every test, from highly computational, to highly i/o bound. I don't know what troubles you were having but things have changed a lot. ADABAS does not support SQL but an interface can be purchased from Software AG or a couple other vendors. Best Regards Kelly Jones Penske Logistics -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Bell Sent: Tuesday, October 09, 2007 2:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ADABAS vs IMS vs DB2 Who is faster? I supported ADABAS for 2 years about 20 years ago. What I remember was the SVC that modified itself and still running with 24 bit addressability. Don't get me wrong - I could write amazing programs in Natural in just a couple of hours but the other restrictions were painfull. Went on an interview for a DB2 job and discovered they still had ADABAS - asked how they managed it - basically they created a new ADABAS collection for every application area that wanted it. You have to backup the entire database - can't select one application and create a backup point. Started working as IMS DBA with 1.1.5 - I think - been applications, system DBA and sysprog. Never did past path but all combinations of HDAM, HIDAM, SHISAM, etc It is very difficult to beat the performance of a properly designed HDAM application unless the users require a half dozen secondary indexes. Problem was the 2G/4G dataset limit - IBM didn't release partitioned database until V9. Yes, you could move segments to a separate dataset (max of 10) but it created performance problems as often as solving them. People did all kinds of unusual design work to support more than 4G of data. One place had a dozen PCB's that were selected by application based on key range. first supported DB2 as sysprog on 1.2. My mistake of being in the IMS group and saying it isn't that hard - just another database -setup 1,2,3 write a userid exit and let the applications groups go. SQL is different. It requires a different type of design. I think it is harder to build a good SQL design than IMS because you have so many choices and the SQL hides the performance impact of those choices.The ability to use big bufferpools can also hide bad design. It can still meet response time goals but use more resources than it should. The other part is that DB2 started with a 64G limit and has expanded that multiple times. ADABAS does use less memory and disk space than DB2 but it doesn't scale to really large applications the way DB2 does and it doesn't let you keep the database up while some portion of the database is having utilities run. Mike On 10/7/07, Itschak Mugzach [EMAIL PROTECTED] wrote: I spoke few days ago with an ADABAS specialist that claimed that ADABAS is much faster and has low overhead compared to IMS and DB2. Is this true? Itschak -- 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 -- Mike -- 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: PEND (was: System REXX for z/OS R8 Web ...)
My 2.10 manual says it is optional in a catalogued procedure. I have some in the proclib used for started tasks and also in the proclib used for batch jobs. -Original Message- From: Paul Gilmartin [mailto:snip] Sent: Friday, October 05, 2007 9:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: PEND (was: System REXX for z/OS R8 Web ...) Is PEND tolerated in library PROCs nowadays? I have always considered it a PITA and extraordinarily stupid that it isn't (wasn't?). Was this changed to accommodate // INCLUDE? -- 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: SLIP sliding away
On Oct 9, 2007, at 2:20 PM, David Cole wrote: -SNIP- Hi Ed, Perhaps I've been reading things too hurriedly. Maybe I missed the thrust of Rick's comment. What you are concerned about is the possibility of letting a distribution copy of a product get out the door with a debugging interface still activated. That, of course, can lead to unhappy situations at customer sites should the debugging interface get executed. I agree. That sort of thing must never be allowed to happen. But to my mind, avoiding such a situation is very easy: Just make the debugging interface fail-safe. Code it so as to require some additional action of environmental characteristic without which the interface simply does nothing, NOPs as if it did not exist. And there are any number of ways to do that: One way is to code a closed permanent branch around the interface activation code. Then a manual zap by the developer would be required, without which the code could never be executed. Another might be to require the presence of a secret keyword ddname, example //DEBUGME DD DUMMY. Then a simple TIOT scan would be all that was needed for the debugging interface to know whether it should allow debugging or just step aside. Another might be to check the environment for your own computer's local SYSPLEX name, SMF name, CPU id/serial#, TSO userid, RACF ownerid, ... whatever. Absent the right value, the debugging interface would not permit debugging. I really don't see that there is a serious problem here. (Or am I still missing the point?) Just a little. Even *IF* you were to only let the debug product work in a specific environment (you gave a fair list) the problem comes in to play about exceptions. If people (ie programmers) were really honest it would not be an issue but programmers have this attitude what ever I can get away with I will and point fingers if he can't. While I can say its not just programmers its a fair share as programmers are bright and they can/do squeeze through any loop hole that can be found. BTW after thinking it through I would rather not have the dependancies name you mentioned as DR comes into play and heaven help you if things don't work EXACTLY as they did in the home system. The auditors would be screaming for my neck. The secret DDNAME does not work unless it changes say every week (or so) as people let the cat out of the bag without thinking. A long time ago I put a daily changing password in cols 73-80 of the JCL card to allow stepcat/jobcat to go through, I would suspect that the code is still running to this day (15+ years later). I have no experience with your code and I was not pointing out any issues with your product (just OTHER debugging products). Ed -- 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: ADABAS vs IMS vs DB2 Who is faster?
Boys, please relax. I wonder why TPC-C tests are only done for the distributed platforms databases (or their DP versions). Within its members are IBM, Oracle (MF version) Sybase(the same) and others. Maybe, because TPC heard (too early, I must say) that the mainframe is dead? Itschak -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jones, Kelly (Indust, PTL) Sent: Tuesday, October 09, 2007 9:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ADABAS vs IMS vs DB2 Who is faster? Hello Mike, Most of the restrictions in the classes you mentioned disappeared from ADABAS years ago. In our shop we yo-yo the ADABAS databases weekly - though I know many shops that yo-yo the database only when an IPL is required. We run backups every day - this can be done on only those blocks that have changed, only certain files, while in use ... Production changes can be implemented on the fly - new fields, new indexes ... can be made while the file being modified is in use. ADABAS fully supports a sysplex and can actually scale quite well. I have practically no DB2 or IMS experience so am not able to compare. An optional optimizing compiler can be purchased for Natural. I've seen the code it generates (it's good) and benchmarked it against optimized COBOL - Natural won every test, from highly computational, to highly i/o bound. I don't know what troubles you were having but things have changed a lot. ADABAS does not support SQL but an interface can be purchased from Software AG or a couple other vendors. Best Regards Kelly Jones Penske Logistics -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Bell Sent: Tuesday, October 09, 2007 2:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ADABAS vs IMS vs DB2 Who is faster? I supported ADABAS for 2 years about 20 years ago. What I remember was the SVC that modified itself and still running with 24 bit addressability. Don't get me wrong - I could write amazing programs in Natural in just a couple of hours but the other restrictions were painfull. Went on an interview for a DB2 job and discovered they still had ADABAS - asked how they managed it - basically they created a new ADABAS collection for every application area that wanted it. You have to backup the entire database - can't select one application and create a backup point. Started working as IMS DBA with 1.1.5 - I think - been applications, system DBA and sysprog. Never did past path but all combinations of HDAM, HIDAM, SHISAM, etc It is very difficult to beat the performance of a properly designed HDAM application unless the users require a half dozen secondary indexes. Problem was the 2G/4G dataset limit - IBM didn't release partitioned database until V9. Yes, you could move segments to a separate dataset (max of 10) but it created performance problems as often as solving them. People did all kinds of unusual design work to support more than 4G of data. One place had a dozen PCB's that were selected by application based on key range. first supported DB2 as sysprog on 1.2. My mistake of being in the IMS group and saying it isn't that hard - just another database -setup 1,2,3 write a userid exit and let the applications groups go. SQL is different. It requires a different type of design. I think it is harder to build a good SQL design than IMS because you have so many choices and the SQL hides the performance impact of those choices.The ability to use big bufferpools can also hide bad design. It can still meet response time goals but use more resources than it should. The other part is that DB2 started with a 64G limit and has expanded that multiple times. ADABAS does use less memory and disk space than DB2 but it doesn't scale to really large applications the way DB2 does and it doesn't let you keep the database up while some portion of the database is having utilities run. Mike On 10/7/07, Itschak Mugzach [EMAIL PROTECTED] wrote: I spoke few days ago with an ADABAS specialist that claimed that ADABAS is much faster and has low overhead compared to IMS and DB2. Is this true? Itschak -- 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 -- Mike -- 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: SLIP sliding away
Rick said I've looked at XDC, but it doesn't seem to lend itself easily to imbedding in an application that might very well be a OEM Software Product. It appears to be a great debugging tool, but I question the advisability of imbedding it in a fee-based product. You don't need to embed it to integrate it, even in shipping ISV code. Dave and others have mentioned the HOOK command - which works exactly as advertised. But there is another way to integrate XDC with your code. The only trick you need is to call XDC from your own recovery code, passing the SDWA in the same manner that your own code got it from RTM. When XDC returns control you do whatever the RC indicates. If you got a 4, then Dave has already done everything for you and you just return to RTM. If you get anything else you go on about your business and handle recovery. There are a few minutiae about handling END COMPLETELY and conditionally establishing addressability to XDC - left as an exercise to the reader. If you DO that, then your debugging environment is completely baked into your code, but there is no physical dependence on XDC and no way for fat fingered programmers to blunder into it. A certain family of products that I've had a passing association with :-) are -ALL- like that. Recovery and diagnostic support is always there no matter what. And if XDC is present and you're properly authorized, you can just use it. If it's not present, or it is, but you're not authorized for it, you don't even know its there. No muss, no fuss. No worries. CC -- 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: SLIP sliding away
Craddock, Chris wrote: [snip] If you DO that, then your debugging environment is completely baked into your code, but there is no physical dependence on XDC and no way for fat fingered programmers to blunder into it. A certain family of products that I've had a passing association with :-) are -ALL- like that. Recovery and diagnostic support is always there no matter what. And if XDC is present and you're properly authorized, you can just use it. If it's not present, or it is, but you're not authorized for it, you don't even know its there. No muss, no fuss. No worries. Yup! I deliberately didn't go there because the typical non-ISV user probably won't feel the need to integrate with z/XDC to that extent. However, this level of integration, exactly what Steve Thompson was alluding to in his post, is a *must* if you're going to debug exotic code (e.g., SRB mode -- which can't be HOOKed in the traditional way) and/or you want to be able to use and/or debug your recovery routines during a z/XDC session. I'll bet most savvy ISVs are doing it just like you described! -- 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
CICS TS V2.3 - End-of-Marketing and End-of-Service dates
I sent the following information to the SHARE LNGC project email list, but thought that some within IBM-MAIN and comp.lang.cobol might also be interested (impacted). Today, Oct 9, in IBM (US) announcement 907-207 that you can view online at: http://www.ibm.com/vrm/newsletter_10577_2055_47992_email_DYN_1IN/WKlein1 2584487 IBM has announced that CICS TS V2.3 will be withdrawn from marketing on January 14, 2008 (in the US) with a statement of direction that they plan on removing it from service on September 30, 2009. The significance to readers of this note is that this is the LAST release of CICS TS for which IBM provides support for OS/VS COBOL compiled programs. (After this, they won't even come up in an IBM-only environment. I assume that those for whom this might matter, already know that there is at least one 3rd party vendor - and possibly more - that provides their own support for OS/VS COBOL compiled programs in later versions of CICS - but this does not change the fact that IBM support won't be available.) If this is an issue for your shop, please make certain that all the appropriate people are made aware of it. If you are outside the US, then you should check for a corresponding announcement letter in your area. -- Bill Klein wmklein at ix.netcom.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: SLIP sliding away
At 10/9/2007 03:46 PM, Ed Gould wrote: [snip] BTW after thinking it through I would rather not have the dependancies name you mentioned as DR comes into play [...] Yep. That's a good point. The secret DDNAME does not work unless it changes say every week (or so) as people let the cat out of the bag without thinking... I was thinking of secret from customers so that they would not accidently and unexpectedly be confronted with a debugging interface for which they would not have the background knowledge for using said interface. But secret was too strong a word for me to use. What I really was talking about was a ddname that was unlikely to be used accidently by a customer. Nothing more than that. If a customer wants to intentionally inflict such pain upon himself (debugging code for which he has no source), why would that be of particular concern? I just don't get why this would be a cat that had to be kept in a bag... In any case, this is all beside the point. I was just giving some examples of how a developer might keep a customer from accidentally having to cope with an internal debugging interface that he should never have to see anyway. There are maybe thousands of other ways to afford this sort of protection, ranging from very simple to very complex. If you find shortcomings in my suggestions, well you're a smart person. If you wanted to, I'm sure you could find a way to both enjoy the benefits of an interactive debugger (such as z/XDC) and keep it from appearing in the wrong context. [snip] If people (ie programmers) were really honest it would not be an issue but programmers have this attitude what ever I can get away with I will and point fingers if he can't. While I can say its not just programmers its a fair share as programmers are bright and they can/do squeeze through any loop hole that can be found ... Wow! I'm sure glad I've never had to work with the lowlife that you've suffered with! Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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
Health CHECK(IBMCSV,CSV_LNKLST_NEWEXTENTS)
Seems like this health check should recognize when no jobs are using an obsolete LNKLST set and stop complaining without having to update the check PARM with NEW(). I put a load library on the IPL-time LNKLST with a secondary space amount, forced it to add an extent, ran this health check and, as expected, received RC=12 with the following report: |CSVH0969I LNKLST set IPLTIME | |The error status is in column one: |C = Confirmed error* = New error- = Unknown | | ORIG CURR VOLUME DSNAME |* 56 MVSSY1 SYS2.E450.SEJELPA | TOTAL EXTENTS ORIG: 205CURR: 206 I then activated a new LNKLST set called OCT09A. Re-ran the check and got exactly the same return code and report with the following two additional lines at the bottom: CSVH0974I LNKLST set OCT09A is using 206 extents, which has not changed since it was activated. I then issued SETPROG LNKLST,UPDATE,JOB=* on all systems and re-ran the check again. Same report; same RC=12! But, when I issue D PROG,LNKLST,USERS,NAME=IPLTIME, I get: CSV481I THERE ARE NO USERS OF LNKLST SET IPLTIME Shouldn't the health check understand this condition? -- 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: SLIP sliding away
exotic code Oooh I like that ! From now on, I am going to be an Exotic Programmer when asked. I agree with Ed and CC here, in my stuff I test for XDC being there (and also an internal global/component level option) and then I use XDC as my first-up recovery routine. It is not really intended for use at a customer site - but is there just in case things get that tricky. I *have* used it on some of the more non-standard test systems we have at Rocket when debugging strange setups/environments. 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 Edward Jaffe Sent: 09 October 2007 21:30 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SLIP sliding away Craddock, Chris wrote: [snip] If you DO that, then your debugging environment is completely baked into your code, but there is no physical dependence on XDC and no way for fat fingered programmers to blunder into it. A certain family of products that I've had a passing association with :-) are -ALL- like that. Recovery and diagnostic support is always there no matter what. And if XDC is present and you're properly authorized, you can just use it. If it's not present, or it is, but you're not authorized for it, you don't even know its there. No muss, no fuss. No worries. Yup! I deliberately didn't go there because the typical non-ISV user probably won't feel the need to integrate with z/XDC to that extent. However, this level of integration, exactly what Steve Thompson was alluding to in his post, is a *must* if you're going to debug exotic code (e.g., SRB mode -- which can't be HOOKed in the traditional way) and/or you want to be able to use and/or debug your recovery routines during a z/XDC session. I'll bet most savvy ISVs are doing it just like you described! -- 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 -- 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 calling EZASOKET gets RC 2912
What does CC 2912 mean? My Cobol test program returns CC 2912 when I add these EZASOKET calls: SOCKET CONNECT WRITE READ CLOSE FWIW, the EZASOKET calls are working - tcpdump at the other end of the connection shows the outbound inbound blocks. -- 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 calling EZASOKET gets RC 2912
If the CALL actually seems to be working and EZASOKET doesn't document such a CC, then it sounds to me as if this is the old not clearing register 15 problem documented at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/4.2.4.1 where it says, You might need to think about this handling of the RETURN-CODE special register when control is returned to a COBOL program from a non-COBOL program. If the non-COBOL program does not use register 15 to pass back the return code, the RETURN-CODE special register of the COBOL program might be updated with an invalid value. Unless you set this special register to a meaningful value before your Enterprise COBOL program returns to the operating system, a return code that is invalid will be passed to the system. There are a number of documented cases (CICS and DB2 - if I recall correctly, but maybe others) where IBM products have this problem. Try checking the Return-Code special register in your COBOL program IMMEDIATELY after the CALL. If it has a non-zero value and the values aren't documented by the program that you call, then this is probably what is happening. Tom Simons [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... What does CC 2912 mean? My Cobol test program returns CC 2912 when I add these EZASOKET calls: SOCKET CONNECT WRITE READ CLOSE FWIW, the EZASOKET calls are working - tcpdump at the other end of the connection shows the outbound inbound blocks. -- 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 calling EZASOKET gets RC 2912
NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. I believe the EZASOKET routines do not properly clear R15 on return, so when you program ends the COBOL program propagates the value back. Just set RETURN CODE to 0 in your COBOL program. Larry Gray Large Systems Engineering Lowe's Companies 336-658-7944 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Simons Sent: Tuesday, October 09, 2007 6:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Cobol calling EZASOKET gets RC 2912 What does CC 2912 mean? My Cobol test program returns CC 2912 when I add these EZASOKET calls: SOCKET CONNECT WRITE READ CLOSE FWIW, the EZASOKET calls are working - tcpdump at the other end of the connection shows the outbound inbound blocks. -- 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: SLIP sliding away
Looks like Rob has his Halloween costume all planned. ;-) BTW I nominate this thread for the coolest title of 2007. . . 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] Rob Scott [EMAIL PROTECTED] TWARE.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: SLIP sliding away 10/09/2007 03:16 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU exotic code Oooh I like that ! From now on, I am going to be an Exotic Programmer when asked. -- 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 calling EZASOKET gets RC 2912
Tom Simons [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... What does CC 2912 mean? My Cobol test program returns CC 2912 when I add these EZASOKET calls: SOCKET CONNECT WRITE READ CLOSE FWIW, the EZASOKET calls are working - tcpdump at the other end of the connection shows the outbound inbound blocks. Hmmm.. check the messages and code for COBOL ... oh wait their isn't one... call IBM. Ed -- 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
How many CF engines are necessary?
Hi, (Previously posted to MXG-L) We are having some spirited discussion on the need to provision multiple engines production data sharing Coupling Facilities. I was recently given this reference regarding DB2 v8 CF performance and capacity from DB2 for z/OS: Data Sharing in a Nutshell SG24-7322-00. Reviewing the metrics is straightforward. I am very curious to know how 1. How many of you are using the 25% single/50% multiple utilization as a threshold to upgrade? A different threshold? 2. Who is using multiple engines coupling facilities as a standard to support production data sharing? 7.4 How many CF engines are necessary? DB2 V8 introduced new CF instructions that handle multiple CF requests at one time. They are Read For Castout Multiple (RFCOM) and Write and Register Multiple (WARM). The intent of these instructions is to take a number of individual instructions and lump them into one instruction that provides a list of actions to be performed. WARM allows multiple pages to be written to the CF and registered with a single write request. The intent is to take a CF request that would take 30 μsec. synchronous service time (about 10 μsec. on the CF CPU) and combine may be 10 of them into one instruction that executes in 100 μsec. on the CF CPU. CF utilization remains the same but host and link activity is reduced, especially in DB2 batch insert/update applications. The new instructions contribute to significant increases in asynchronous requests, as synchronous requests are converted to asynchronous most of the time due to the increased time to process Multiple requests. Single CF engine effect: Assume there are two CF requests that arrive about the same time. The first request will consume 100 μsec. on the CF itself (and is likely asynchronous). The second request will consume 10 μsec. on the CF and is synchronous. The synchronous request must wait on the only CF processor (not a subchannel) until the first request completes. If there had been a second CF engine, it could have processed the synchronous request immediately. The result of this activity on a CF with a single engine is to have variable response times that are reflected in the RMF CF Activity Report in the STD_DEV column under SERV TIME (MICS) and DELAY /ALL. The longer running commands have the side-effect of monopolizing the single CF CPU while they are running, so that any other single-entry CF requests (Register Page, for example) that come through will have to wait behind them. This will tend to elongate the SERV TIME (MICS) sync service time of the single-entry requests and increase their standard deviation as well. If it happens to a very significant extent, it could increase the average service time for even single-entry commands to the point where they also start to get converted to async. When your peak CF CPU utilization on a single engine CF approaches 25%, we recommend you add a second engine. For this reason alone, we recommend that you follow these suggestions: - Do not share CF engines in a production parallel sysplex. - Consider providing two dedicated engines minimum per CF for a production parallel sysplex for consistent service times. For less-than-optimal configurations, our guidelines are as follows: - Do not share CF engines in a production parallel sysplex (test and development environments have less stringent requirements) - If you currently have a single CF engine (per CF), add a second when peak CF CPU utilization exceeds 25% (single engine effect). Look at the RMF CF activity report, under the coupling facility usage summary and find the number beside Average CF utilization (% busy) - If you have a multi-engine CF, add another engine when peak CF CPU utilization exceeds 50%. Note: The numbers used in this section are for illustrative purpose only. These guidelines also apply if you implement system-managed duplexing: - If you currently have a single CF engine per CF, add a second engine when peak CF CPU utilization exceeds 25%. - If you have a multi engine CF, add another engine when peak CF CPU utilization exceeds 50%. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.