Re: How to free up space from deleted datasets wtihout IXFP
Yes, I too though Tom was being a bit harsh. I have a customer that has just replaced all their disk with the latest kit. But no PAV ...:( Ours is not to reason why. Shane ... - Original Message - From: Craddock, Chris Tom Conley said; HTF do you buy an RVA without IXFP? snip You would have been better off spending your money on a Shark or an EMC. It probably wasn't his money. We've all been in that equisitely painful place where the available funds are somewhere south of the salesman's best price and management decides to buy less than half a solution... but what would we 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: JES2 from R4 to Z2 mode for z/OS 1.6
Hi all and thank you for your replies. Reading my post I realized I did a mistake, we have to activate new Checkpoint mode from R4 to z2 for new z/OS 1.7 (and NOT for z/OS 1.6) we'll install next year. Sam, I said I need a COLD restart because it's stated in IBM papers. Thanks Max Scarpa DB2 sysprog -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: HCD Token needed for Esoteric devices - Closed
Hello Mike, Before HCD and IODFs the esoteric token was generated in the IOGEN implicitly. So the first esoteric was 1 sequentially. So if you changed the order of esoteric entries, the tokens changed and so maybe caused catalogued dataset access problems. When I turned on the tokens in my esoterics some years back, I scanned my catalogs for any entries using tokens. I used these to populate my esoteric list. And now I just pick an unused number whenever I add an esoteric. I am also consistent in the token value across EDT lists and across sites. Having coded esoteric tokens also makes it simpler when you delete an entry. But since the message is just a warning you can also ignore it. Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: CA-DISK question
Lieven, I takes 4 - 5 hours to merge partially filled 3490's to 1 9840. The 9840 has a nominal (uncompressed) capacity of 20GB, I don't know the capacity of the 3590's. Merging from 3480 will require more (4x?) tapemounts, unless they are full, so processing time might be even more. You must define the 3590 units as DYNx units,to distinguishe them from the 3480, see the manual about handling different tapes and tapedevices. Check the MULTVOL parameter on the Merge statement to also process multivolume 3480 tapes. Kees. Lieven Borgs [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Neal, The reason that I would like to go for the 'MERGE' tool is that you can provide a list of input tapes. XCOPY requires, to my knowledge, a dataset list as input for the copy process. This means that I have to setup a process that collect the datasetnames that are stacked with CA-DISK on 1 tape. Do you have any experience about the time needed to merge 3480's in order to fill up one 3590 ? Any other usefull experiences, watchouts? Thx, Lieven -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
problem IKJEFTSR
I got a problem : IKJEFTSR interface error Authorized program 'VRASPFLK'. Return code = 20. Reason code = 56. I have listed the library to APF and listed also in IKJTSOxx. Someone have any sugestion ...? Thanks for the attention. __ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.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 VSAM Statistics are often Bogus
Dave, Your reply is wrong on so many levels that I don't know where to start. It is obvious to me that the topic of this thread *is not clear to you.* In the case of an ABEND or CICS close immediate situation, what information would you like Mark to write to the file? And where is this information supposed to come from? Remember, we are only talking about VSAM statistics for datasets that were not closed *normally*. For normal closures, the statistics are just fine. To use your words, the lousy disclaimer has been known to me since I first learned about VSAM. Ron Ferguson has traveled around the world for a few decades now telling all who will listen these two major points: 1) Statistics garnered from listcats of open VSAM datasets are invalid 2) Statistics garnered from listcats of VSAM datasets that were not closed properly are also invalid Your final comments about SMF and RMF are pure nonsense. Once again, to quote Ted, invalid data is invalid data! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Juraschek Sent: Wednesday, July 06, 2005 4:32 AM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: IBM VSAM Statistics are often Bogus I guess what really peeves me is not that the stats are invalid - although that is certainly disturbing to say the least. That is clear (to me now). What really is unconscionable is Mark's admission that IBM has known this for 30+ years and has not cared or bothered to fix it yet. Mark's response (whether he likes to admit is or not) and IBM's response seems to be shame on you for using our bogus [for John] numbers, and never shame on us for knowing about this for so long and just not giving a rip. A lousy disclaimer in one paragraph of one manual is hardly notification to end- users who might need this kind of information that what IBM is providing them is ... um, again ... bogus. Not having fixed this in 30+ years (according to Mark) is both arrogant and sloppy on IBM's part. I wonder where the disclaimer paragraph is that I missed about SMF stats, RMF stats, and ever other statistic IBM provides disclaiming it's validity too. -Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 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. Seeing Beyond Money is a service mark 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: CA-DISK question
Lieven, When I converted the 3480s to 3490Es using the CA-DISK MERGE utility, I would do 50 input tapes at a time. These tapes then went to one of five output tapes. The output tapes were grouped by how long the backup dataset was retained. Doing the conversion this way would took about 6-8 hours per 50 tapes. At the same time, a duplicate set of tapes were created which went off-site. This setup was according to how the shop does business. One could just as easily bring the input tapes in one by one and use a single output tape and performed the MERGE that way. The utility is fairly flexible. You can also simulate the runs if you want to get a better feel for how many output tapes it takes before you merge the 3480's. Regards, Neal Kostanski Transaction Oriented Platforms - Large Server Support Abbott Laboratories Ph: 614-624-3613FAX: 614-727-3613 Yahoo IM: criterion_0 -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
In a message dated 7/6/2005 5:22:42 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: In the case of an ABEND or CICS close immediate situation, what information would you like Mark to write to the file? And where is this information supposed to come from? I think you are assuming there is only one way to fix this problem. E.g., in the case of SMF data the solution is called interval accounting. Every X minutes SMF records are written to reflect the activity during the last X minutes. The VSAM statistics in question could be updated on intervals. You will miss all the activity that occurs during the last partial interval just before a system crash. Application programs or even access methods (e.g., at OPEN time) could be enhanced to add ABEND recovery routines that invoke a new service which would add the last partial interval's stats into the proper buckets. This assumes the stats are kept in storage that was not trashed as part of the error leading to the ABEND. If the operator FORCEs the job or the system crashes, there is no hope. But for most abnormal ends there are ways to fix the stats. The information comes from the same place where it comes from now in the case of normal CLOSE. The minimum we would need is a new service which the user would invoke to update stats. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
tso ALLOCATE command and space allocation
A dataset is pre-allocated using the TSO allocate command using a Cylinders with primary allocation of cylinders and 333 secondary space with a list of volumes. When writing into the dataset in a separate step, I would expect that on the second volume, A primary allocation space will be taken. Our experience shows that from the second volume in the volume-list, the space will be allocated in the secondary space units. Why is that so? a reference to the manual will be helpful. 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
Re: tso ALLOCATE command and space allocation
DFSMS: Using Data Sets has the details. Using SMS, you can allocate data sets with the guaranteed space attribute, which sounds like what you want to do. Regards, John Kalinich Computer Sciences Corp Itschak Mugzach imugzachTo: IBM-MAIN@BAMA.UA.EDU @ISRACARD.CO.IL cc: Sent by: IBM Subject: Re: tso ALLOCATE command and space allocation Mainframe Discussion List IBM-MAIN 07/06/2005 08:39 AM Please respond to IBM Mainframe Discussion List Hello John, Is this documented? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Does z/OS 24 bit,31 bit or 64 bit addressing mode affect 1 byte is 8 bits?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bo Xie Sent: Tuesday, July 05, 2005 10:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Does z/OS 24 bit,31 bit or 64 bit addressing mode affect 1 byte is 8 bits? Hi, UNIX98 standard ed utility http://www.opengroup.org/onlinepubs/7990989799/xcu/ed.html; shows: - If the size of a byte on the system is greater than nine bits, the format used for non-printable characters is implementation-dependent. - I want to know whether 1 byte is still 8 bits in zOS 64 bit mode? or int is still 32 bits in zOS 64 bit mode? Thank you! BTW. What system is 1 byte is greater than 9 bits? for example? Best Regards, Xie Bo historical mode=on, pedantic=off Anymore, a byte is always 8 bits in length. I am not aware of any main stream processor for which this is not true at present. Also, in today's environment, an int is usually 32 bits (4 bytes). However, there were some systems in the past in which an int was 36 bits. As you can see if you do the math, that 36 is not evenly divisible by 8 (36/8==4.5). On these systems, a byte was usually 9 bits in length. In this context, a byte is not 8 bits, but rather the fundamental unit of memory addressing (or some such thing). If you do any C programming (or UNIX work), you will likely notice that octal is used quite a bit instead of hexadecimal. The reason, IIRC, is that the PDP systems upon which C and UNIX were originally developed were 36 bit machines. A 9 bit byte could be displayed as 3 octal digits. But could not be displayed at all using hex. note - if this is incorrect, please forgive me, it's been too long /historical If you deal with telecommunications, you will notice that they always talk about an octet. An octet has a definate defination of 8 bits. That's why they use it instead of byte. No confusion. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RVA: How to free up space from deleted datasets wtihout IXFP
Copy the data sets elsewhere and INITialize the volume using DSF. NO! That will make the problem no better and probably worse. If you do a minimal INIT (just VTOC), then the tracks for all the datasets that used to be on the volume will STILL be assigned in the back-store. If you do a medial INIT (write every track), then EVERY track ont he volume will be assigned space on the back-store. What he could do is move all the datasets off a volume, then DELETE the volume from the RVA control panel (which releases the backstore), then redefine the volume and move datasets back. This could be very tedious. I agree, IXFP is necessary to the management of an RVA, there is no other way to release unused space. Alternately, you can license the SVAA product from StorageTek, more recent version of IXFP. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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: How to free up space from deleted datasets wtihout IXFP
In a message dated 7/5/2005 11:52:51 P.M. Central Standard Time, [EMAIL PROTECTED] writes: funds are somewhere south of the salesman's best price and management decides to buy less than half a solution... but what would we know? Missing something in the loop? Keep it running, keep response time acceptable, keep availability highest with what we've got. If there aren't feedback mechanisms in place to address this, probably need to look elsewhere for employment, just wasting everybody's time trying to write CYA memos for selections made by the word processing department. IIRC the CE has tools to force DDSR in lieu of IXFP and the RVA does it it's ownself although glacially. The CE might hit the wrong button and reinit the whole string. Backups are good! -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RVA: How to free up space from deleted datasets wtihout IXFP
What he could do is move all the datasets off a volume, then DELETE the volume from the RVA control panel (which releases the backstore), then redefine the volume and move datasets back. This could be very tedious. Just reread what I typed. Assuming that he moved the datasets to another volume in the RVA, he would NOT want to move them back to the redefined volume. Otherwise the tracks from the temporary volume would remain assinged in the backstore. So the process should be: consolidate datasets on a smaller number of disk volumes in the RVA, then vary the empty volumes offline, and DELETE and redefine them from the control panel. Still tedious. Also, if the RVA has the SNAPSHOT feature (and most do), you are missing out on its advantages if you don[t have IXFP/SNAPSHOT. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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: HSM statistics
On Wed, 6 Jul 2005 08:51:36 +0800, Ron and Jenny Hawkins [EMAIL PROTECTED] CABLE.COM wrote: Seeing as the dataset is opened, wouldn't there be a type 42-6 record for it that is not just using the relative concat id? Good thought, but no go. I just ran a test and not even the STEPLIB that my program came from was in the SMF42 records. The only data set I saw was the CA-JOBTRAC checkpoint data set (which all jobs allocate). I have never looked closely at SMF42 records before, but here is what the fine manual says about subtype 6: Subtype 6 -- records DASD data set level I/O statistics. There are two events that cause subtype 6 to be generated: - Close, or - Immediately after the recording of the type 30 interval record. There is one type 42 subtype 6 record for each type 30 interval record. Looks like ThruPut manager may still my best solution. Cheers, Mark -- Mark Zelden Sr. Software and Systems Architect mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rename VSAM Cluster and its components
When I have a lot of VSAM files to rename, I use DFDSS to do the rename with filtering, here is an example //S02 EXEC PGM=ADRDSSU,REGION=6000K,TIME=95 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=A //SYSIN DD * COPY - DATASET(INCLUDE(DOTWONG.COPP.VSAM.IPOIDHD)) - RENAMEUNCONDITIONAL(DOTWONG.COPP.VSAM.IPOIDHD, - DOTWONG.NEWNAME.VSAM.TEST) - DELETE CATALOG PURGE /* -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Questions from someone coming from a plain vanilla environment
John S. Giltner, Jr. wrote: Webshpere is IBM term for their family of middleware. If you mean Websphere Application Server, it is IBM's J2EE application server. Out of the box you can't use Websphere as a DNS server or a DHCP server, but you can use it as a Web server. Technically I think you could write your own DNS server code and or DHCP server code in Java and run it under Websphere. Think of Websphere application Server as a CICS (or IMS or IDMS-DC) for Java. You could write DNS server code or DHCP server code and run it under CICS if you wanted to. I have not heard of iServices, can you point me to a link. Can someone tell me why I never saw the post below? I get the feeling I have some setting such that I'm missing some of the posts on ibm-main. Kind regards, -Steve Comstock John F. Regus wrote: We don't take full advantage of all the bells and whistles around here that are in zOS. So I have some questions. 1) Can someone give me a one or two sentence explanation of IBM Websphere? Can you define web servers, DNS servers, DHCP, etc. using Websphere and what is the iServices...I get the impression that defining web servers, DNS servers, etc. is done with iServices and not Websphere. Thanks for the time to explain full use of the box. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: 25% Pageds utilization on 3390-09?
The following ROT are still reasonable- - Individual local page datasets should not exceed 30% (or 25% if you choose) utilization because the contigious slot allocation algorithm becomes inefficient/unsuccessful for that dataset. The utilization% at a total paging subsystem level is irrelevent with respect to the algorithms. - All local page datasets should be the same size (or close to it in slots) and device type because of ASMs round robin allocation algorithm. If one page dataset has 12000 slots and another has 24000 the utilization% on the second will be about 1/2 of the first. - Paging bandwidth is as important as paging space. Converting 9 page datasets to 3 page datasets of triple size will probably impact performance. More smaller page datasets is always better over fewer large page datasets. - A volume should only have a single local page dataset on it, and no other datasets. Use of WLM managed PAVs by ASM can be used to eliminate this restriction. Depending on the actual storage subsystem backing a page dataset it may or may not be reasonable to have multiple systems using a volume with a page dataset on it. Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM VSAM Statistics are often Bogus
I never even envisioned automated tools looking at VSAM stats. My ASSumption when reading Mark's posts was that he was referring to individual programmers looking at individual VSAM file stats for guidance. My experience is obviously severely limited in this regard, as in my varied positions over the years the usual case was that all of the applications' datasets (including VSAM) were our (the application programmers') responsibility to feed and care for, and we never had thousands to contend with. As for my ASSumption on criticality, the normal performance variations (once a good initial design and shakeout was done) for an individual (set of) application file(s) were never that critical unless severe volume increases occurred. A parochial point of view, I must freely admit. I stand humbly corrected. My vision is obviously way too narrow. Peter -Original Message- From: Richards.Bob [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 6:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM VSAM Statistics are often Bogus Snipped Your paragraph: Just because they are not written when something BAD happens is NOT a reason to see them as invalid or useless. Like anything else in this business (or life, for that matter), you need to know what you are talking about when you use statistics to justify a decision. If these statistics were being inspected one-by-one, I might concede that last half of the second sentence. In my experience though, decisions of this sort are being made in an automated fashion without consideration for knowing what you are talking about. They are being made under *the assumption that the statistics are accurate*, a point that has clearly been demonstrated as wrong! Urgent or critical? Without empirical evidence to the contrary, how can *you assume* that it is neither/nor? I raise your two cents and make it my $.04 cents. grin Bob _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM VSAM Statistics are often Bogus
See my earlier reply to Mr. Richards for the ASSumptions behind that statement. Peter -Original Message- From: Ted MacNEIL [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 6:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM VSAM Statistics are often Bogus ... Just because they are not written when something BAD happens is NOT a reason to see them as invalid or useless. ... I don't get it! Invalid data is invalid data! We make enough bad decisions with valid data. How can you say that with a straight face? _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Can anyone tell me about Trident Systems product..
snip Is anyone out there using or did use OS/EM from Trident Data Systems? Did it save your company money? Easy to use? etc.. /snip Great product, but IMHO, not worht the expense. IBM provides native code to perform 95% plus of the OS/EM functionality, at no extra expense. At one time, this was not the case, but many 3rd party products have been overtaken by MVS enhancements over the years. 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: problem IKJEFTSR
Where is the library containing VRASPFLK located? LPA? Linklist? STEPLIB? ISPLLIB? LIBDEFed? TSOLIBed? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Albertus Dwisulami Sent: Wednesday, July 06, 2005 6:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: problem IKJEFTSR I got a problem : IKJEFTSR interface error Authorized program 'VRASPFLK'. Return code = 20. Reason code = 56. I have listed the library to APF and listed also in IKJTSOxx. Someone have any sugestion ...? Thanks for the attention. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM VSAM Statistics are often Bogus
Dave Juraschek [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... ... CICS close immediate situation This really is a red herring. The CICS CEMT PERFORM SHUT IMMEDIATE is completely IBM code. This is an example of where this is absolutely not a user/application/customer problem. If it is violating some IBM VSAM file rule, it's still an IBM problem and one would think that the IBM VSAM folks would have asked the IBM CICS folks to play by their restrictive rules years and years and years ago - especially, if this is a primary cause of the statistics corruption as Mark claims. CICS distributes a program that can be tailored by the installation to determine whether an application is waiting for an I/O to complete, or just sitting idle. CICS does not attempt to terminate a transaction that is performing I/O and uses a wait timer (I believe also specified by the installation) on how long to wait before deciding to terminate the transaction on an immediate shutdown. The solution is there for the customer - they just have to make use of it. Almost nobody has. It's called options... Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: How to free up space from deleted datasets wtihout IXFP
From: caleb ong [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Tuesday, July 05, 2005 9:35 PM Subject: RVA: How to free up space from deleted datasets wtihout IXFP We have a RVA with NCL nearing 85%. We don't have IXFP. We are trying to free up space to bring down the NCL. Without IXFP, is there no other way to reclaim spaces from deleted datasets ? Caleb, you should post to the list rather than the newsgroup. I wouldn't have seen this if Tom Conley hadn't reproduced it. One way to free up space on your RVA without IXFP is to fill up your volumes with large datasets containing binary zeros, then delete those datasets. The backend will still remember those tracks as they do without IXFP today, but they'll be compressed into near-nothingness. (Slightly OT: Linux-390 doesn't support IXFP, so it has the same problem with RVA as you. A couple of years ago Scott Ledbetter posted a neat little script that you can run on Linux-390 to temporarily fill your RVA filesystem with nulls. See: http://www.mail-archive.com/linux-390@vm.marist.edu/msg10508.html ) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Questions from someone coming from a plain vanilla environmen t
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock [ snip ] Can someone tell me why I never saw the post below? I get the feeling I have some setting such that I'm missing some of the posts on ibm-main. If you get your IBM-MAIN via email, you won't see anything posted directly to the newsgroup bit.listserv.ibm-main. -jc- Kind regards, -Steve Comstock John F. Regus wrote: We don't take full advantage of all the bells and whistles around here that are in zOS. So I have some questions. [ snip ] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to free up space from deleted datasets wtihout IXFP
Arghhh, following up on my own post. Bad form as usual. On Wed, 2005-07-06 at 11:16 -0400, David Andrews wrote: From: caleb ong [EMAIL PROTECTED] Subject: RVA: How to free up space from deleted datasets wtihout IXFP Caleb, you should post to the list rather than the newsgroup. Whoops. I see you *did* post to the list, but someone changed your Subject: line, and I saw the followups before I saw your original post. My bad. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM VSAM Statistics are often Bogus
On Wed, 6 Jul 2005 06:57:38 EDT, Bill Fairchild wrote: In a message dated 7/6/2005 5:22:42 A.M. Central Daylight Time, Bob Richards writes: In the case of an ABEND or CICS close immediate situation, what information would you like Mark to write to the file? And where is this information supposed to come from? I think you are assuming there is only one way to fix this problem. E.g., in the case of SMF data the solution is called interval accounting. Every X minutes SMF records are written to reflect the activity during the last X minutes. The VSAM statistics in question could be updated on intervals. You will miss all the activity that occurs during the last partial interval just before a system crash. Application programs or even access methods (e.g., at OPEN time) could be enhanced to add ABEND recovery routines that invoke a new service which would add the last partial interval's stats into the proper buckets. This assumes the stats are kept in storage that was not trashed as part of the error leading to the ABEND. If the operator FORCEs the job or the system crashes, there is no hope. But for most abnormal ends there are ways to fix the stats. The information comes from the same place where it comes from now in the case of normal CLOSE. The minimum we would need is a new service which the user would invoke to update stats. Bill Fairchild There is a more fundamental issue here: VSAM keeps its statistics records in KEY 8 storage in the address space's private area, since it normally runs as an extension to the application program code. Those statistics records can, and often are in the case of a storage overlay, subject to corruption and/or destruction because of that inherent lack of protection. VSAM (and other access methods perhaps) needs to have a protected area for such apparently customer-important data as statistics. Anything less is a band-aid. VSAM could move the statistics to a data space, either owned by the application address space or perhaps owned by the system (somewhere). But it would probably still end up being a KEY 8 data space since it is still an extension of the application program code... so it would be 'security by obscurity' and not iron-clad. That should still offer a marked improvement over the private area. But it would also introduce performance concerns in the middle of an obvious performance path. Sticky detail. The problem with using interval accounting to try to anticipate the ABENDs is that storage overlays do not always (or even often) inflict the fatal damage on the first strike. The statistics records could, possibly, be the first storage to be overlaid (or worse, partially overlaid) and the result would be difficult to see... certainly difficult for poorly written LISTCAT automation to see. Again, this introduces a (smaller? maybe not) performance concern by pushing out excess SMF records in the middle of the I/O (performance) path. A problem with having the access method inflict its own recovery during ABENDs would be the new conflict(s) that would result, for example which percolates to which and how could the access method get control first ... should the access method REALLY get control first? LE would probably vote 'no' and other products (or applications) might vote similarly... then what? Even if VSAM's shiny new recovery intercept got control at the ABEND who is to say that its statistics data wasn't already overlaid? Too late. As for why it took IBM so long to address the issue... I personally don't blame IBM for taking so long, since the statistics were always (as far as I know) documented to be an indicator and there was (as is obvious by this thread) a huge misunderstanding in the customer (and vendor) community over the scope and impact of the problem, if any. There was documentation warning against use of LISTCAT as a programming interface that goes back to (at least) 1981 ... caveat emptor. I commend Mark for taking the issue in hand and trying to implement a long term solution, and for raising it to the level where it is discussed so that the appropriate awareness is reached, but Mark doesn't need my commendation for job satisfaction. Say what you want about IBM but its people are still among the best architects of software around. This issue is convoluted at best. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: How to free up space from deleted datasets wtihout IXFP
You could try to bring the partition down (deactivate it). We used to run linux/390 on a partition, and it doesn't have any IXFP, so our STK CE told us to bring the partition down once a week for the SVA to free up deleted stuff. SteveBui -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of caleb ong Sent: Tuesday, July 05, 2005 6:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: RVA: How to free up space from deleted datasets wtihout IXFP Hello, We have a RVA with NCL nearing 85%. We don't have IXFP. We are trying to free up space to bring down the NCL. The deleted dataset space from os/390 is not freed up in rva. From the docs and the archives post, we know that we need to run dynamic ddsr and interval ddsr. But this is part of ixfp and we currently don't have this sw. Without IXFP, is there no other way to reclaim spaces from deleted datasets ? The redbook seems to indicate that IXFP was an option, if this is the case, then there should be some other way to reclaim spaces outside of ixfp. Outside of ixfp, is there any manual procedure that you could do to reclaim the space from deleted datasets ? it doesn't have to be online, any procedure , even those that require downtime on the rva. thanks in advance. Caleb _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
In a message dated 7/6/2005 10:26:57 A.M. Central Standard Time, [EMAIL PROTECTED] writes: invalid data? If your checking statement said you had $3,127.47 but next to it in parentheses it said (but this amount is invalid), would you go out and try to spend the money? No, I think you'd be kinda cautious so you didn't get arrested for fraud. I wonder how businesses can make decisions on the same invalid data. We had a competitor who had a customer withdraw his mistakenly debited $3M. His claim was that he had prayed for riches and his prayers were answered. The glee was that the competitor had to explain under oath that it was human error totally and that their recon system needed a little work. No jail time for the fervent, but the competitor got scheduled visits from the Fed. Guess another consideration is that the stats have been bogus for so long many, many application delete and redefine nightly adding cycles to an already tight window. No way for 24/7. Runs customers off in droves. Can you say tanked revenue? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: How to free up space from deleted datasets wtihout IXFP
I think you really need to get SVAA ASAP. http://www.stortek.com/products/category_page2011.html Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 If you think nobody cares if you're alive, try missing a couple of car payments. 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Does z/OS 24 bit,31 bit or 64 bit addressing mode affect 1
The Honeywell Series 6000 boxes - taken from GE design, IIRC - had 36-bit addressable words, that could be interpreted as 6 6-bit BCD characters or 4 9-bit ASCII characters. Decades ago, I wrote some GMAP (was that the assembler, or am I thinking of Prime Computer's PRIMOS assembler?) routines (under GCOS - [EMAIL PROTECTED] low bid community college contract, so no Multics) to display things like job name, SNUMB, remote destination node name, etc. and routines dealing with text characters had to be careful with character mode. My routine could be called from BCD programs (FORTRAN) and ASCII programs (COBOL), so I had to determine mode and use the right instructions to move the data from system blocks to the user-provided parameter area. It did have this interesting compiler on it, though - B. I wonder if Groupe Bull's machines still do this. Later, Ray -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RVA: How to free up space from deleted datasets wtihout IXFP
Bruce Black wrote: Copy the data sets elsewhere and INITialize the volume using DSF. NO! That will make the problem no better and probably worse. If you do a minimal INIT (just VTOC), then the tracks for all the datasets that used to be on the volume will STILL be assigned in the back-store. If you do a medial INIT (write every track), then EVERY track ont he volume will be assigned space on the back-store. Interesting. We no longer have an RVA, so I can't try anything. But I seem to remember the NCL going down when we reinitialized a volume. OTOH, we did run IXFP. That probably explains why we observed that phenomenon. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | 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: RVA: How to free up space from deleted datasets wtihout IXFP
We've still got one and it is definitely the IXFP software that frees up the backend storage when doing a pack init. Rex -Original Message- From: Edward E. Jaffe [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 11:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: RVA: How to free up space from deleted datasets wtihout IXFP Bruce Black wrote: Copy the data sets elsewhere and INITialize the volume using DSF. NO! That will make the problem no better and probably worse. If you do a minimal INIT (just VTOC), then the tracks for all the datasets that used to be on the volume will STILL be assigned in the back-store. If you do a medial INIT (write every track), then EVERY track ont he volume will be assigned space on the back-store. Interesting. We no longer have an RVA, so I can't try anything. But I seem to remember the NCL going down when we reinitialized a volume. OTOH, we did run IXFP. That probably explains why we observed that phenomenon. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | 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 E-MAIL CONFIDENTIALITY USE NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. In addition, you are strictly prohibited from using, disseminating, distributing, copying, or storing this message and any attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
destructive overlap
I am trying to figure out precisely what is destructive overlap. Does destructive overlap imply nonconcurrent copy (and vice versa)? For example: ds 0d a ds 12x b ds 16x mvc a(16),b Here is an overlap but it is non-destructive. I would assume the copy is concurrent? But if I code mvc b(16),a the overlap is destructive (ie b won't necessarily be an exact copy of a). Would a concurrent copy occur? (in this case, a concurrent copy could occur without affecting the result). Thanks, Greg Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RVA: How to free up space from deleted datasets wtihout IXFP
Bruce, Duh, must have been seriously sleep deprived when I agreed with this madness. You are correct, of course. I was probably still in shock that anyone would have an RVA without IXFP. That's like running a car on rims. Nice catch. Tom - Original Message - From: Bruce Black [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 06, 2005 9:34 AM Subject: Re: RVA: How to free up space from deleted datasets wtihout IXFP Copy the data sets elsewhere and INITialize the volume using DSF. NO! That will make the problem no better and probably worse. If you do a minimal INIT (just VTOC), then the tracks for all the datasets that used to be on the volume will STILL be assigned in the back-store. If you do a medial INIT (write every track), then EVERY track ont he volume will be assigned space on the back-store. What he could do is move all the datasets off a volume, then DELETE the volume from the RVA control panel (which releases the backstore), then redefine the volume and move datasets back. This could be very tedious. I agree, IXFP is necessary to the management of an RVA, there is no other way to release unused space. Alternately, you can license the SVAA product from StorageTek, more recent version of IXFP. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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
Has VSAM become synonymous with KSDS?
On 6-Jul-2005, [EMAIL PROTECTED] (Mark Thomen) wrote: VSAM is a particularly complex access method, much more so than the others. Is VSAM these days pretty much synonymous with KSDS? At one time, I worked in a shop where I converted all of our Univac 9030 data to IBM, and made everything VSAM, even though most files were relative or flat. But over time, I have been finding VSAM being used very little for non KSDS, and have seen people referring to VSAM as IBM's ISAM. Of course, in some shops, VSAM is obsolete altogether (except for databases that use VSAM that programmers don't see). -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: How to free up space from deleted datasets wtihout IXFP
- Original Message - From: David Andrews [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 06, 2005 11:17 AM Subject: Re: How to free up space from deleted datasets wtihout IXFP One way to free up space on your RVA without IXFP is to fill up your volumes with large datasets containing binary zeros, then delete those datasets. The backend will still remember those tracks as they do without IXFP today, but they'll be compressed into near-nothingness. David, Whoa mama! Cool man! (a la Bart Simpson). Great solution to a really snipped problem. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
You want good stats to base things such as REORGs on? Go to DB2. And pay for it. Only in FOSS will you get something for free (either Libre or Gratis). And, in FOSS, if you don't like it, you can fix it yourself. If you don't have the talent to fix it yourself, then either: (1) nicely ask the maintainer to fix it; (2) pay somebody to fix it; (3) learn how to fix it yourself; (4) learn to live with it. With z/OS, you don't have option (3). And options (1) and (2) are similar in that IBM must do any fixing. Option (4) is always available. I tried to refrain from mentioning that option (4) is the Windows way.grin -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 IKJEFTSR
- Original Message - From: [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 06, 2005 6:00 AM Subject: problem IKJEFTSR I got a problem : IKJEFTSR interface error Authorized program 'VRASPFLK'. Return code = 20. Reason code = 56. I have listed the library to APF and listed also in IKJTSOxx. Someone have any sugestion ...? Put Vanguard in LINKLIST, don't STEPLIB to it in your TSO logon proc. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
In a message dated 7/6/2005 11:35:21 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Of course, in some shops, VSAM is obsolete altogether (except for databases that use VSAM that programmers don't see). VSAM's being obsolete is like saying TSO is obsolete. VSAM has been the strategic access method of IBM since the mid-1970s. It underlies many other structures that programmers also don't see, such as page data sets and catalogs, without which z/OS will not run very well or long. A better term might be non-obvious. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
Well, not everywhere. RRDS/ESDS in my experience are still actively used, especially where database complexity would be a performance drawback instead of an advantage. Not *every* business transaction requires a database. KISS is still a good design principle. Peter -Original Message- From: Howard Brazee [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 12:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Has VSAM become synonymous with KSDS? On 6-Jul-2005, [EMAIL PROTECTED] (Mark Thomen) wrote: VSAM is a particularly complex access method, much more so than the others. Is VSAM these days pretty much synonymous with KSDS? At one time, I worked in a shop where I converted all of our Univac 9030 data to IBM, and made everything VSAM, even though most files were relative or flat. But over time, I have been finding VSAM being used very little for non KSDS, and have seen people referring to VSAM as IBM's ISAM. Of course, in some shops, VSAM is obsolete altogether (except for databases that use VSAM that programmers don't see). _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: destructive overlap
In a recent note, Greg Smith said: Date: Wed, 6 Jul 2005 12:26:01 -0400 ds 0d a ds 12x b ds 16x But if I code mvc b(16),a the overlap is destructive (ie b won't necessarily be an exact copy of a). Would a concurrent copy occur? (in this case, a concurrent copy could occur without affecting the result). No. I believe the destructive character of the overlap has long been part of the specification of MVC. In particular, programmers of old were accustomed to blanking out a buffer with: MVI C' ',A MVC A+1(L'A'-1),A (before padding MVCL). -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
DB2 is also loaded into VSAM datasets. Also, don't forget the linear datasets used by the OS. Bill Fairchild wrote: In a message dated 7/6/2005 11:35:21 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Of course, in some shops, VSAM is obsolete altogether (except for databases that use VSAM that programmers don't see). VSAM's being obsolete is like saying TSO is obsolete. VSAM has been the strategic access method of IBM since the mid-1970s. It underlies many other structures that programmers also don't see, such as page data sets and catalogs, without which z/OS will not run very well or long. A better term might be non-obvious. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: destructive overlap
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] No. I believe the destructive character of the overlap has long been part of the specification of MVC. In particular, programmers of old were accustomed to blanking out a buffer with: MVI C' ',A Hmmm Is it really true that Lysdexics have more nuf? :-) MVC A+1(L'A'-1),A (before padding MVCL). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM VSAM Statistics are often Bogus
- Original Message - From: Mark Thomen [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 06, 2005 11:26 AM Subject: Re: IBM VSAM Statistics are often Bogus Had I worked in VSAM for 30+ years I'd have made this change a long time ago and this issue would never have been so contentious. But I've only been working directly in VSAM for a couple of years now so I apologize for not publicizing this sooner. And as several users have pointed out, invalid data is invalid data - and how can you make business decisions on invalid data? If your checking statement said you had $3,127.47 but next to it in parentheses it said (but this amount is invalid), would you go out and try to spend the money? No, I think you'd be kinda cautious so you didn't get arrested for fraud. I wonder how businesses can make decisions on the same invalid data. We do have plans to correct the problem, but it's dependent on resources, and time. Mark, The only beef I had with this whole thing is that IBM did not protect the customer investment with the first fix. I know you hate the compromise fix, but it was the right thing to do. Ensuring that customer code runs uninterrupted wherever possible should be one of the highest development priorities. The new fix allows application code to run unchanged (although REXX will probably still fail because the '*' is abutted to the end of the number), while giving the new information that the data is potentially invalid. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: destructive overlap
Don't forget the all time favorite method for clearing a print buffer: MVI PBUF,C' ' MVC PBUF+1(132),PBUF PBUF DS CL133 I have never heard of it being called a destructive overlap before. I have always herad it called a destructive move. Fought a bug in a CICS COBOL program for a week before I realized the program had a destructive move using an MVCL instruction. MVCL, as I now understand, is a noop if the move is destructive. Greg Smith wrote: I am trying to figure out precisely what is destructive overlap. Does destructive overlap imply nonconcurrent copy (and vice versa)? For example: ds 0d a ds 12x b ds 16x mvc a(16),b Here is an overlap but it is non-destructive. I would assume the copy is concurrent? But if I code mvc b(16),a the overlap is destructive (ie b won't necessarily be an exact copy of a). Would a concurrent copy occur? (in this case, a concurrent copy could occur without affecting the result). Thanks, Greg Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Does z/OS 24 bit,31 bit or 64 bit addressing mode affect 1
... Decades ago, I wrote some GMAP ... General Macro Assembly Program(me). I learned on a Level 66, running GCOS-8. It had just had its name changed from GECOS, after Honeywell bought General Electric's computer division -teD In God we Trust! All others bring data! --Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: destructive overlap
In a recent note, Chase, John said: Date: Wed, 6 Jul 2005 11:51:50 -0500 MVI C' ',A Hmmm Is it really true that Lysdexics have more nuf? :-) Have you heard about the man who was insomniac, agnostic and dyslexic? MVC A+1(L'A'-1),A I once astonished Ed Jaffe (or was it Bruce Black) by stating that I don't write assembler code (or was it that I don't read dumps). Every now and again I feel the need to provide proof. And for Steve's doubts about destructive overlap: Ranked Search Results for Book: dz9zr003 z/Architecture Principles of Operation 10 topics have matches for: destructive overlap 1. MOVE LONG, 7.5.90 2. MOVE LONG EXTENDED, 7.5.91 3. MOVE LONG UNICODE, 7.5.92 4. Consistency Specification, 5.13.9.4 5. Interlocks within a Single Instruction, 5.13.4.2 6. MOVE STRING, 7.5.94 7. MOVE WITH DESTINATION KEY, 10.29 8. MOVE WITH SOURCE KEY, 10.31 9. MOVE LONG (MVCL), A.3.26 10. CIPHER MESSAGE WITH CHAINING (KMC), 7.5.25 -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VSAM KSDSs: To Reorg or not to Reorg
Hello listserv members, Mark Thomen really hit my hot button on his last response: Ask Ron Ferguson who preaches don't reorg based on split counts, or check out the VSAM Demystified Redbook. Or do your own studies. Which is better - downtime for a major application, or reorging a file that doesn't need it? As a result of this change to IDCAMS I've had discussions with several customers who were SHOCKED to discover they didn't need to reorg. They quietly said thank you and changed their processes. In more than 600 VSAM courses taught over the past 25+ years, I have preached that most installations are doing far too many reorgs -- all in the name of improving performance or saving DASD -- both are incorrect results in the vast majority of situations. Immediately after the reorg, the file's performance is degraded, not improved until the file settles back down after re-doing the beneficial splits that were removed -- and following that, the DASD savings from the reorg is also wiped out. The problem is, the IDCAMS LISTCAT just doesn't provide sufficient information to really understand what's going on within a KSDS, and the STATISTICS are the only source of information that most people have at their fingertips. Decades-old myths about splits are bad, so let's reorg to get rid of them is the typical solution handed down from old-timer to newcomer, and for that, people believe STATISTICS values are of immense importance. (Consider this, if you see a LISTCAT that shows 10 CA splits, did 10 different CAs split once, did one CA split 10 times -- and how much difference is there between those two extremes? With a LISTCAT, that's all you have -- and no information about where and why those splits occurred). I've presented VSAM tuning sessions at every SHARE for the past 5+ years, and will do so again at SHARE Boston (Session 3060, 3:00PM, Monday, 22 August) -- I use the output from a mapping program that I have to debunk the myths about reorgs (and therefore, incorrect usage of STATISTICS). Drop by my session. Ron Ferguson President and CEO Product Manager -- Catalog RecoveryPlus Mainstar Software Corporation [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
On Wed, 6 Jul 2005 16:34:54 GMT Howard Brazee [EMAIL PROTECTED] wrote: :On 6-Jul-2005, [EMAIL PROTECTED] (Mark Thomen) wrote: : VSAM is a particularly complex access method, much more so than the others. :Is VSAM these days pretty much synonymous with KSDS? :At one time, I worked in a shop where I converted all of our Univac 9030 data to :IBM, and made everything VSAM, even though most files were relative or flat. :But over time, I have been finding VSAM being used very little for non KSDS, and :have seen people referring to VSAM as IBM's ISAM. KSDS provided major enhancements over ISAM. Neither RRDS or ESDS have any particular advantage over BDAM (despite IBM calling it obsolete) or BSAM/QSAM. -- 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: destructive overlap
Thanks for the info. I will keep that in mind for future reference. Paul Gilmartin wrote: I once astonished Ed Jaffe (or was it Bruce Black) by stating that I don't write assembler code (or was it that I don't read dumps). Every now and again I feel the need to provide proof. And for Steve's doubts about destructive overlap: Ranked Search Results for Book: dz9zr003 z/Architecture Principles of Operation 10 topics have matches for: destructive overlap 1. MOVE LONG, 7.5.90 2. MOVE LONG EXTENDED, 7.5.91 3. MOVE LONG UNICODE, 7.5.92 4. Consistency Specification, 5.13.9.4 5. Interlocks within a Single Instruction, 5.13.4.2 6. MOVE STRING, 7.5.94 7. MOVE WITH DESTINATION KEY, 10.29 8. MOVE WITH SOURCE KEY, 10.31 9. MOVE LONG (MVCL), A.3.26 10. CIPHER MESSAGE WITH CHAINING (KMC), 7.5.25 -- 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: IBM VSAM Statistics are often Bogus
In a message dated 7/6/2005 12:56:40 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: It doesn't take a weatherman to know which the wind is blowing. ...which WAY the wind is blowing. (Unless you were trying to imply no 'way' in your original sentence?) If we are going to quibble over the lyrics, let's go to the Principles of Operation itself: You don’t need a weather man To know which way the wind blows [Bob Dylan: 1965; “Subterranean Homesick Blues”] Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: destructive overlap
Paul Gilmartin wrote: In a recent note, Greg Smith said: Date: Wed, 6 Jul 2005 12:26:01 -0400 ds 0d a ds 12x b ds 16x But if I code mvc b(16),a the overlap is destructive (ie b won't necessarily be an exact copy of a). Would a concurrent copy occur? (in this case, a concurrent copy could occur without affecting the result). No. I believe the destructive character of the overlap has long been part of the specification of MVC. In particular, programmers of old were accustomed to blanking out a buffer with: MVI C' ',A MVC A+1(L'A'-1),A (before padding MVCL). -- gil Well that's what I would think. I'm trying to understand concurrent copy better - as I understand it, if the dest and source begin on the same byte boundary in a doubleword, doublewords are fetched and stored concurrently and if they are off by 4 then fullwords are fetched and stored concurrently (once you get to the proper boundary). However, if there is destructive overlap, then bytes are moved 1 at a time. But, I cannot get the program below to fail. Either I don't quite understand destructive overlap (tfm: ` Destructive overlap is said to exist when the result location is used as a source after the result has been stored, assuming processing to be performed one byte at a time') or there is concurrent copy if the source and dest are far enough apart. Greg MVCTEST CSECT SAVE (14,12) lr 12,15 using MVCTEST,12 IDENTIFY EP=SUBTASK,ENTRY=SUBTASK ATTACH EP=SUBTASK loopmvca(32),c mvca(16),b mvcb(16),a clisw,0 be loop STIMER WAIT,BINTVL==f'5' RETURN (14,12),RC=0 SUBTASK SAVE (14,12) lr 12,15 ahi12,MVCTEST-SUBTASK l 0,=a(N) loop2 l 1,b cl 1,c+12 be cont cl 1,c+24 be cont cl 1,c be cont mvisw,1 dc h'0' contbct0,loop2 mvisw,1 RETURN (14,12),RC=0 N EQU5 sw dc f'0' ds d a ds 12x b ds 20x c dc x'01020304',x'05060708',x'090a0b0c',x'0d0e0f10' dc x'11121314',x'15161718',x'191a1b1c',x'1d1e1f20' end -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
[EMAIL PROTECTED] wrote in message news:OFD38D43EF.26E4669D-ON85257036.005F128B-85257036.005 [EMAIL PROTECTED]... Ok, I'll be the whipping boy. Why can't the Operating System be Enhanced to intercept the Abend and close the files. That's what module IFG0TC0A (IFG-gotcha) does.It is an exit invoked by task termination to process open files. However, there are problems closing files as I mentioned before. Most of the VSAM control blocks are in user key. If these have been overlaid or incorrectly modified, writing this data to the catalog may BREAK THE DATA SET. The effects of breaking the data set are much worse than throwing away the data and verifying the data set on the next open. No one wants an online application to have to recover a major data set and be down for hours because it was broken closing it during an ABEND because data was overlaid. Close any input file and/or VSAM file. There is already alot of processing that occurs after the abend by building the dump thru Abend-Aid and other debuggers. We already have CICS with DTB feature that will backout changes and adds back to the last SYNCPOINT. DB2 can backout changes and adds back to the last COMMIT. So why can't Z/OS be changed to make sure that VSAM files are closed during Abend process ?? Because the only code at the moment is during task termination. As I mentioned before, the access methods do NOT have recovery routines because of the overhead and performance implications. Not that we're not trying to solve that problem, but it's going to take quite a while to do it. Movement of the control blocks into protected storage is a goal also, but given the number of users/vendors/applications that try to touch these blocks (and sometimes change them) means there are a lot of issues with doing this. Not that we're not going to do it, but existing references by programs will have to be changed. So when CICS and/or DB2 recovery routines get entered, they can do backout, etc. However control has been yanked away from the access method until task termination processing, WAY after the application recovery routines have been deleted. Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
In a message dated 7/6/2005 2:51:54 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Most of the VSAM control blocks are in user key. If these have been overlaid or incorrectly modified, writing this data to the catalog may BREAK THE DATA SET. The effects of breaking the data set are much worse than throwing away the data and verifying the data set on the next open. No one wants an online application to have to recover a major data set and be down for hours because it was broken closing it during an ABEND because data was overlaid. A Devil's Advocate might be tempted to say just because you don't ABEND does not mean that a user did not overlay or incorrectly modify VSAM control blocks that are in user key. How can you ever trust the stats? Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: destructive overlap
On Wed, 6 Jul 2005 13:02:22 -0500, Steve Arnett [EMAIL PROTECTED] wrote: ... And for Steve's doubts about destructive overlap: Ranked Search Results for Book: dz9zr003 z/Architecture Principles of Operation 10 topics have matches for: destructive overlap 1. MOVE LONG, 7.5.90 2. MOVE LONG EXTENDED, 7.5.91 3. MOVE LONG UNICODE, 7.5.92 4. Consistency Specification, 5.13.9.4 5. Interlocks within a Single Instruction, 5.13.4.2 6. MOVE STRING, 7.5.94 7. MOVE WITH DESTINATION KEY, 10.29 8. MOVE WITH SOURCE KEY, 10.31 9. MOVE LONG (MVCL), A.3.26 10. CIPHER MESSAGE WITH CHAINING (KMC), 7.5.25 ... I think if you go back to pre-z POPs you'll find the term only on those instructions that didn't support it. (It's destuctive. We're proctecting you.) I guess MVC with overlap is a contructive use. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to free up space from deleted datasets wtihout IXFP
On Wed, 6 Jul 2005 11:16:52 -0400, David Andrews wrote: One way to free up space on your RVA without IXFP is to fill up your volumes with large datasets containing binary zeros, then delete those datasets. The backend will still remember those tracks as they do without IXFP today, but they'll be compressed into near-nothingness. Or (mis)use the erase-on-scratch function: create a RACF profile with the ERASE attribute and allocate and delete datasets using this profile. The system overwrites the extent(s) with binary zeros during deletion. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
On Wed, 6 Jul 2005 20:56:49 +0300, Binyamin Dissen wrote: Neither RRDS or ESDS have any particular advantage over BDAM (despite IBM calling it obsolete) or BSAM/QSAM. Hmm, you get VSAM statistics for RRDS and ESDS. Isn't that an advantage... g, d r Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RVA: How to free up space from deleted datasets wtihout IXFP
On Wed, 6 Jul 2005 09:20:39 -0700, Edward E. Jaffe wrote: Interesting. We no longer have an RVA, so I can't try anything. But I seem to remember the NCL going down when we reinitialized a volume. OTOH, we did run IXFP. That probably explains why we observed that phenomenon. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CP6PIU02/3.2.5.2?SHELF=CP6BKS03DT=19990405153646CASE= http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/C2671784/5.6?SHELF=C2673780DT=19990712113601 It is also recommended that Interval DDSR be run immediately after reinitializing a RAMAC Virtual Array volume, after restoring a new RAMAC Virtual Array volume, and after running a utility such as IBM's DFDSS DEFRAG on a volume. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
... 1) One can always do one's own interval accounting by opening and closing the file periodically. ... I hope you are joking! -teD In God we Trust! All others bring data! --Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, July 05, 2005 7:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM VSAM Statistics are often Bogus ... 1) One can always do one's own interval accounting by opening and closing the file periodically. ... I hope you are joking! -teD Why? I've been known to do CLOSE TYPE=T on sequential datasets after processing n records. Of course, IIRC, it was a specialized application. Lost is the mists of pre-history, now. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
... have seen people referring to VSAM as IBM's ISAM ... That's like saying it's IBM's PDSE, z/OS, etc. -teD In God we Trust! All others bring data! --Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
Bill Fairchild writes: A Devil's Advocate might be tempted to say just because you don't ABEND does not mean that a user did not overlay or incorrectly modify VSAM control blocks that are in user key. How can you ever trust the stats? and there is of course a sense in which his argument is unanswerable; but it is finally irrelevant because too fertile (and sophomoric): It can be used to argue that no result of any program's execution can be trusted. I have already made it clear that the tone of many of the posts in this thread is offensive. Much of it is also silly. He who uses a report format as a programming interface may think himself clever, but he has no basis for complaint when t changes. John Gilmore Ashland, MA 01721 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
A Devil's Advocate might be tempted to say just because you don't ABEND does not mean that a user did not overlay or incorrectly modify VSAM control blocks that are in user key. How can you ever trust the stats? Bill Fairchild Note: CICS, recovering an application abend (via DTB) does not have to Close a VSAM file, since the in-flight work is backed out, and the CIs that are frozen (enqueued) are released at sync-point rollback. This lets other transactions continue against that VSAM file. Closing during/after DTB is irrelevant. DB2 and IMS are careful users of VSAM also. Another thread on this list is discussing destructive moves, etc. Why mention it? The point is this. In higher level languages one has to be particularly lax as a programmer to cause VSAM control block overlays and destructive (when unintended) moves. So it is assembler that can bite the unwary yet diligent programmer. But if you are coding assembler in the first place, it is because you need some function that should be denied to Joe programmer. This language imposes a stiffer testing methodology and (dare I say) greater knowledge about how things work on the developer. TRUST is inherent in a (debuged) language and (debuged) OS, since the hardware will do exactly what it is told... no more, no less. What user? We're talking programmer. What programmer? Using his native language? Perhaps there should be a TRUST quotient assigned to each program based on the author's skill and care and test time, divided by the language complexity and factored by its size and host of the program (CICS, batch, Websphere, etc). If you want VSAM to make the stats trustworthy, write trustworthy programs. At least acknowledge the probability of a failure and plan for it. (I'll not debate the imagined solution of user-written ESTAEx and the problems of having an FFR, VSAM under SRB, VSAM in a Plex under RRS in the CCF, distributed LUWs, etc) -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
...
Who said IBM doesn't have a sense of humor? Thanks,Mark, that gave me
the giggles.
...
I verified this one years ago.
I don't know if it's still true.
The programme prefix for dfpSMS is IGD.
Years ago, either the main module or an alias was IGDZILLA.
“I, God-Zilla”.
(8-{]}
-teD
In God we Trust!
All others bring data!
--Deming
--
For IBM-MAIN subscribe / signoff / archive access instructions,
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 VSAM Statistics are often Bogus
... Why? I've been known to do CLOSE TYPE=T on sequential datasets after processing n records. Of course, IIRC, it was a specialized application. Lost is the mists of pre-history, now. ... Open/Close processing is not cheap. Also, if you have (partial-)release on close, you can easily create a multi-(tiny)extent file in no time. -teD In God we Trust! All others bring data! --Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 Enterprise 3.4
I'm working on my Cobol-Analyzer called COBANAL (www.cbttape.org file321). to support the newest Cobol-Compiler. Anybody running this version and is able to send me a load-module compiled with Enterprise Cobol V3.4 including a compile listing? Please contact me and I'll give you more details. Thanks Mit freundlichen Grüßen Kind regards i. A. Roland Schiradin Alte Leipziger Lebensversicherung a.G. IT-Betrieb Tel. (06171) 66-4095, Fax (06171) 66-7500-4095 mailto:[EMAIL PROTECTED] www.alte-leipziger.de -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
Will this thread never end? Mark Thomen explained now several times the why and the current state of this issue. Please raise requirements if you relay on those statistics and explain the business case and also how did you handle this the last nn years in the past. I believe a lot of customers will not vote for such a requirement because of the possible performance issue. As for Alte-Leipziger I can say it's not issue for us. Roland -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
... As for Alte-Leipziger I can say it's not issue for us. ... I couldn't find the meaning of that compound word. -teD In God we Trust! All others bring data! --Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
In a message dated 7/6/2005 4:24:41 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: A Devil's Advocate might be tempted to say just because you don't ABEND does not mean that a user did not overlay or incorrectly modify VSAM control blocks that are in user key. How can you ever trust the stats? and there is of course a sense in which his argument is unanswerable; but it is finally irrelevant because too fertile (and sophomoric): It can be used to argue that no result of any program's execution can be trusted. My point was that it does not seem to me to be any more likely that the stats have been hosed if all we know is that an ABEND has occurred. If you want to determine the likelihood that the stats have been hosed, you should examine the stats for reasonableness, whether ABENDing or NORMENDing. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
Peter, Well, as long as we are bearing our sins, I must humbly admit that I have coded REXX to process the entire catalog structure based on LISTCAT output (then changed to CSI output) and then taken actions. The shame of it all. I have Ron F. to thank for showing me the error of my ways of trusting stats on open and/or corrupted files and leading me back to the path of right-stat-ness. grin My problem is not having a narrow vision. Mine is having visions that are often too grand! :) The penance for both of us is to write Invalid data is invalid data ten thousand times. Under ISPF EDIT, it should take us roughly ten seconds. vbg Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Wednesday, July 06, 2005 10:32 AM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: IBM VSAM Statistics are often Bogus I never even envisioned automated tools looking at VSAM stats. My ASSumption when reading Mark's posts was that he was referring to individual programmers looking at individual VSAM file stats for guidance. My experience is obviously severely limited in this regard, as in my varied positions over the years the usual case was that all of the applications' datasets (including VSAM) were our (the application programmers') responsibility to feed and care for, and we never had thousands to contend with. As for my ASSumption on criticality, the normal performance variations (once a good initial design and shakeout was done) for an individual (set of) application file(s) were never that critical unless severe volume increases occurred. A parochial point of view, I must freely admit. I stand humbly corrected. My vision is obviously way too narrow. 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. Seeing Beyond Money is a service mark 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
Collecting sysplex-wide WLM data
Hey, I thought I'd throw this one up just in case (well, just in case): I am trying to collect Sysplex-wide WLM performance data, compare actual vs. desired. Unfortunately, or so it seems, WLM's IWMRCOLL macro only provides information for the system on which it is invoked on. The documentation indicates that 'monitors can use this to combine data'. An SMF exit for RMF-written SMF 72 record, subtype 3 also appears to gather only data for the local system. Is there a way to extract sysplex-wide information of service class performance without manually merging this information in real-time? After all, WLM calculates and adjusts performance parameters according to measurements within the Sysplex (one definition per Sysplex). RMF III reports on these and I have serious doubts that it does its own x-system data aggregation. Does anybody have any notable knowledge in this area? Thanks in advance. /re -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
WLM data collection
(Sorry for the duplicate post - it showed up in the wrong thread). Hey, I thought I'd throw this one up just in case (well, just in case): I am trying to collect Sysplex-wide WLM performance data, compare actual vs. desired. Unfortunately, or so it seems, WLM's IWMRCOLL macro only provides information for the system on which it is invoked on. The documentation indicates that 'monitors can use this to combine data'. An SMF exit for RMF-written SMF 72 record, subtype 3 also appears to gather only data for the local system. Is there a way to extract sysplex-wide information of service class performance without manually merging this information in real-time? After all, WLM calculates and adjusts performance parameters according to measurements within the Sysplex (one definition per Sysplex). RMF III reports on these and I have serious doubts that it does its own x-system data aggregation. Does anybody have any notable knowledge in this area? Thanks in advance. /re -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has VSAM become synonymous with KSDS?
On Jul 6, 2005, at 3:30 PM, Norbert Friemel wrote: On Wed, 6 Jul 2005 20:56:49 +0300, Binyamin Dissen wrote: Neither RRDS or ESDS have any particular advantage over BDAM (despite IBM calling it obsolete) or BSAM/QSAM. Hmm, you get VSAM statistics for RRDS and ESDS. Isn't that an advantage... But are they accurate?:) 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: IBM VSAM Statistics are often Bogus
On Jul 5, 2005, at 7:00 PM, Ted MacNEIL wrote: ... 1) One can always do one's own interval accounting by opening and closing the file periodically. ... I hope you are joking! Ted, Along similar lines we had a programmer close and open a vsam dataset after each search. I agree with you. 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: problem IKJEFTSR
STEPLIB ... Albertus SD --- Imbriale, Donald (Exchange) [EMAIL PROTECTED] wrote: Where is the library containing VRASPFLK located? LPA? Linklist? STEPLIB? ISPLLIB? LIBDEFed? TSOLIBed? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Albertus Dwisulami Sent: Wednesday, July 06, 2005 6:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: problem IKJEFTSR I got a problem : IKJEFTSR interface error Authorized program 'VRASPFLK'. Return code = 20. Reason code = 56. I have listed the library to APF and listed also in IKJTSOxx. Someone have any sugestion ...? Thanks for the attention. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.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
FW: IBM VSAM Statistics are often Bogus
Tom, et al, I was just thinking... CICS aside, when a job ABENDS while updating a KSDS file, what is the most common thing that happens to allow the job to be rerun? Delete and restore the KSDS, right? So what good are the accumulated statistics at this point - valid or invalid? Well there worth zilcho, because they were just deleted. Gone forever. And the next day someone takes a LISTCAT of that file and makes some decision based on those stats, assuming that it represents 24 hours of activity, when it is really just the last 20 minutes of the batch run. Smart move! I would rather we just got rid of all the stats from LISTCAT. We don't have a listdb2, listdl1, listfastpath or listqsam, so why the religious fervour around LISTC stats? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Savor Sent: Thursday, 7 July 2005 1:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM VSAM Statistics are often Bogus Ok, I'll be the whipping boy. Why can't the Operating System be Enhanced to intercept the Abend and close the files. Close any input file and/or VSAM file. There is already alot of processing that occurs after the abend by building the dump thru Abend-Aid and other debuggers. We already have CICS with DTB feature that will backout changes and adds back to the last SYNCPOINT. DB2 can backout changes and adds back to the last COMMIT. So why can't Z/OS be changed to make sure that VSAM files are closed during Abend process ?? I'm probably wrong, but this sounds much easier to do, than what CICS and DB2 does. Tom Savor Certegy Card Services 11720 Amber Park Drive, Suite 500 Alpharetta, GA 30004 Phone: 678-867-8431 cell: 404-660-6898 E-Mail: [EMAIL PROTECTED] /\/\_00_/\/\ -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM Statistics are often Bogus
In a message dated 7/6/2005 6:52:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes: The penance for both of us is to write Invalid data is invalid data ten thousand times. Under ISPF EDIT, it should take us roughly ten seconds. vbg R10 Invalid data is invalid data rr rr 3.7 secs. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Collecting sysplex-wide WLM data
In a message dated 7/6/2005 7:00:53 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Does anybody have any notable knowledge in this area? Thanks in advance. Cheryl even had the presence to market it as GoalTender. _www.watsonwalker.com_ (http://www.watsonwalker.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: IBM VSAM Statistics are often Bogus
Ed, You must be a typist. It took me 7 of the 10 to type the words! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Wednesday, July 06, 2005 10:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: IBM VSAM Statistics are often Bogus In a message dated 7/6/2005 6:52:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes: The penance for both of us is to write Invalid data is invalid data ten thousand times. Under ISPF EDIT, it should take us roughly ten seconds. vbg R10 Invalid data is invalid data rr rr 3.7 secs. 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. Seeing Beyond Money is a service mark 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: IBM VSAM Statistics are often Bogus
On Jul 6, 2005, at 9:32 AM, Farley, Peter x23353 wrote: I never even envisioned automated tools looking at VSAM stats. My ASSumption when reading Mark's posts was that he was referring to individual programmers looking at individual VSAM file stats for guidance. My experience is obviously severely limited in this regard, as in my varied positions over the years the usual case was that all of the applications' datasets (including VSAM) were our (the application programmers') responsibility to feed and care for, and we never had thousands to contend with. As for my ASSumption on criticality, the normal performance variations (once a good initial design and shakeout was done) for an individual (set of) application file(s) were never that critical unless severe volume increases occurred. A parochial point of view, I must freely admit. I stand humbly corrected. My vision is obviously way too narrow. Peter -SNIP_ Peter, Somewhere in the back of my paged out (permanently?) memory is there used to be (or there is one currently) a utility that went through the catalog and looked for vsam datasets and listed any that according to its recommendation ones that needed re-orging. My mind just can't remember the name. It may have built idcams control cards as well. Can anyone come up with the name of the product? 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: IBM VSAM Statistics are often Bogus
In a message dated 7/6/2005 9:43:31 P.M. Central Standard Time, [EMAIL PROTECTED] writes: You must be a typist. It took me 7 of the 10 to type the words! I'm decent, but was able to just cut and paste! Then I went and did a review of the Oracle Grid. Hmmm, wonder how in the world they stay up forever with no abends and no catalogs??? Hmmm. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM statistics are often bogus
John, I'll take your word on the automation coding time. For now, I off to search the Internet for the meaning of boustrophedon. grin Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Wednesday, July 06, 2005 10:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: IBM VSAM statistics are often bogus The penance for both of us is to write Invalid data is invalid data ten thousand times. Under ISPF EDIT, it should take us roughly ten seconds. vbg A more exiguous penalty is clearly called for. My preference would be to require you format it in boustrophedon parametrically in full n-character lines, n = 131, which it would take you rather longer to automate. John Gilmore Ashland, MA 01721 USA 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. Seeing Beyond Money is a service mark 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: IBM VSAM statistics are often bogus
In a message dated 7/6/2005 9:54:54 P.M. Central Standard Time, [EMAIL PROTECTED] writes: boustrophedon 'Hot air balloon' -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 VSAM statistics are often bogus
Not quite! It is a writing style compare to an ox plowing a field where .noitcerid etisoppo eht ni seog dna snrut ylerem eh Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Wednesday, July 06, 2005 10:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject:Re: IBM VSAM statistics are often bogus In a message dated 7/6/2005 9:54:54 P.M. Central Standard Time, [EMAIL PROTECTED] writes: boustrophedon 'Hot air balloon' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 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. Seeing Beyond Money is a service mark 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: IBM VSAM Statistics are often Bogus
On Jul 6, 2005, at 9:48 PM, Ed Finnell wrote: --SNIP- I'm decent, but was able to just cut and paste! Then I went and did a review of the Oracle Grid. Hmmm, wonder how in the world they stay up forever with no abends and no catalogs??? Hmmm. Well, I am not a ORACLE fan but at least their catalog stats are probably correct. 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: Collecting sysplex-wide WLM data
I have done some research and it would appear that this data is available by calling the RMF sysplex data server, quizzing SMF 72 subtype 3. Does anybody have any experience doing that? Any caveats? I had a play with extracting data from the Sysplex server a while back. Basically pretty painless, although I was pulling RMFIII delay data rather than specific RMF records. I seem to recall I had to increase the buffer size - too much data coming in. Just went and had a look for my code, but it appears a cohort of mine has rebuilt that system, and all my stuff has dissipated into the ether. Ah well - was just a learning experiment anyway 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: IBM VSAM Statistics are often Bogus
At 07:36 -0500 on 07/06/2005, Chase, John wrote about Re: IBM VSAM Statistics are often Bogus: The fact remains that CEMT P SHUT I causes an ABNORMAL termination of CICS, as would the MVS CANCEL or FORCE command. The fact also remains that on a commanded ABNORMAL termination of (anything), VSAM cannot update the dataset statistics because the issuer of the command has INTENTIONALLY prevented it from doing so. Since CEMT P SHUT I causes a CONTROLLED issuance of an Abnormal Termination, there is no reason why a request to flush the statistics BEFORE doing the Abnormal Termination can't be done. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
