OT: New AFP related list started at UGA.EDU
Cross-posting to IBM-MAIN, JES2-L, JES3-L The new AFP-L discussion list is open for subscriptions. I hope to get the experts and the users back on board to quickly reestablish an AFP community. (The former list at Topica seems to be dead since October 2012.) Please spread the word among your colleagues involved in AFP who might not follow this list. To join the list, send an email to lists...@listserv.uga.edu with the following single line body: SUBSCRIBE AFP-L firstname lastname The Web interface to access the list archives and to post to the list is at http://listserv.uga.edu/archives/afp-l.html -- Peter Hunkeler Owner of the AFP-L at LISTSERV.UGA.EDU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local MCS Console Solutions
W dniu 2013-06-02 19:10, Don Williams pisze: Good points which is why I don't setup them up as NIP consoles and we only allow access inside our firewall. Well, the only reason I need hard consoles is NIP/IPL/shutdown process. Later (after IPL) I can use EMCS consoles (SDSF) or VTAM consoles if any. Of course YMMV. :-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
Thank you , if no ENF signal, nothing to do . On 30.05.2013 13:55, Peter Relson wrote: There are a lot of ENF's that are for IBM use only, for which case I would expect there to be no details in the books. While it is possible that this is an oversight, it is more likely that it is not. I don't actually see anything in the SDUMP code that issues an ENF signal. Perhaps there is no such signal produced any longer, even if there is an event code assigned. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: New AFP related list started at UGA.EDU
Hunkeler Peter (TLSG 4) wrote: The new AFP-L discussion list is open for subscriptions. Cool! ;-) Very Cool! :-D Now you can get rich from being an admin... ;-D Groete / Greetings Elardus Engelbrecht PS: I know, being an admin is just a volunteer type of work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cloning SMPE with Renaming
Hello Group, I am trying to take a back up of a products like SMPED.MRSTAR.** and restoring to other LPAR like SMPEP.MRSTAR.**. So to make the cloned SMPE environment to work what are the other things which needs renaming ? so that SMPEP.MRSTAR.** Goes well. I understand the DDDEF needs the renaming as well, but after restoring with rename I am not able to select target zone via SMPE panel. So any advises or suggestions ? /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: New AFP related list started at UGA.EDU
Now you can get rich from being an admin... ;-D I was more looking for something to help me avoid a heart attack when I cannot determine that hidden error in an AFP datastream. A place to discuss with experts like here on IBM-MAIN. But then, if becoming rich is part of the list owner game, I won't refuse it :-) -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
Hi John, Peter, * Re. I am also suspicious of Jan Vanbrabant's esclusion of homologation from this discussion. The word is derived from the ancient Greek verb homologein, to approve, which becomes homologare, to agree, in fairly late Latin. (It has a special meaning in Scots law, where it is used to characterize a process of removing minor defects from contracts, the remediated versions of which are then given the force of law.)* * Re. As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to (Internal or Product) Quality Assurance and ACCEPTANCE to Client Test. My organization uses both, though not in disparate technical or physical environments, and always without recompilation.* This is exactly what it means, Peter ! Jan On Fri, May 31, 2013 at 9:40 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. In the case where each stage from development to production may reside on physically and/or technically disparate systems, I admit that recompilation seems like a reasonable solution to ensure accurate and effective execution at each stage, but again ISTM that the additional verification requirements are far too onerous a cost both technically and bureaucratically. IMHO, of course. We can certainly agree to disagree on this. As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to (Internal or Product) Quality Assurance and ACCEPTANCE to Client Test. My organization uses both, though not in disparate technical or physical environments, and always without recompilation. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, May 31, 2013 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To recompile or not recompile, that's the question Predictably I suppose, recompilation gets my vote. The issues involved are technical and not management ones, and bureaucratizing them never helps. Development takes some time, and linking the development version of a PL/I compiler to that in current production use is always a bad idea. It ensures that retrograde technology and performance will be wired into newly developed systems. (This may happen anyway, of course; the use of the best translator is a necessary but not a sufficient condition for high performance. That use can be, often is, perfunctory.) I am also suspicious of Jan Vanbrabant's esclusion of homologation from this discussion. The word is derived from the ancient Greek verb homologein, to approve, which becomes homologare, to agree, in fairly late Latin. (It has a special meaning in Scots law, where it is used to characterize a process of removing minor defects from contracts, the remediated versions of which are then given the force of law.) If, as I suspect, homologation here has to do with ensuring that a systems meets its functional specifications, it is relevant. John Gilmore, Ashland, MA 01721 - USA -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning SMPE with Renaming
It would help to know what error messages you are getting? How did you do the renames? Did you do any UCLIN after the renames? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Monday, June 03, 2013 3:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cloning SMPE with Renaming Hello Group, I am trying to take a back up of a products like SMPED.MRSTAR.** and restoring to other LPAR like SMPEP.MRSTAR.**. So to make the cloned SMPE environment to work what are the other things which needs renaming ? so that SMPEP.MRSTAR.** Goes well. I understand the DDDEF needs the renaming as well, but after restoring with rename I am not able to select target zone via SMPE panel. So any advises or suggestions ? /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
Hi to you all, wise gal and guys, THANK YOU SINCERELY for all your valuable réactions! I think the overall conclusion might (!) be: the techies seem rather to be PRO-recompile, while the more development oriented people CONTRA-recompile and hence PRO-copying, and this certainly between ACCEPTANCE and PRODUCTION ! I am a techie, and hence rather PRO-re-compile, while I adore technical beauties, much more than the application solution. But these wise considerations about regression testing and its managing burden when re-compiling lead to my final conclusion: A chacun son métier !. Every man to his own trade! (does this sound english enough ?;-) ) We can't be good at everything Cheers to you all. Jan On Mon, Jun 3, 2013 at 1:27 PM, Jan Vanbrabant vanbrabant...@gmail.comwrote: Hi John, Peter, * Re. I am also suspicious of Jan Vanbrabant's esclusion of homologation from this discussion. The word is derived from the ancient Greek verb homologein, to approve, which becomes homologare, to agree, in fairly late Latin. (It has a special meaning in Scots law, where it is used to characterize a process of removing minor defects from contracts, the remediated versions of which are then given the force of law.)* * Re. As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to (Internal or Product) Quality Assurance and ACCEPTANCE to Client Test. My organization uses both, though not in disparate technical or physical environments, and always without recompilation.* This is exactly what it means, Peter ! Jan On Fri, May 31, 2013 at 9:40 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. In the case where each stage from development to production may reside on physically and/or technically disparate systems, I admit that recompilation seems like a reasonable solution to ensure accurate and effective execution at each stage, but again ISTM that the additional verification requirements are far too onerous a cost both technically and bureaucratically. IMHO, of course. We can certainly agree to disagree on this. As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to (Internal or Product) Quality Assurance and ACCEPTANCE to Client Test. My organization uses both, though not in disparate technical or physical environments, and always without recompilation. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, May 31, 2013 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To recompile or not recompile, that's the question Predictably I suppose, recompilation gets my vote. The issues involved are technical and not management ones, and bureaucratizing them never helps. Development takes some time, and linking the development version of a PL/I compiler to that in current production use is always a bad idea. It ensures that retrograde technology and performance will be wired into newly developed systems. (This may happen anyway, of course; the use of the best translator is a necessary but not a sufficient condition for high performance. That use can be, often is, perfunctory.) I am also suspicious of Jan Vanbrabant's esclusion of homologation from this discussion. The word is derived from the ancient Greek verb homologein, to approve, which becomes homologare, to agree, in fairly late Latin. (It has a special meaning in Scots law, where it is used to characterize a process of removing minor defects from contracts, the remediated versions of which are then given the force of law.) If, as I suspect, homologation here has to do with ensuring that a systems meets its functional specifications, it is relevant. John Gilmore, Ashland, MA 01721 - USA -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send
Re: Cloning SMPE with Renaming
Hello Lizette, To be honest I just tried using SMP/E panel rather than Batch. Do you have any sequence of sample Batch Jobs which are used in renaming the internal information of SMP/E ? Jake On Mon, Jun 3, 2013 at 5:05 PM, Lizette Koehler stars...@mindspring.comwrote: It would help to know what error messages you are getting? How did you do the renames? Did you do any UCLIN after the renames? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Monday, June 03, 2013 3:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cloning SMPE with Renaming Hello Group, I am trying to take a back up of a products like SMPED.MRSTAR.** and restoring to other LPAR like SMPEP.MRSTAR.**. So to make the cloned SMPE environment to work what are the other things which needs renaming ? so that SMPEP.MRSTAR.** Goes well. I understand the DDDEF needs the renaming as well, but after restoring with rename I am not able to select target zone via SMPE panel. So any advises or suggestions ? /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
Right. Honest, I was not trying to be obscure or overly clever. What I do in all of my xSAM/BPAM code is code all of the DCB's and DECB's and other RMODE 24 stuff in its own CSECT (and sometimes, just because it organizes the code better, even other small things that do not HAVE to be RMODE 24 like a DCBE). I then do a GETMAIN 24 at run time for the length of the CSECT and copy all of the QSAM stuff into the GETMAIN area. With some cleverness you can then use the CSECT like it was a DSECT for addressing the tables in the GETMAIN area. Sometimes you have to manually relocate a couple of address constants, like the DECB pointer to the DCB. However, I don't think I copy any BUFCB's anywhere. I think QSAM automatically allocates the BUFCB wherever it chooses (presumably it chooses RMODE 24) and the buffers wherever you tell it to allocate them (RMODE ANY in my case). Am I confused? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, June 03, 2013 12:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage It can be done that way, you are right, but I figure if the OP's program is using BUILD and GETBUF then my statements may prove to help him with his problem, and that's my reason for posting what I did, to help the OP. I could have qualified my statement by adding saying unless the program is copying the BUFCB (and not the buffers) below the line but I thought but who does that? Well, now I know who does that, or something like that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning SMPE with Renaming
... I just tried using SMP/E panel rather than Batch. Do you have any sequence of sample Batch Jobs which are used in renaming the internal information of SMP/E ? If you copied your CSI data sets then most likely you need to update the ZONEINDEX subentries in the global zone for the target and dlib zones so they point to the new name CSI data sets. Use UCLIN like this: SET BDY(GLOBAL). LIST GZONE /* List the existing, so you have it for reference... just in case. */. UCLIN. DEL GZONE ZONEINDEX((tgtZone)). ADD GZONE ZONEINDEX((tgtZone, new.dsname.CSI, TARGET)). ENDUCL. Repeat the DEL and ADD statements for however many target and dlib zones live in CSI data sets with new names. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
I must admit that I too am guilty of offenses very like the ones Charles Mills appears to have committed. I put data-management control blocks that must be below the line below it, but it would not occur to me to put buffers there. Moreover, it seems to me that there is a rationale for doing this. Storage below the line is crowded in many shops, so crowded that large VSCR efforts must be and have been mounted to free up some of it. (Above-the-bar VSCR projects may be in the womb of time, but I judge that their gestation period will be very long.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local MCS Console Solutions
Seconded! OSA/ICC works great... snip We have used OSA-ICC for several years. The Visara has been off maintenance for years, but has not died. We still use it for back-up consoles. /snip snip However, when we upgrade our processor to a zBC12 (or whatever the next mid-range processor ends up being called), it won't support ESCON anymore. So, we need to do something: 1. Install ESCON - FICON converters. Do they work for this sort of application? 2. Upgrade to Visara's latest FICON-attached offerings. Any experiences? 3. Consider other console technologies. How do they stack up to Visara? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
It is also part of the name of a sports car - Gran Turismo Omologato (aka GTO), meaning homologated grand tourer, a luxury car that has been homologated (certified or approved) for racing. And sometimes Darren has to be involved in homologating posts on this list server. Bill Fairchild Franklin, TN - Original Message - From: Jan Vanbrabant vanbrabant...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, June 3, 2013 6:27:47 AM Subject: Re: To recompile or not recompile, that's the question Hi John, Peter, * Re. I am also suspicious of Jan Vanbrabant's esclusion of homologation from this discussion. The word is derived from the ancient Greek verb homologein, to approve, which becomes homologare, to agree, in fairly late Latin. (It has a special meaning in Scots law, where it is used to characterize a process of removing minor defects from contracts, the remediated versions of which are then given the force of law.)* * Re. As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to (Internal or Product) Quality Assurance and ACCEPTANCE to Client Test. My organization uses both, though not in disparate technical or physical environments, and always without recompilation.* This is exactly what it means, Peter ! Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
On 06/01/2013 10:58 PM, Shmuel Metz (Seymour J.) wrote: In 985915eee6984740ae93f8495c624c6c2318055...@jscpcwexmaa1.bsg.ad.adp.com, on 05/31/2013 at 03:40 PM, Farley, Peter x23353 peter.far...@broadridge.com said: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. Yes, additional regression checking is expensive. However, how do you validate a new release or service level of the compiler without it? What do you do when you roll a new release of the compiler into production and discover six months later that you can't compile a module that you need to update? Sometimes pay now is less expensive than pay later. Now, if there is an LPAR hierarchy with the same levels of the compilers and static libraries, no recompile is necessary. But when you promote changes to the compilers (static libraries), a recompile (rebind) of everything, followed by testing, is the only way to be sure that you didn't break anything. Our experience over multiple decades was that actual compiler or language run-time bugs or undocumented changes that affected our code were so rare that it was the last thing to consider when application development was having code problems. Subtle mis-use of the langauge or just logic bugs accounted for 99.99%+ of problems encountered. I recall a few subtle undocumented changes in three decades in either the compiler or run-time environment which caused some minor grief to applications until they were resolved or code modified, but the only cases which required or justified a massive recompile of everything were a very few cases where significant documented changes in compiler syntax and semantics made it clearly necessary. It is IBM's job, not that of individual installations, to do regression testing of the compiler and language run-time environments across version changes and maintenance that is not intended to change syntax or semantics, and at least in our experience any bugs that escaped their testing were so subtle that UNLESS you re-compiled everything you would have a low probability of encountering them before someone else hit them and a resolution was available. We tested new compiler versions to validate basic functionality, but this was always just to be sure there wasn't some obvious installation configuration error on our part. Recompiling everything for each new compiler version only proves a clean compile is possible, not that the semantic behavior of the code has not been changed in some subtle way that may not surface until 6 months later. It always seemed to us that the much saner approach with a new compiler level was to only force its use with new development and on-going maintenance, so that any problems would be manifested in code that was already being closely monitored for unexpected behavior; and any subtle issues that weren't' immediately apparent would be confined to that code, rather than unnecessarily exposing all in-house applications. One of the big advantages to MVS has always been the deliberate design for upward compatibility, precisely so you don't have to recompile and retest all applications every time there is major maintenance to the Operating System or its component parts, which would increase programming costs by a significant factor. It is absolutely essential to have adequate program management in place to guarantee that for every application program running you also have the matching program source. It is not essential, and just asking for problems, to attempt to recompile everything whenever there is a compiler version or maintenance change, unless that change has documented compatibility issues with old source code and previously compiled code. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
BUILD is only capable of creating a BUFCB that is immediately followed by the buffers, as it only has one operand to indicate the memory location, as you no doubt know. Earlier you said your program does not use BUILD. If your program had used BUILD, like the OP's does, and given it the address of an area above the line, which we don't know in the OP's case, it would be necessary to copy the BUFCB part of the area below the line and point the DCB to the copy. This possibility is not mentioned in the manual. The description of the BUILD operand says If the area resides above the line, it cannot be used by other access method macros. This page in Chapter 21 of Using Data Sets: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D4A0/3.2.8 says For BSAM, IBM recommends that you allocate data areas or buffers through GETMAIN, STORAGE, or CPOOL macros and not through BUILD, GETPOOL, or by the system during OPEN. Allocated areas can be above the line. This leads me to believe that the OP's program was not written with buffers above the line in mind, since it uses BUILD, but that is just a guess. Bill On Mon, 3 Jun 2013 08:28:19 -0400, Charles Mills wrote: Right. Honest, I was not trying to be obscure or overly clever. What I do in all of my xSAM/BPAM code is code all of the DCB's and DECB's and other RMODE 24 stuff in its own CSECT (and sometimes, just because it organizes the code better, even other small things that do not HAVE to be RMODE 24 like a DCBE). I then do a GETMAIN 24 at run time for the length of the CSECT and copy all of the QSAM stuff into the GETMAIN area. With some cleverness you can then use the CSECT like it was a DSECT for addressing the tables in the GETMAIN area. Sometimes you have to manually relocate a couple of address constants, like the DECB pointer to the DCB. However, I don't think I copy any BUFCB's anywhere. I think QSAM automatically allocates the BUFCB wherever it chooses (presumably it chooses RMODE 24) and the buffers wherever you tell it to allocate them (RMODE ANY in my case). Am I confused? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, June 03, 2013 12:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage It can be done that way, you are right, but I figure if the OP's program is using BUILD and GETBUF then my statements may prove to help him with his problem, and that's my reason for posting what I did, to help the OP. I could have qualified my statement by adding saying unless the program is copying the BUFCB (and not the buffers) below the line but I thought but who does that? Well, now I know who does that, or something like that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
Ah! Got it. The OP has been absent from this discussion for a while. Either the problem is solved, or he has gotten tired of our debate. g Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, June 03, 2013 9:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage BUILD is only capable of creating a BUFCB that is immediately followed by the buffers, as it only has one operand to indicate the memory location, as you no doubt know. Earlier you said your program does not use BUILD. If your program had used BUILD, like the OP's does, and given it the address of an area above the line, which we don't know in the OP's case, it would be necessary to copy the BUFCB part of the area below the line and point the DCB to the copy. This possibility is not mentioned in the manual. The description of the BUILD operand says If the area resides above the line, it cannot be used by other access method macros. This page in Chapter 21 of Using Data Sets: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D4A0/3.2.8 says For BSAM, IBM recommends that you allocate data areas or buffers through GETMAIN, STORAGE, or CPOOL macros and not through BUILD, GETPOOL, or by the system during OPEN. Allocated areas can be above the line. This leads me to believe that the OP's program was not written with buffers above the line in mind, since it uses BUILD, but that is just a guess. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 08:46:24 -0400, John Gilmore wrote: (Above-the-bar VSCR projects may be in the womb of time, but I judge that their gestation period will be very long.) A plausible judgment. But how about in between? Is VSCR below the bar but above the line looming? I'd expect a motivator to be LPA. How big is LPA getting in some shops? I understand that some of Java has migrated to within the bar in order to employ 32-bit addressing without triggering further below the bar VSCR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
On Fri, 31 May 2013 20:09:33 -0500, Mike Schwab wrote: We don't have enough DASD at the hot site for that. You don't have enough DASD at your hot site to run the business? Then what is it good for? -- Tom Marchant On Thu, May 30, 2013 at 7:44 PM, Jeffery Swagger wrote: Yes, this! Prereq: The company must have a DR manager of which one of his responsibilities is to ensure the families of those who leave are taken care of. Here I'm thinking of natural disasters like hurricanes. Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
On Mon, 3 Jun 2013 08:44:17 -0500, Joel C. Ewing wrote: One of the big advantages to MVS has always been the deliberate design for upward compatibility, precisely so you don't have to recompile and retest all applications every time there is major maintenance to the Operating System or its component parts, which would increase programming costs by a significant factor. Il a les défauts de ses qualités. To wit, the continued reliance on 24-bit addressing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
On Sat, 1 Jun 2013 23:58:34 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 985915eee6984740ae93f8495c624c6c2318055...@jscpcwexmaa1.bsg.ad.adp.com, on 05/31/2013 at 03:40 PM, Farley, Peter x23353 peter.far...@broadridge.com said: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. Yes, additional regression checking is expensive. However, how do you validate a new release or service level of the compiler without it? What do you do when you roll a new release of the compiler into production and discover six months later that you can't compile a module that you need to update? Sometimes pay now is less expensive than pay later. I supposed I could see a small shop, or a development shop / vendor that would do this. But I don't know that I've ever been in a production shop that did. There is no way it would ever happen in the larger ones I've been at. My current client must have a few hundred thousand COBOL programs (batch / CICS mostly) and the cost to test after compile even 10% of them would far far out weigh whatever cost of fixing a program or programs that had a problem 6 months down the line. In my experience, those have been few and far between anyway (although I admit I am not in the loop for many application issues). As far as validation, there is plenty of activity on a daily basis to point to a new compiler when we are ready to and then cut over to it being the default once everyone is comfortable. I have been at shops that did it one application system at a time to migrate from COBOL II to Enterprise V3, but that was the last time all programs were compiled and tested for any given application. No one wants to do that again! Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
However, with the upcoming release of Enterprise COBOL 5.1 and its radically different code generation (and, I am guessing, runtime library contents and usage to match), there exists at least the *possibility* we may have to do something similar again. I certainly hope not (one would *hope* that IBM would not do that to us), but I have not yet seen the migration guide/advice from IBM to be sure about it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Monday, June 03, 2013 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To recompile or not recompile, that's the question On Sat, 1 Jun 2013 23:58:34 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 985915eee6984740ae93f8495c624c6c2318055...@jscpcwexmaa1.bsg.ad.adp.com, on 05/31/2013 at 03:40 PM, Farley, Peter x23353 peter.far...@broadridge.com said: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. Yes, additional regression checking is expensive. However, how do you validate a new release or service level of the compiler without it? What do you do when you roll a new release of the compiler into production and discover six months later that you can't compile a module that you need to update? Sometimes pay now is less expensive than pay later. I supposed I could see a small shop, or a development shop / vendor that would do this. But I don't know that I've ever been in a production shop that did. There is no way it would ever happen in the larger ones I've been at. My current client must have a few hundred thousand COBOL programs (batch / CICS mostly) and the cost to test after compile even 10% of them would far far out weigh whatever cost of fixing a program or programs that had a problem 6 months down the line. In my experience, those have been few and far between anyway (although I admit I am not in the loop for many application issues). As far as validation, there is plenty of activity on a daily basis to point to a new compiler when we are ready to and then cut over to it being the default once everyone is comfortable. I have been at shops that did it one application system at a time to migrate from COBOL II to Enterprise V3, but that was the last time all programs were compiled and tested for any given application. No one wants to do that again! Mark -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 09:28:07 -0500, Paul Gilmartin wrote: I understand that some of Java has migrated to within the bar Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. For example, the Extended Addressability Guide for z/OS release 2 has this definition of the bar: quote bar. A virtual line that marks the 2-gigabyte address in a 64-bit address space. It separates virtual storage below the 2-gigabyte address (called below the bar) from virtual storage above the 2-gigabyte line (called above the bar). /quote And in the description of the IARV64 macro in the Assembler Services Guide for z/OS release 2 there is this description: quote The two gigabyte address in the address space is marked by a virtual line called the bar. The bar separates storage below the two gigabyte address, called below the bar, from storage above the two gigabyte address, called above the bar. /quote In any case, the area that has been reserved for Java is (IIRC) from 2GB to 32 GB, well beyond 4 GB. in order to employ 32-bit addressing without triggering further below the bar VSCR. There is no such thing as 32-bit addressing. Addresses in z/Architecture are either 24, 31 or 64 bits. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
Early doc available publicly from IBM seems to indicate that no conversion necessary for source code already at Ent COBOL 4.2. I am also waiting for the COB V5 documentation library to become available for more specific wording. Of course the usual caveats apply, and that is to make sure you have the LE support for COBOL V5 runtime on all systems in your environment before you start compiling programs under the new level. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, June 03, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To recompile or not recompile, that's the question However, with the upcoming release of Enterprise COBOL 5.1 and its radically different code generation (and, I am guessing, runtime library contents and usage to match), there exists at least the *possibility* we may have to do something similar again. I certainly hope not (one would *hope* that IBM would not do that to us), but I have not yet seen the migration guide/advice from IBM to be sure about it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Monday, June 03, 2013 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To recompile or not recompile, that's the question On Sat, 1 Jun 2013 23:58:34 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 985915eee6984740ae93f8495c624c6c2318055...@jscpcwexmaa1.bsg.ad.adp.com , on 05/31/2013 at 03:40 PM, Farley, Peter x23353 peter.far...@broadridge.com said: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. Yes, additional regression checking is expensive. However, how do you validate a new release or service level of the compiler without it? What do you do when you roll a new release of the compiler into production and discover six months later that you can't compile a module that you need to update? Sometimes pay now is less expensive than pay later. I supposed I could see a small shop, or a development shop / vendor that would do this. But I don't know that I've ever been in a production shop that did. There is no way it would ever happen in the larger ones I've been at. My current client must have a few hundred thousand COBOL programs (batch / CICS mostly) and the cost to test after compile even 10% of them would far far out weigh whatever cost of fixing a program or programs that had a problem 6 months down the line. In my experience, those have been few and far between anyway (although I admit I am not in the loop for many application issues). As far as validation, there is plenty of activity on a daily basis to point to a new compiler when we are ready to and then cut over to it being the default once everyone is comfortable. I have been at shops that did it one application system at a time to migrate from COBOL II to Enterprise V3, but that was the last time all programs were compiled and tested for any given application. No one wants to do that again! Mark -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe
Re: To recompile or not recompile, that's the question
In another context someone here once cited the Irish washer woman who feared that she would grow bored with praising the Lord for all eternity, and I have similar reactions to praise of regression testing. (She was the same washer woman who hoped, since she had no voice, that she would get out of ther singing.) Regression testing is too often simplistic. An example will help me to make clear what I mean.. During Y2K remediation testing in one shop I was advising some hundreds of discrepancies, all suspiciously of the same sign, arose. Traced to their source---They were all traced!---they all stemmed from use of the same 'guilty' subroutine, which I had written. There was of course some glee that I was the culprit. Its defect was that it determined leap years correctly using the Gregorian rule. The code it replaced had instead used the Julian leap-year rule, obsolete since 1582 or thereabouts. What I found interesting was that some senior people argued vociferously for retention of the old rule for the sake of consistency with the past. It was, they said, too late to use the correct rule. My response was that it was too late to use the incorrect rule. Fortunately, the lawyers intervened. They said that retention of an obviously incorrect rule, publicly known to be so, would have horrendous legal consequences; and the new leap-year rule was adopted. Something akin to regression testing is of course inescapable; but comprehensive unit testing of new subroutines is better and, like liquor, quicker. One needs to be alerted to discrepancies, but one also needs to remember that many things are done wrong in old code. Emerson long ago observed that a foolish consistency is the hobgoblin of little minds. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 10:08:19 -0500, Tom Marchant wrote: Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. The construct is such a convenient abbreviation that I see little reason to discontinue its historic use. In any case, the area that has been reserved for Java is (IIRC) from 2GB to 32 GB, well beyond 4 GB. I stand corrected. ITYM 2GiB to 32GiB. in order to employ 32-bit addressing without triggering further below the bar VSCR. It's an interpreter. An interpreter can use whatever representation of addresses it chooses. Rexx, for example, represents addresses as hexadecimal display values of variable length. But, yes, now that you've reminded me, 32GiB requires larger addresses than 32 bits. (Probably. If an interpreter were make its smallest unit of addressable storage 8 bytes, it could still address 32GiB with 32 bit addresses. I doubt that Java is implemented in that fashion.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
DB2, IMS and CICS have already done considerable work moving stuff from 31- to 64-Bit, to name just three products. Certainly in the case of DB2 it was vital. For CICS becoming more so. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@listserv.ua.edu, Date: 06/03/2013 03:28 PM Subject:VSCR (was: Examples of getbuf and build usage) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Mon, 3 Jun 2013 08:46:24 -0400, John Gilmore wrote: (Above-the-bar VSCR projects may be in the womb of time, but I judge that their gestation period will be very long.) A plausible judgment. But how about in between? Is VSCR below the bar but above the line looming? I'd expect a motivator to be LPA. How big is LPA getting in some shops? I understand that some of Java has migrated to within the bar in order to employ 32-bit addressing without triggering further below the bar VSCR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 2013-06-03 at 11:02 -0500, Paul Gilmartin wrote: (Probably. If an interpreter were make its smallest unit of addressable storage 8 bytes, it could still address 32GiB with 32 bit addresses. I doubt that Java is implemented in that fashion.) The IBM Java implementation does precisely this. Objects all are doubleword aligned, so the low-order three bits of a 32-bit address are zero. If you enable compressed references then 64-bit pointers are right-shifted into 32-bit words. (As you note this will only work for addresses below 32GiB.) It's a big win for Java heap space, because 64-bit pointers increase object size approximately 60% per Marcel Mitran. See his IBM Java on System z presentation at: http://www-06.ibm.com/software/jp/zseries/events/language2011/download/pdf/02_e.pdf -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
On Mon, 3 Jun 2013 11:52:27 -0400, John Gilmore jwgli...@gmail.com wrote: Regression testing is too often simplistic. Regression testing is more a political / procedural / contractual / audit obligation after recompile, even if no program changes were made. Cost vs. benefit. All cost, probably no benefit or too little to just do it en masse for quite a while now. I doubt V5 will change the thinking in the general case. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
In 01d401ce6055$d6e79170$84b6b450$@mcn.org, on 06/03/2013 at 08:28 AM, Charles Mills charl...@mcn.org said: However, I don't think I copy any BUFCB's anywhere. I think QSAM automatically allocates the BUFCB wherever it chooses (presumably it chooses RMODE 24) and the buffers wherever you tell it to allocate them (RMODE ANY in my case). Am I confused? Normal usage is to let QSAM OPEN allocate the bugger pool, in which case there is nothing to relocate. If you specify BUFCB in a model DCB then it is your responsibility to relocate DCBBUFCB. There's also the issue of what you specify in your DCBE. See z/OS DFSMS Using Data Sets, SC26-7410-09 and z/OS DFSMS Macro Instructions for Data Sets, SC26-7408-08. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: New AFP related list started at UGA.EDU
In dc74548a025aff4a85f46926802a9b230a24c...@chsa1035.share.beluni.net, on 06/03/2013 at 12:17 PM, Hunkeler Peter (TLSG 4) peter.hunke...@credit-suisse.com said: I was more looking for something to help me avoid a heart attack when I cannot determine that hidden error in an AFP datastream. The last time that I had to work with AFP I wrote a REXX to format the AFP data stream. It was a lot more reliable than IEBIBALL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
In cae1xxde74ruwarz2_7t1x3qlccv8fykjrb5gqjawnlbasts...@mail.gmail.com, on 06/03/2013 at 11:52 AM, John Gilmore jwgli...@gmail.com said: Something akin to regression testing is of course inescapable; but comprehensive unit testing of new subroutines is better and, like liquor, quicker. One needs to be alerted to discrepancies, but one also needs to remember that many things are done wrong in old code. That is analogous to claiming that air is better than water, or a hammer better than a screwdriver. Unit testing is not better yhan unit testing of new routines, it is different. Both are necessary. There is a role for all of Unit testing of new routines Unit testing of old routines after changes, and accumulating a libraty of regression tests for futute changes. Integration testing, including a suite of regression tests. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Citation for reformatting of VSAM, HFS and zFS data sets
I am editing a wiki article on disk formatting and have been challenged to provide documentation of my claim that formatting a VSAM cluster, HFS or zFS rewrites existing data. I could cite dead tree documentation for VSAM in OS/VS2 R3.8, but I'd really prefer something recent enough to be available online, preferably current, and that wouldn't include the Unix file systems. I would appreciate it if someone could add appropriate citations to http://en.wikipedia.org/wiki/Disk_formatting or give me the links so that I can do so. Thanks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
I'd like to second that statement. I recall only two times when there were significant problems with new compilers and when we did large tests on new compiler versions. One was a new version of one of the first C/370 compilers (when we discovered some questionable pieces of our code that needed to be fixed, because the new compiler didn't accept them any more), and the other was the introduction of the first Enterprise PL/1 compiler - which replaced the OS PL/1 V2.3, IIRC. There were even some discussions with IBM, because some semanctics were different in the two PL/1 compilers - which was fixed by IBM after some negotiations. But that was only on the first migration, no problem with later EP PL/1 migrations. All other compiler version changes worked without problems. In the last few years, we change the C compilers with the z/OS releases and don't even test them. The tests go with the normal regression tests of our insurance math package, which we run every week. Kind regards Bernd Am 03.06.2013 15:44, schrieb Joel C. Ewing: Our experience over multiple decades was that actual compiler or language run-time bugs or undocumented changes that affected our code were so rare that it was the last thing to consider when application development was having code problems. Subtle mis-use of the langauge or just logic bugs accounted for 99.99%+ of problems encountered. I recall a few subtle undocumented changes in three decades in either the compiler or run-time environment which caused some minor grief to applications until they were resolved or code modified, but the only cases which required or justified a massive recompile of everything were a very few cases where significant documented changes in compiler syntax and semantics made it clearly necessary. It is IBM's job, not that of individual installations, to do regression testing of the compiler and language run-time environments across version changes and maintenance that is not intended to change syntax or semantics, and at least in our experience any bugs that escaped their testing were so subtle that UNLESS you re-compiled everything you would have a low probability of encountering them before someone else hit them and a resolution was available. We tested new compiler versions to validate basic functionality, but this was always just to be sure there wasn't some obvious installation configuration error on our part. Recompiling everything for each new compiler version only proves a clean compile is possible, not that the semantic behavior of the code has not been changed in some subtle way that may not surface until 6 months later. It always seemed to us that the much saner approach with a new compiler level was to only force its use with new development and on-going maintenance, so that any problems would be manifested in code that was already being closely monitored for unexpected behavior; and any subtle issues that weren't' immediately apparent would be confined to that code, rather than unnecessarily exposing all in-house applications. One of the big advantages to MVS has always been the deliberate design for upward compatibility, precisely so you don't have to recompile and retest all applications every time there is major maintenance to the Operating System or its component parts, which would increase programming costs by a significant factor. It is absolutely essential to have adequate program management in place to guarantee that for every application program running you also have the matching program source. It is not essential, and just asking for problems, to attempt to recompile everything whenever there is a compiler version or maintenance change, unless that change has documented compatibility issues with old source code and previously compiled code. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
I let QSAM allocate the little buggers wherever it wants. g Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, June 03, 2013 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage In 01d401ce6055$d6e79170$84b6b450$@mcn.org, on 06/03/2013 at 08:28 AM, Charles Mills charl...@mcn.org said: However, I don't think I copy any BUFCB's anywhere. I think QSAM automatically allocates the BUFCB wherever it chooses (presumably it chooses RMODE 24) and the buffers wherever you tell it to allocate them (RMODE ANY in my case). Am I confused? Normal usage is to let QSAM OPEN allocate the bugger pool, in which case there is nothing to relocate. If you specify BUFCB in a model DCB then it is your responsibility to relocate DCBBUFCB. There's also the issue of what you specify in your DCBE. See z/OS DFSMS Using Data Sets, SC26-7410-09 and z/OS DFSMS Macro Instructions for Data Sets, SC26-7408-08. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
... the bugger pool ... = You must've been subconsciously thinking of IBM-MAIN when you Freudian-slipped that in. ;-) = Date: Mon, 3 Jun 2013 13:46:10 -0400 From: shmuel+...@patriot.net Subject: Re: Examples of getbuf and build usage To: IBM-MAIN@LISTSERV.UA.EDU In 01d401ce6055$d6e79170$84b6b450$@mcn.org, on 06/03/2013 at 08:28 AM, Charles Mills charl...@mcn.org said: However, I don't think I copy any BUFCB's anywhere. I think QSAM automatically allocates the BUFCB wherever it chooses (presumably it chooses RMODE 24) and the buffers wherever you tell it to allocate them (RMODE ANY in my case). Am I confused? Normal usage is to let QSAM OPEN allocate the bugger pool, in which case there is nothing to relocate. If you specify BUFCB in a model DCB then it is your responsibility to relocate DCBBUFCB. There's also the issue of what you specify in your DCBE. See z/OS DFSMS Using Data Sets, SC26-7410-09 and z/OS DFSMS Macro Instructions for Data Sets, SC26-7408-08. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Longer SMFWAIT during IPL MSI
I remember having this issue years ago when using the old IPO SMFDUMP program. We forced a switch at midnight and dumped the last of the previous day's data on two loosely coupled systems. IIRC, the type 19s were produced by the IEFU29 exit under a global IPO1.SMF enqueue. The two dumps' time frames never matched because one had to wait a long time for the other to issue the l-space macro against every device in the system before proceeding. Record type 19 is written: 1. For each online device associated with a specific IPL time frame, 2. For each online device associated with a processed HALT EOD or SWITCH SMF command, and 3. When a direct access volume that is defined by DD statement is demounted. Therefore, the magnitude of the problem depends very much on the number of online devices and how fast their VTOCs can be read. Since our shop already had more modern DASD space reporting tools, we got rid of the problem by excluding type 19 in SMFPRMxx. db -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shameem .K .Shoukath Sent: Friday, May 31, 2013 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Longer SMFWAIT during IPL MSI Thanks Bob for sharing the REDBOOK details it is of good help to understand the process. We are recording 19 in all LPARs. I think storage team uses it for their reporting using 20% or something, im not sure. My actual question still stands when i compare PROD and DEV SMFPRMxx then only diff i see is the SMF EXIT IEFU84. Is this exit heavy by itself or by poor coding ? is this affecting performance POST IPL as this EXIT takes control before each SMF Write. I need to raise a CHANGE if i want to remove it and test. So I was expecting to get a feedback from the LIST whether it worth a try. I have to give some justification in the CHANGE to request the removal. Thanks and Regards Shameem K Shoukath From: Bob Rutledge deerh...@ix.netcom.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2013 8:55 PM Subject: Re: Longer SMFWAIT during IPL MSI I suggest this Redbook: http://publib-b.boulder.ibm.com/abstracts/sg247816.html?Open Bob Shameem .K .Shoukath wrote: hi there, I was just going thru the IPL statistics of all LPARs in out org. I see in one LPAR the SMFWAIT is taking fairly longer comp to others. out of total 00:01:12 MSI time this takes 00:00:53.586 I am not sure what happens in this process, took a chance compared the SMFPRMxx and saw there is one exit IEFU84 additional compared to PROD and QA lpars. would this be the cause for slower IPL ? Will it also may be one reason contributing to performance issues? as i understand this exit gets control before each SMF write. *** IEEMB860 Statistics *** ILRTMRLG 00:00:00.278 ASM IEEVMSI 00:00:00.065 Reconfiguration IARM8MSI 00:00:00.030 RSM - bring storage online IECVIOSI 00:00:02.627 IOS dynamic pathing RACROUTE 00:00:00.000 Initialize Security Environment ATBINSYS 00:00:00.020 APPC IKJEFXSR 00:00:00.183 TSO IXGBLF00 00:00:00.029 Logger AXRINSTR 00:00:00.042 System REXX CEAINSTR 00:00:00.031 Common Event Adapter HWIAMIN1 00:00:00.067 BCPii COMMNDXX 00:00:00.091 COMMANDxx processing IEAVTMSI 00:00:00.071 RTM SMFWAIT 00:00:53.586 SMF ICHSEC05 00:00:12.113 Security Server MSIEXIT 00:00:00.000 Cnz_MSIExit Dynamic Exit IEFJSIN2 00:00:03.188 SSN= subsystem IEFHB4I2 00:00:00.015 ALLOCAS - UCB scan CSRINIT 00:00:00.005 Windowing services FINSHMSI 00:00:00.336 Wait for attached CMDs IEEMB860 00:01:12.797 Uncaptured time: 00:00:00.011 Thanks and Regards Shameem K Shoukath -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Longer SMFWAIT during IPL MSI
We IPL with type 19's turned off, and then enable in Command after IPL. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Barry Sent: Monday, June 03, 2013 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Longer SMFWAIT during IPL MSI I remember having this issue years ago when using the old IPO SMFDUMP program. We forced a switch at midnight and dumped the last of the previous day's data on two loosely coupled systems. IIRC, the type 19s were produced by the IEFU29 exit under a global IPO1.SMF enqueue. The two dumps' time frames never matched because one had to wait a long time for the other to issue the l-space macro against every device in the system before proceeding. Record type 19 is written: 1. For each online device associated with a specific IPL time frame, 2. For each online device associated with a processed HALT EOD or SWITCH SMF command, and 3. When a direct access volume that is defined by DD statement is demounted. Therefore, the magnitude of the problem depends very much on the number of online devices and how fast their VTOCs can be read. Since our shop already had more modern DASD space reporting tools, we got rid of the problem by excluding type 19 in SMFPRMxx. db -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shameem .K .Shoukath Sent: Friday, May 31, 2013 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Longer SMFWAIT during IPL MSI Thanks Bob for sharing the REDBOOK details it is of good help to understand the process. We are recording 19 in all LPARs. I think storage team uses it for their reporting using 20% or something, im not sure. My actual question still stands when i compare PROD and DEV SMFPRMxx then only diff i see is the SMF EXIT IEFU84. Is this exit heavy by itself or by poor coding ? is this affecting performance POST IPL as this EXIT takes control before each SMF Write. I need to raise a CHANGE if i want to remove it and test. So I was expecting to get a feedback from the LIST whether it worth a try. I have to give some justification in the CHANGE to request the removal. Thanks and Regards Shameem K Shoukath From: Bob Rutledge deerh...@ix.netcom.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2013 8:55 PM Subject: Re: Longer SMFWAIT during IPL MSI I suggest this Redbook: http://publib-b.boulder.ibm.com/abstracts/sg247816.html?Open Bob Shameem .K .Shoukath wrote: hi there, I was just going thru the IPL statistics of all LPARs in out org. I see in one LPAR the SMFWAIT is taking fairly longer comp to others. out of total 00:01:12 MSI time this takes 00:00:53.586 I am not sure what happens in this process, took a chance compared the SMFPRMxx and saw there is one exit IEFU84 additional compared to PROD and QA lpars. would this be the cause for slower IPL ? Will it also may be one reason contributing to performance issues? as i understand this exit gets control before each SMF write. *** IEEMB860 Statistics *** ILRTMRLG 00:00:00.278 ASM IEEVMSI 00:00:00.065 Reconfiguration IARM8MSI 00:00:00.030 RSM - bring storage online IECVIOSI 00:00:02.627 IOS dynamic pathing RACROUTE 00:00:00.000 Initialize Security Environment ATBINSYS 00:00:00.020 APPC IKJEFXSR 00:00:00.183 TSO IXGBLF00 00:00:00.029 Logger AXRINSTR 00:00:00.042 System REXX CEAINSTR 00:00:00.031 Common Event Adapter HWIAMIN1 00:00:00.067 BCPii COMMNDXX 00:00:00.091 COMMANDxx processing IEAVTMSI 00:00:00.071 RTM SMFWAIT 00:00:53.586 SMF ICHSEC05 00:00:12.113 Security Server MSIEXIT 00:00:00.000 Cnz_MSIExit Dynamic Exit IEFJSIN2 00:00:03.188 SSN= subsystem IEFHB4I2 00:00:00.015 ALLOCAS - UCB scan CSRINIT 00:00:00.005 Windowing services FINSHMSI 00:00:00.336 Wait for attached CMDs IEEMB860 00:01:12.797 Uncaptured time: 00:00:00.011 Thanks and Regards Shameem K Shoukath -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: Local MCS Console Solutions
We use the HMC as the NIP console, but I can definitely see where some customers need a hard NIP console. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, June 03, 2013 5:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local MCS Console Solutions W dniu 2013-06-02 19:10, Don Williams pisze: Good points which is why I don't setup them up as NIP consoles and we only allow access inside our firewall. Well, the only reason I need hard consoles is NIP/IPL/shutdown process. Later (after IPL) I can use EMCS consoles (SDSF) or VTAM consoles if any. Of course YMMV. :-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526- 021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local MCS Console Solutions
On 6/3/2013 12:51 PM, Don Williams wrote: We use the HMC as the NIP console, but I can definitely see where some customers need a hard NIP console. A 3270 NIP console with no remote access would create a problem for an unattended shop like ours when there is a prompt that prevents IPL (e.g., initialize or join sysplex, which volume to stay offline, etc). The HMC can be controlled remotely, so that's what we use for NIP. If you have remote access to your 3270 NIP consoles, then either way is fine. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
It is enough to get Tier 0, 1, and some 2 going. Then wait for more dasd to be installed and raise the CPU limits when we need it. On Mon, Jun 3, 2013 at 9:35 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 31 May 2013 20:09:33 -0500, Mike Schwab wrote: We don't have enough DASD at the hot site for that. You don't have enough DASD at your hot site to run the business? Then what is it good for? -- Tom Marchant -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To recompile or not recompile, that's the question
Mark, Even had a LARGE customer argue we should rewrite our software in 24bit ...because he didn't understand 32 bit LE ,heaps and run options . Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Jun 3, 2013, at 10:50 AM, Mark Zelden m...@mzelden.com wrote: On Sat, 1 Jun 2013 23:58:34 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 985915eee6984740ae93f8495c624c6c2318055...@jscpcwexmaa1.bsg.ad.adp.com, on 05/31/2013 at 03:40 PM, Farley, Peter x23353 peter.far...@broadridge.com said: The problem with recompilation is not purely technical though. ISTM that there is far more bureaucracy needed to monitor and guarantee successful completion of full regression testing at each recompilation than there is payback from using notionally better translators and runtimes at a given stage. Yes, additional regression checking is expensive. However, how do you validate a new release or service level of the compiler without it? What do you do when you roll a new release of the compiler into production and discover six months later that you can't compile a module that you need to update? Sometimes pay now is less expensive than pay later. I supposed I could see a small shop, or a development shop / vendor that would do this. But I don't know that I've ever been in a production shop that did. There is no way it would ever happen in the larger ones I've been at. My current client must have a few hundred thousand COBOL programs (batch / CICS mostly) and the cost to test after compile even 10% of them would far far out weigh whatever cost of fixing a program or programs that had a problem 6 months down the line. In my experience, those have been few and far between anyway (although I admit I am not in the loop for many application issues). As far as validation, there is plenty of activity on a daily basis to point to a new compiler when we are ready to and then cut over to it being the default once everyone is comfortable. I have been at shops that did it one application system at a time to migrate from COBOL II to Enterprise V3, but that was the last time all programs were compiled and tested for any given application. No one wants to do that again! Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Citation for reformatting of VSAM, HFS and zFS data sets
I went through the z/OS 1.13 manuals on defining VSAM datasets, but even where the internal pointers were mentioned, it didn't say each CA and CI was written as empty when defined. Just explained what was there in each CI. On Mon, Jun 3, 2013 at 1:29 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: I am editing a wiki article on disk formatting and have been challenged to provide documentation of my claim that formatting a VSAM cluster, HFS or zFS rewrites existing data. I could cite dead tree documentation for VSAM in OS/VS2 R3.8, but I'd really prefer something recent enough to be available online, preferably current, and that wouldn't include the Unix file systems. I would appreciate it if someone could add appropriate citations to http://en.wikipedia.org/wiki/Disk_formatting or give me the links so that I can do so. Thanks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: New AFP related list started at UGA.EDU
On Mon, Jun 3, 2013 at 1:03 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In dc74548a025aff4a85f46926802a9b230a24c...@chsa1035.share.beluni.net, on 06/03/2013 at 12:17 PM, Hunkeler Peter (TLSG 4) peter.hunke...@credit-suisse.com said: I was more looking for something to help me avoid a heart attack when I cannot determine that hidden error in an AFP datastream. The last time that I had to work with AFP I wrote a REXX to format the AFP data stream. It was a lot more reliable than IEBIBALL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) I needed to take our logo and make an AFP image out of it. Went into Paint, saved it as a BMP, and wrote a word visual basic macro to read the BMP and write the AFP image file. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Citation for reformatting of VSAM, HFS and zFS data sets
Perhaps the citation looked for is: = SPEED|RECOVERY Specifies whether the data component's control areas are to be preformatted This parameter is only considered during the actual loading (creation) of a data set. Creation occurs when the data set is opened and the high-used RBA is equal to zero. After normal CLOSE processing at the completion of the load operation, the physical structure of the data set and the content of the data set extents are exactly the same, regardless of which option is used. Any processing of the data set after the successful load operation is the same, and the specification of this parameter is not considered. If you use RECOVERY, the initial load takes longer because the control areas are first written with either empty or software end-of-file control intervals. These preformatted control intervals are then updated, using update writes with the data records. When SPEED is used, the initial load is faster. SPEED Does not preformat the data component's space. If the initial load is unsuccessful, you must load the data set again from the beginning because VSAM cannot determine the location of your last correctly written record. VSAM cannot find a valid end-of-file indicator when it searches your data records. RECOVERY Does preformat the data component's space prior to writing the data records. If the initial load is unsuccessful, VSAM can determine the location of the last record written during the load process. = Don -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, June 03, 2013 6:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Citation for reformatting of VSAM, HFS and zFS data sets I went through the z/OS 1.13 manuals on defining VSAM datasets, but even where the internal pointers were mentioned, it didn't say each CA and CI was written as empty when defined. Just explained what was there in each CI. On Mon, Jun 3, 2013 at 1:29 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: I am editing a wiki article on disk formatting and have been challenged to provide documentation of my claim that formatting a VSAM cluster, HFS or zFS rewrites existing data. I could cite dead tree documentation for VSAM in OS/VS2 R3.8, but I'd really prefer something recent enough to be available online, preferably current, and that wouldn't include the Unix file systems. I would appreciate it if someone could add appropriate citations to http://en.wikipedia.org/wiki/Disk_formatting or give me the links so that I can do so. Thanks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
