Re: DS6800 and OS/390 2.9
W dniu 2011-09-13 23:37, Carlos Bodra - Pessoal pisze: Hello List Gurus. We are in process of migrate from an ancient IBM 2105-F20 with 1TB of legacy mainframe data to a IBM 1750-522 (DS6800). Both subsystems has volumes defined as 3390-3 and no software features (flashcopy, pprc etc..) used in Shark and will neither in DS6800. My question is, anyone has any experience with DS6800 running under a OS390 2.9? We should migrate to z/OS 1.8 soon and after to z/OS 1.12, but for some time, DS6800 will be running under OS390 control. No software features will be used at all. It will be used as 2105 is been used today. Any positive or negative comentary will be wellcome. I heard (only heard) about serious problems, when oold systems without PTFs were trying to use DS family dasd. I may apply OS/390 2.9 or not. I would set up DS6800 as 3990 CU (not 21xx) just to be more compatible. -- 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, 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.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GIMUNZIP GIM54701S error
hi Lim, my advise would be to add some TEMP datasets within the JCL... you can hardcode the Volser with a disp of Delete, Delete. this util allocates space from TEMP as defined in SMS and remove after the success.. thanks, Amit On Tue, Sep 13, 2011 at 5:59 AM, Lim Ming Liang limm...@unifi.my wrote: Hi Bill, Much obliged on the updates. Regards Lim ML On 13/09/11 1:24 AM, Bill Godfrey wrote: GIMUNZIP might be trying to allocate a Large Format sequential data set (DSNTYPE=LARGE) rather than a PDSE. I say that because at this web page: https://www-304.ibm.com/**support/docview.wss?uid=**isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 it says: GIMUNZIP has been updated to allocate SYSUT1 as a Large Format sequential data set. Large Format data sets, like PDSEs, cannot be on VIO. I suspect that the error code 0C060090 might apply to both PDSEs and Large Format data sets, even though the manual describing the error code only mentions PDSEs. But I am not certain of that. I don't know what unit name GIMUNZIP uses, if any, in this allocation, and I don't know if temporary data set allocations are being controlled by ACS routines on your system. If they are, the logic that allows VIO for temporary data sets might need to check forDSNTYPE equal to LARGE and not include VIO for such allocations. That's assuming this actually is a Large Format data set allocation. Bill On Sun, 11 Sep 2011 11:26:41 +0800, Lim Ming Lianglimm...@unifi.my wrote: Hi Bill, PDSE cannot be VIO , is it a DFSMSdfp software constraint ? GIMUNZIP is trying to allocate a PDSE on VIO for SYSUT1 , is it an software action taken by GIMUNZIP to dynamically allocate SYSUT1 with VIO ? Or is it my system setup for VIO allocation causing the problem ? Pardon me, I am still trying to digest those stuff you provided me. Thank you. Regards Lim ML On 11/09/11 1:46 AM, Bill Godfrey wrote: Google for 0C060090,which is in one of the messages. It will take you here: http://www.mail-archive.com/**ibm-main@bama.ua.edu/msg28790.**htmlhttp://www.mail-archive.com/ibm-main@bama.ua.edu/msg28790.html which shows an ibm-main post from 2006 that says: (quote) HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 For this code you need to look in the DFSMSdsp Diagnostic Reference. You will find that, for CREATE, 0C060090 means PDSE cannot be VIO. (end quote) This is confirmed here in the DFSMSdfp Diagnosis manual: http://publibz.boulder.ibm.**com/cgi-bin/bookmgr_OS390/** BOOKS/DGT2R190/6.9.1http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R190/6.9.1 So gimunzip is trying to allocate a PDSE on VIO for SYSUT1. Maybe that information will help solve the problem. Bill On Sun, 11 Sep 2011 00:47:39 +0800, Lim Ming Lianglimm...@unifi.my wrote: That description not really fit the problem I am having here. I googled and found an archived back in Feb did talked about this messages I am having, and the resolution is add volume parameter in the ARCHDEF. Yes, it did help to get the job going, but I wonder wh., All those extracted Data Sets are pre-allocated and cataloged, and why GIMUNZIP need the volume parameter to be specified ? Regards Lim ML On 10/09/11 9:37 PM, Bill Johnson wrote: Check this:https://www-304.ibm.com/**support/docview.wss?uid=** isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 On Sat, Sep 10, 2011 at 9:25 AM, Lim Ming Lianglimm...@unifi.my wrote: Hi, I run GIMUNZIP, --GIMUNZIP --ARCHDEF --archid=AAOPEXEC.100 --newname=TRX4.AOP.AAOPEXEC -- / and encountered error messages; ** ALLOCATION FAILED FOR SYSUT1 - IKJ56893I FILE SYSUT1 NOT ALLOCATED+. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SYS11253.T114250.RA000.** IBMUSERF.R0100060. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - RETURN CODE 12 REASON CODE 144. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE AAOPEXEC.100. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Is this something to do with SMS setup? Please help. -- Regards Lim ML --**--** -- For IBM-MAIN subscribe / signoff / archive
Re: SMS compressed VSAM datasets
Something is wrong with Ed's email that causes single quote (or apostrophes) to show as #39, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mingee, David Sent: Tuesday, September 13, 2011 7:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Ed, Not that I know of. BTW, what is #39,t mean? I see it frequently, is it encrypted cursing? hahaha David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, September 13, 2011 10:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets David, Correct me if I am wrong but doesn#39;t DFDSS invoke idcams under the covers? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GIMUNZIP GIM54701S error
I tried that with SYSUT1 ddname, but GIMUNZIP still dynamically allocate it. Regards Lim ML On 14/09/11 3:43 PM, amit wrote: hi Lim, my advise would be to add some TEMP datasets within the JCL... you can hardcode the Volser with a disp of Delete, Delete. this util allocates space from TEMP as defined in SMS and remove after the success.. thanks, Amit On Tue, Sep 13, 2011 at 5:59 AM, Lim Ming Lianglimm...@unifi.my wrote: Hi Bill, Much obliged on the updates. Regards Lim ML On 13/09/11 1:24 AM, Bill Godfrey wrote: GIMUNZIP might be trying to allocate a Large Format sequential data set (DSNTYPE=LARGE) rather than a PDSE. I say that because at this web page: https://www-304.ibm.com/**support/docview.wss?uid=**isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 it says: GIMUNZIP has been updated to allocate SYSUT1 as a Large Format sequential data set. Large Format data sets, like PDSEs, cannot be on VIO. I suspect that the error code 0C060090 might apply to both PDSEs and Large Format data sets, even though the manual describing the error code only mentions PDSEs. But I am not certain of that. I don't know what unit name GIMUNZIP uses, if any, in this allocation, and I don't know if temporary data set allocations are being controlled by ACS routines on your system. If they are, the logic that allows VIO for temporary data sets might need to check forDSNTYPE equal to LARGE and not include VIO for such allocations. That's assuming this actually is a Large Format data set allocation. Bill On Sun, 11 Sep 2011 11:26:41 +0800, Lim Ming Lianglimm...@unifi.my wrote: Hi Bill, PDSE cannot be VIO , is it a DFSMSdfp software constraint ? GIMUNZIP is trying to allocate a PDSE on VIO for SYSUT1 , is it an software action taken by GIMUNZIP to dynamically allocate SYSUT1 with VIO ? Or is it my system setup for VIO allocation causing the problem ? Pardon me, I am still trying to digest those stuff you provided me. Thank you. Regards Lim ML On 11/09/11 1:46 AM, Bill Godfrey wrote: Google for 0C060090,which is in one of the messages. It will take you here: http://www.mail-archive.com/**ibm-main@bama.ua.edu/msg28790.**htmlhttp://www.mail-archive.com/ibm-main@bama.ua.edu/msg28790.html which shows an ibm-main post from 2006 that says: (quote) HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 For this code you need to look in the DFSMSdsp Diagnostic Reference. You will find that, for CREATE, 0C060090 means PDSE cannot be VIO. (end quote) This is confirmed here in the DFSMSdfp Diagnosis manual: http://publibz.boulder.ibm.**com/cgi-bin/bookmgr_OS390/** BOOKS/DGT2R190/6.9.1http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R190/6.9.1 So gimunzip is trying to allocate a PDSE on VIO for SYSUT1. Maybe that information will help solve the problem. Bill On Sun, 11 Sep 2011 00:47:39 +0800, Lim Ming Lianglimm...@unifi.my wrote: That description not really fit the problem I am having here. I googled and found an archived back in Feb did talked about this messages I am having, and the resolution is add volume parameter in the ARCHDEF. Yes, it did help to get the job going, but I wonder wh., All those extracted Data Sets are pre-allocated and cataloged, and why GIMUNZIP need the volume parameter to be specified ? Regards Lim ML On 10/09/11 9:37 PM, Bill Johnson wrote: Check this:https://www-304.ibm.com/**support/docview.wss?uid=** isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 On Sat, Sep 10, 2011 at 9:25 AM, Lim Ming Lianglimm...@unifi.my wrote: Hi, I run GIMUNZIP, --GIMUNZIP --ARCHDEF --archid=AAOPEXEC.100 --newname=TRX4.AOP.AAOPEXEC -- / and encountered error messages; ** ALLOCATION FAILED FOR SYSUT1 - IKJ56893I FILE SYSUT1 NOT ALLOCATED+. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SYS11253.T114250.RA000.** IBMUSERF.R0100060. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - RETURN CODE 12 REASON CODE 144. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE AAOPEXEC.100. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Is this something to do with SMS setup? Please help. -- Regards Lim ML --**--**
Re: GIMUNZIP GIM54701S error
can you try directing it to tape instead of DASD, specifically mention ur TAPE psuedos...it wd take a lot of IO, but end of the day it would help you achieve success. On Wed, Sep 14, 2011 at 3:01 PM, Lim Ming Liang limm...@unifi.my wrote: I tried that with SYSUT1 ddname, but GIMUNZIP still dynamically allocate it. Regards Lim ML On 14/09/11 3:43 PM, amit wrote: hi Lim, my advise would be to add some TEMP datasets within the JCL... you can hardcode the Volser with a disp of Delete, Delete. this util allocates space from TEMP as defined in SMS and remove after the success.. thanks, Amit On Tue, Sep 13, 2011 at 5:59 AM, Lim Ming Lianglimm...@unifi.my wrote: Hi Bill, Much obliged on the updates. Regards Lim ML On 13/09/11 1:24 AM, Bill Godfrey wrote: GIMUNZIP might be trying to allocate a Large Format sequential data set (DSNTYPE=LARGE) rather than a PDSE. I say that because at this web page: https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377https://www-304.ibm.com/**support/docview.wss?uid=**isg1IO10377 https://www-304.**ibm.com/support/docview.wss?**uid=isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 it says: GIMUNZIP has been updated to allocate SYSUT1 as a Large Format sequential data set. Large Format data sets, like PDSEs, cannot be on VIO. I suspect that the error code 0C060090 might apply to both PDSEs and Large Format data sets, even though the manual describing the error code only mentions PDSEs. But I am not certain of that. I don't know what unit name GIMUNZIP uses, if any, in this allocation, and I don't know if temporary data set allocations are being controlled by ACS routines on your system. If they are, the logic that allows VIO for temporary data sets might need to check forDSNTYPE equal to LARGE and not include VIO for such allocations. That's assuming this actually is a Large Format data set allocation. Bill On Sun, 11 Sep 2011 11:26:41 +0800, Lim Ming Lianglimm...@unifi.my wrote: Hi Bill, PDSE cannot be VIO , is it a DFSMSdfp software constraint ? GIMUNZIP is trying to allocate a PDSE on VIO for SYSUT1 , is it an software action taken by GIMUNZIP to dynamically allocate SYSUT1 with VIO ? Or is it my system setup for VIO allocation causing the problem ? Pardon me, I am still trying to digest those stuff you provided me. Thank you. Regards Lim ML On 11/09/11 1:46 AM, Bill Godfrey wrote: Google for 0C060090,which is in one of the messages. It will take you here: http://www.mail-archive.com/ibm-main@bama.ua.edu/msg28790.** **htmlhttp://www.mail-archive.com/**ibm-main@bama.ua.edu/msg28790.**html http://www.mail-**archive.com/ibm-m...@bama.ua.**edu/msg28790.htmlhttp://www.mail-archive.com/ibm-main@bama.ua.edu/msg28790.html which shows an ibm-main post from 2006 that says: (quote) HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 For this code you need to look in the DFSMSdsp Diagnostic Reference. You will find that, for CREATE, 0C060090 means PDSE cannot be VIO. (end quote) This is confirmed here in the DFSMSdfp Diagnosis manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/** BOOKS/DGT2R190/6.9.1http://**publibz.boulder.ibm.com/cgi-** bin/bookmgr_OS390/BOOKS/**DGT2R190/6.9.1http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R190/6.9.1 So gimunzip is trying to allocate a PDSE on VIO for SYSUT1. Maybe that information will help solve the problem. Bill On Sun, 11 Sep 2011 00:47:39 +0800, Lim Ming Lianglimm...@unifi.my wrote: That description not really fit the problem I am having here. I googled and found an archived back in Feb did talked about this messages I am having, and the resolution is add volume parameter in the ARCHDEF. Yes, it did help to get the job going, but I wonder wh., All those extracted Data Sets are pre-allocated and cataloged, and why GIMUNZIP need the volume parameter to be specified ? Regards Lim ML On 10/09/11 9:37 PM, Bill Johnson wrote: Check this:https://www-304.ibm.com/support/docview.wss?uid=**https://www-304.ibm.com/**support/docview.wss?uid=** isg1IO10377https://www-304.**ibm.com/support/docview.wss?** uid=isg1IO10377https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377 On Sat, Sep 10, 2011 at 9:25 AM, Lim Ming Lianglimm...@unifi.my wrote: Hi, I run GIMUNZIP, --GIMUNZIP --ARCHDEF --archid=AAOPEXEC.100 --newname=TRX4.AOP.AAOPEXEC -- / and encountered error messages; ** ALLOCATION FAILED FOR SYSUT1 - IKJ56893I FILE SYSUT1 NOT ALLOCATED+. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - SYS11253.T114250.RA000.** IBMUSERF.R0100060. GIM54701S ** ALLOCATION FAILED FOR SYSUT1 - HISTORIC RETURN CODE IS 196 DIAGNOSTIC
Re: IBM-MAIN Digest - 12 Sep 2011 to 13 Sep 2011 (#2011-256)
BTW, what is #39,t mean? I see it frequently, is it encrypted cursing? Hahaha No, it's an attempt by smart mail user agents to insert a fancy apostrophe character instead of using the single quote. The 39 is the hex character code for the apostrophe. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
I guess my first thought / question would be to identify where the bottleneck for the backups is; disk I/O, tape I/O, or CPU? Presumably disk I/O didn't change a whole lot for reading the data or you would have seen impacts elsewhere too. My guess would be similar for the CPU. However, if either is true, it's possible it's simply more noticable during backups than your normal processing. But my guess would be it's writing to the tape. You didn't mention what kind of tape subsystem you're writing to, but everything has it's throughput limit and possibly by pushing more data (uncompressed) down the channel, you've hit the throughput limit of the subsystem. If you're going down ESCON channels to the tape, those aren't terribly fast by modern standards, and more data on the channel = slower elapsed time. I discovered a similar situation for our DB2 log archives earlier this year, but the interesting part was that I didn't initially recognize we were hitting the throughput limit because the data is compressed in the logs and the quoted throughput limits seem to assume you're sending uncompressed data to the subsystem. Of course you now are sending uncompressed data to the subsystem, but likely the tape subsystem compression ratio is different than what you get on disk from either SMS or BMC. As I was looking at this I also discovered that for my test jobs there was no significant difference between using 24K and 256K blocks. YMMV. If you're so interested, I wrote up that experience for one of my What I Learned This Month columns for MeasureIT: http://www.cmg.org/measureit/issues/mit80/m_80_5.pdf Scott Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IOCP RESOURCE coding help needed
Hi Mike You might have already checked but I thought it maybe usefull to mention: I have used IOCP books when I had to do troubleshooting in standalone IOCP,it was on 9672 machines, but I have found it usefull on that time.These are latest version on ibm resourcelink website. * For coding , Check System zInput/Output Configuration Program User's Guide for ICP IOCP SB10-7037-09. * For standalone IOCP process using HMC-single object operations or SE,check System z Stand-Alone Input/Output Configuration Program User's Guide SB10-7152-05. * In addition to these books,there is one redbook `I/O Configuration Using z/OS HCD and HCM` that contains example of IOCP statements using multiple CSS (chapter 7 for configuration,Apendix A for IOCP dataset itself). http://www.redbooks.ibm.com/abstracts/sg247804.html?Openpdfbookmark Best Regards Meral -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Myers Sent: Monday, September 12, 2011 9:11 PM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] IOCP RESOURCE coding help needed I am trying to code the correct IOCP RESOURCE statement to make all 4 CSSs available to the same 2 LPARs on a z9. I have managed to successfully get both LPARs to share CSS(0), but have not been able to find an acceptable way to get the stand-alone IOCP to let me define the others (CSS 1,2 and 3) for the same two LPARS. Can anyone help with this? Is must be doable Mike Myers Mentor Services Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This message and attachments are confidential and intended solely for the individual(s) stated in this message. If you received this message although you are not the addressee, you are responsible to keep the message confidential. The sender has no responsibility for the accuracy or correctness of the information in the message and its attachments. Our company shall have no liability for any changes or late receiving, loss of integrity and confidentiality, viruses and any damages caused in anyway to your computer system. Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir zarardan sorumlu tutulamaz. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and OS/390 2.9
On 9/13/2011 5:38 PM, Carlos Bodra - Pessoal wrote: Hello List Gurus. We are in process of migrate from an ancient IBM 2105-F20 with 1TB of legacy mainframe data to a IBM 1750-522 (DS6800). Both subsystems has volumes defined as 3390-3 and no software features (flashcopy, pprc etc..) used in Shark and will neither in DS6800. My question is, anyone has any experience with DS6800 running under a OS390 2.9? We should migrate to z/OS 1.8 soon and after to z/OS 1.12, but for some time, DS6800 will be running under OS390 control. No software features will be used at all. It will be used as 2105 is been used today. Any positive or negative comentary will be wellcome. Thanks Carlos Bodra Carlos, According to the DS6800 Interoperability matrix, the lowest level operating system supported by the device is z/OS V1R4. It's unlikely that OS/390 V2R9 has the appropriate device support for the DS6800. I would recommend that you hook the DS6800 up to your new CEC where you're installing z/OS V1R8, and cable the 2105 to the new CEC as well, and then migrate the data after you've completed the z/OS upgrade. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GIMUNZIP GIM54701S error
added volume parameter in the ARCHDEF, resolved the issue. I think I can close this thread. Thank you all. Regards Lim ML On 14/09/11 5:47 PM, amit wrote: add volume parameter in the ARCHDEF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
Thanks for your opinion. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, September 13, 2011 2:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge In 08ef7d7816b3b642a380513303a2d77b225c4...@alvmbxw02.prod.quest.corp, on 09/13/2011 at 07:17 PM, David Booher david.boo...@quest.com said: I posted this to DB2-L, but no takers :) Perhaps because it was a bad idea. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. Why? Foot, gun; gun, foot. -- 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...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GIMUNZIP GIM54701S error
advise would be to add some TEMP datasets within the JCL... you can hardcode the Volser with a disp of Delete, Delete. this util allocates space from TEMP as defined in SMS and remove after the success.. If you're in an SMS world, why hard code a volser? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IOCP RESOURCE coding help needed
Meral: Thanks. Yes, I have been reading the manuals. I have not found an example that shows what I want to do and no explanation in them that what I am trying to do is not legit. Mike On 09/14/2011 07:43 AM, Meral Temel (Garanti Teknoloji) wrote: Hi Mike You might have already checked but I thought it maybe usefull to mention: I have used IOCP books when I had to do troubleshooting in standalone IOCP,it was on 9672 machines, but I have found it usefull on that time.These are latest version on ibm resourcelink website. * For coding , Check System zInput/Output Configuration Program User's Guide for ICP IOCP SB10-7037-09. * For standalone IOCP process using HMC-single object operations or SE,check System z Stand-Alone Input/Output Configuration Program User's Guide SB10-7152-05. * In addition to these books,there is one redbook `I/O Configuration Using z/OS HCD and HCM` that contains example of IOCP statements using multiple CSS (chapter 7 for configuration,Apendix A for IOCP dataset itself). http://www.redbooks.ibm.com/abstracts/sg247804.html?Openpdfbookmark Best Regards Meral -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Myers Sent: Monday, September 12, 2011 9:11 PM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] IOCP RESOURCE coding help needed I am trying to code the correct IOCP RESOURCE statement to make all 4 CSSs available to the same 2 LPARs on a z9. I have managed to successfully get both LPARs to share CSS(0), but have not been able to find an acceptable way to get the stand-alone IOCP to let me define the others (CSS 1,2 and 3) for the same two LPARS. Can anyone help with this? Is must be doable Mike Myers Mentor Services Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This message and attachments are confidential and intended solely for the individual(s) stated in this message. If you received this message although you are not the addressee, you are responsible to keep the message confidential. The sender has no responsibility for the accuracy or correctness of the information in the message and its attachments. Our company shall have no liability for any changes or late receiving, loss of integrity and confidentiality, viruses and any damages caused in anyway to your computer system. Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir zarardan sorumlu tutulamaz. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Thanks. Yes, I see those entries. Messing around with the CISIZE is a bit iffy because I am not the primary responsibly person for these files. I cannot change them without permission. But I'm tasking with converting the in sitsu because programming just doesn't have the time necessary to be bothered with it. The reason for conversion is financial, not technical. And chaning from Faver to ADRDSSU is no go because that is a change which would require going through change control for each and every file. And require rearchitecting some jobs. We use Faver for a lot of functions, including making shadow copies of files. Data Accelerator is a great product. But we, like many, are struggling to stay alive. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mingee, David Sent: Tuesday, September 13, 2011 9:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Hi John, Do the VSAM files show COMP-FORMT and USER-DATA-SIZE--9636537000 COMP-USER-DATA-SIZE-2831001090 in the listcat(s)? This verifies the SMS compression is on. Also, you could try SMS utility ADRDSSU for backup speed. Lastly, if SMS compress is on, I suggest defining the vsam cisize as 26624 as this is the most efficient for i/o and disk space and I have never seen this have a negative impact on CICS. David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Wednesday, September 14, 2011 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets 1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
From 3 output tapes to 12? What kind of tape drives are you using? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 8:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Wednesday, September 14, 2011 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets 1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
You could point SDSNEXIT to a library you don't use for anything. SMP would still assemble and link DSNZPARM, but you wouldn't use the output module. In our case, I always delete the SMP step from DSNTIJUZ. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Tuesday, September 13, 2011 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Question for SMP/E gurus with DB2 knowledge I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
They are virtual 3490s in a 3494 VTS from IBM. To anticipate some likely questions. They are SMS managed. The DATACLAS assigned to all virtual 3490s has COMPACTION=YES specified in it. The messages indicate that they are compressed. Eg: IEC705I TAPE ON 0601,205917,SL,COMP,PPRI100D,PS060.JS010,PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00,MEDIA2 before conversion IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 305 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2883V00,VOLS=264066,264094,266057, TOTALBLOCKS=270716 /before after conversion IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 301 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00, VOLS=205917,272723,217801,270266,207012,211973,274660,216448, VOLS=227706,213369,206060,TOTALBLOCKS=3326908 /after The conversion job does a Faver backup, followed by an IDCAMS EXPORT. The stats: IEC205I FVROUT0,EXP00152,FAVER,FILESEQ=1, COMPLETE VOLUME LIST, 835 DSN=GVBPN.PRIPV.PR.GCRLCHKS,VOLS=265418,292061,265898, TOTALBLOCKS=270620 IEC205I OUTFILE,EXP00152,EXPORT,FILESEQ=1, COMPLETE VOLUME LIST, 655 DSN=EXPPN.PRIPV.PR.GCRLCHKS, VOLS=230343,230359,266156,252995,230627,267258,233365,267150, VOLS=267698,229245,277722,TOTALBLOCKS=2058408 -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Wednesday, September 14, 2011 8:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets From 3 output tapes to 12? What kind of tape drives are you using? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 8:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Wednesday, September 14, 2011 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets 1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a
Re: Question for SMP/E gurus with DB2 knowledge
Yes, on my new DB2 installs, I simply omit the step from DSNTIJUZ, but once it's run, the damage is done. You pin-pointed my problem on older systems, the APPLY CHECK works fine, but when you actually run the APPLY, it can fail because of a reference to an obsolete SDSNEXIT library. Your suggestion is worth a try. Unfortunately, once the damage is done to SMP, it's hard to reverse it. Thanks, Dave -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Clark, Stan [GCG-PFS] Sent: Wednesday, September 14, 2011 9:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge You could point SDSNEXIT to a library you don't use for anything. SMP would still assemble and link DSNZPARM, but you wouldn't use the output module. In our case, I always delete the SMP step from DSNTIJUZ. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Tuesday, September 13, 2011 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Question for SMP/E gurus with DB2 knowledge I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Suppress command output from SYSLOG
On Thu, 1 Sep 2011 11:24:04 +0300, A.Watthey a.watt...@gmail.com wrote: Sebastian, You should subscribe to the proper netview list where there is far more expertise than here (netv...@yahoogroups.com). However, what you need to do is check out the DEFAULTS SLOGCMDR value. You need either NO or ECHOONLY. Also, don't forget that you must have the SSI address space running as he's the one that actually implements this feature. However, you can still use MVSPARM.MSGIFAC=SYSTEM if you so desire. Regards, Alan. Many thanks to all that replied to me, on and off-list. Using MPF exits, etc. would have far too complex although I had started to look that way. The above method is perfect (so far!) in that all commands that are executed by the NetView user which would normally also show in the SYSLOG are now suppressed from the SYSLOG (using ECHOONLY is nice as it does show what command was executed) but are still processed by NetView. Users who enter commands from NetView will also not see them in the SYSLOG but will have them echoed back to their NetView session and will also go in the NETLOG. So far no ill effects have been noticed and this looks like being the answer to not filling up our SYSLOG with redundant command output. Once again, many thanks. Sebastian. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
Caveat: Moved on to other products, so it's been a few years since I was a db2 sysprog so I may just being dense. It isn't clear what damage you're trying to reverse, or perhaps I don't understand what obsolete means in this context. Why would the SMP/E defined SDNSEXIT dsn be classified on an APPLLY as missing or obsolete in your current CSI? If you ran step DSNTIMQ and it found a DSN to put the member in, why is it obsolete? tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Wednesday, September 14, 2011 10:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge Yes, on my new DB2 installs, I simply omit the step from DSNTIJUZ, but once it's run, the damage is done. You pin-pointed my problem on older systems, the APPLY CHECK works fine, but when you actually run the APPLY, it can fail because of a reference to an obsolete SDSNEXIT library. Your suggestion is worth a try. Unfortunately, once the damage is done to SMP, it's hard to reverse it. Thanks, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
In case you do want more information, searching the complete z/OS V1.12 library for sys1.imagelib finds hits in 27 documents. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZBK0K?searchRequest=sys1.imagelibSEARCH=SearchType=FUZZYSearchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANK -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
In 1315958086.61838.yahoomailmob...@web161421.mail.bf1.yahoo.com, on 09/13/2011 at 04:54 PM, Ed Gould ps2...@yahoo.com said: The 3800 printers essentially obsoleted all printers. No. 1. It was too expensive. 2. Some sites required impact printers for multi-part forms. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
In 0de6a9840123e547b061ac5b6765c02610f...@exmb-05.ad.wsu.edu, on 09/14/2011 at 08:06 AM, Gibney, Dave gib...@wsu.edu said: Something is wrong with Ed's email that causes single quote (or apostrophes) to show as #39, Code points 96, 131, 145 and 146 are also single quotes. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
In 20b9d8db9552d44981f6ebb3d26f579524a...@lm-hsexmsg-p06p.lm.lmig.com, on 09/14/2011 at 02:51 AM, Mingee, David david.min...@libertymutual.com said: Ed, Not that I know of. BTW, what is #39,t mean? It's a character entity, and should only be used in HTML, SGML and XML. The decimal number following the # is the ISO 8859-1 code point; in this case, 39 for apostrophe. His e-mail client is broken, which is not unusual these days. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Invalid PDS member names
In 4e6fc2e1.9080...@neo.tamu.edu, on 09/13/2011 at 03:53 PM, Richard L Peurifoy r-peuri...@neo.tamu.edu said: This was supposed to go to the ISPF-L list. Why? The issue is far from limited to ISPF. In fact, your reply listed some of the other areas. IMHO this list is the proper venue. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
In 20110913223925.DXFKW.7837.root@hrndva-web03-z01, on 09/13/2011 at 10:39 PM, Eric Bielefeld eric-ibmm...@wi.rr.com said: I suspect there aren't a lot of the printers such as 1403 and 3203 printers left anymore either. I'd be surprised to see many of those running, but there are probably 4248 and 6262 printers still around. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
We also use Faver and it is a handy tool to have especially for reorgs and point in time backups. Most of our backups go to a TMM disk pool so we bypass tape initially but eventually, some of the backups end up on tape during migration. I have occasionally wondered if using HSM functionality would be a viable alternative to Faver, esp. if you can use FRBACKUP. I supposed the reorgs wouldn't work because the files would be restored to the same condition they were when they were backed up. I haven't thought it all the way through but was wondering if you had given it any thought given the fact that you are going to a VTS so tape really never gets involved. I'm sure there are some +s and -s, just wondered if it might be worth taking a look at. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 9:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets They are virtual 3490s in a 3494 VTS from IBM. To anticipate some likely questions. They are SMS managed. The DATACLAS assigned to all virtual 3490s has COMPACTION=YES specified in it. The messages indicate that they are compressed. Eg: IEC705I TAPE ON 0601,205917,SL,COMP,PPRI100D,PS060.JS010,PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00,MEDIA2 before conversion IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 305 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2883V00,VOLS=264066,264094,266057, TOTALBLOCKS=270716 /before after conversion IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 301 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00, VOLS=205917,272723,217801,270266,207012,211973,274660,216448, VOLS=227706,213369,206060,TOTALBLOCKS=3326908 /after The conversion job does a Faver backup, followed by an IDCAMS EXPORT. The stats: IEC205I FVROUT0,EXP00152,FAVER,FILESEQ=1, COMPLETE VOLUME LIST, 835 DSN=GVBPN.PRIPV.PR.GCRLCHKS,VOLS=265418,292061,265898, TOTALBLOCKS=270620 IEC205I OUTFILE,EXP00152,EXPORT,FILESEQ=1, COMPLETE VOLUME LIST, 655 DSN=EXPPN.PRIPV.PR.GCRLCHKS, VOLS=230343,230359,266156,252995,230627,267258,233365,267150, VOLS=267698,229245,277722,TOTALBLOCKS=2058408 -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Wednesday, September 14, 2011 8:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets From 3 output tapes to 12? What kind of tape drives are you using? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 8:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message-
Re: SMS compressed VSAM datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, September 14, 2011 6:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets In 20b9d8db9552d44981f6ebb3d26f579524a...@lm-hsexmsg-p06p.lm.lmig.com, on 09/14/2011 at 02:51 AM, Mingee, David david.min...@libertymutual.com said: Ed, Not that I know of. BTW, what is #39,t mean? It's a character entity, and should only be used in HTML, SGML and XML. The decimal number following the # is the ISO 8859-1 code point; in this case, 39 for apostrophe. His e-mail client is broken, which is not unusual these days. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Well, according to our LAN people, Windows is the only true standard. Therefore whatever MS software does is, by that fact alone, the only true standard. Therefore everything which acts differently is, by definition, broken. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Suppress command output from SYSLOG
Sebastian, One item that you may want to consider. Display commands might be fine for something like this, but consider commands that do something like z rod or confit etc. These commands IMO should be logged so you can have accountability. Auditors should be asking about items like this. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
On Wed, 14 Sep 2011 08:18:12 -0500, McKown, John wrote: Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug There are 2 new export parameters in the current (latest) Faver version 4.5.0: SAVECOMP and OPTIMIZE. From the manual: The SAVECOMP parameter directs CA FAVER to export compressed format KSDS files in their native compressed format. The OPTIMIZE parameter is used in conjunction with the SAVECOMP parameter to control the number of tracks read at one time by DFSMSdss when processing hardware compressed files. OPTIMIZE is valid only if SAVECOMP is also specified. If specified, OPTIMIZE must immediately follow the SAVECOMP parameter. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Invalid PDS member names
On 9/14/2011 11:41 AM, Shmuel Metz , Seymour J. wrote: In4e6fc2e1.9080...@neo.tamu.edu, on 09/13/2011 at 03:53 PM, Richard L Peurifoyr-peuri...@neo.tamu.edu said: This was supposed to go to the ISPF-L list. Why? The issue is far from limited to ISPF. In fact, your reply listed some of the other areas. IMHO this list is the proper venue. I agree that it applies here, but the thread I was responding to was on ISPF-L. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Thanks. My boss is working with CA support right now with this new release. We just got it in this morning. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Norbert Friemel Sent: Wednesday, September 14, 2011 11:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets On Wed, 14 Sep 2011 08:18:12 -0500, McKown, John wrote: Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug There are 2 new export parameters in the current (latest) Faver version 4.5.0: SAVECOMP and OPTIMIZE. From the manual: The SAVECOMP parameter directs CA FAVER to export compressed format KSDS files in their native compressed format. The OPTIMIZE parameter is used in conjunction with the SAVECOMP parameter to control the number of tracks read at one time by DFSMSdss when processing hardware compressed files. OPTIMIZE is valid only if SAVECOMP is also specified. If specified, OPTIMIZE must immediately follow the SAVECOMP parameter. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
In a6b9336cdb62bb46b9f8708e686a7ea00afc0ed...@nrhmms8p02.uicnrh.dom, on 09/14/2011 at 08:08 AM, McKown, John john.mck...@healthmarkets.com said: And chaning from Faver to ADRDSSU is no go because that is a change which would require going through change control for each and every file. I take it that the decision to drop Faver did not go through change control and the cost analysis did not include the cost of the migration? -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
Yes there were follow on printers. I suspect there are very few real need for carbon copies anymore. I suppose, but I suspect that the number has decreased because with electronic copies the need is mute except for cash register and the odd type are needed. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
I have no idea what the issue is. The email you sent back to me does not contain the characters you indicated. A friend suggested it#39;s a ISP issue. I will try using m other client and see if the issue follows. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
In a6b9336cdb62bb46b9f8708e686a7ea00afc0ed...@nrhmms8p02.uicnrh.dom, on 09/14/2011 at 11:45 AM, McKown, John john.mck...@healthmarkets.com said: Well, according to our LAN people, Windows is the only true standard. Which windoze? M$ introduces incompatabilities with every release. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
We aren't dropping Faver. We are dropping Data Accelerator. It did go through change control. But nobody knew the effect it would have. I made sure that the converted datasets were still fully and compatibly accessible. They are. But apparently nobody monitored the effect on test or Model Office other than no abends. I am a sysprog. I am not a business analyst or knowledgeable about individual systems. I tested the datasets on DASD and had no problems. I was not given the time to do extensive testing of backups. This is now a highly critical project because we (IT) dragged our heels on it because nobody wanted to be bothered with it. It wasn't something that would acrue points, only pain. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, September 14, 2011 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets In a6b9336cdb62bb46b9f8708e686a7ea00afc0ed...@nrhmms8p02.uicnrh.dom, on 09/14/2011 at 08:08 AM, McKown, John john.mck...@healthmarkets.com said: And chaning from Faver to ADRDSSU is no go because that is a change which would require going through change control for each and every file. I take it that the decision to drop Faver did not go through change control and the cost analysis did not include the cost of the migration? -- 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...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
You will let us know if it works, right? :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 11:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Thanks. My boss is working with CA support right now with this new release. We just got it in this morning. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Norbert Friemel Sent: Wednesday, September 14, 2011 11:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets On Wed, 14 Sep 2011 08:18:12 -0500, McKown, John wrote: Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug There are 2 new export parameters in the current (latest) Faver version 4.5.0: SAVECOMP and OPTIMIZE. From the manual: The SAVECOMP parameter directs CA FAVER to export compressed format KSDS files in their native compressed format. The OPTIMIZE parameter is used in conjunction with the SAVECOMP parameter to control the number of tracks read at one time by DFSMSdss when processing hardware compressed files. OPTIMIZE is valid only if SAVECOMP is also specified. If specified, OPTIMIZE must immediately follow the SAVECOMP parameter. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Yes, I'll update the list one way or another. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Wednesday, September 14, 2011 1:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets You will let us know if it works, right? :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 11:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Thanks. My boss is working with CA support right now with this new release. We just got it in this morning. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Norbert Friemel Sent: Wednesday, September 14, 2011 11:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets On Wed, 14 Sep 2011 08:18:12 -0500, McKown, John wrote: Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug There are 2 new export parameters in the current (latest) Faver version 4.5.0: SAVECOMP and OPTIMIZE. From the manual: The SAVECOMP parameter directs CA FAVER to export compressed format KSDS files in their native compressed format. The OPTIMIZE parameter is used in conjunction with the SAVECOMP parameter to control the number of tracks read at one time by DFSMSdss when processing hardware compressed files. OPTIMIZE is valid only if SAVECOMP is also specified. If specified, OPTIMIZE must immediately follow the SAVECOMP parameter. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please
Mainframe article
The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
re: The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/; No, this can't be right, obviously whoever wrote this article is not reading enough airline magazines. Bobbie Justice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
I notice they claim only 4,000 Mainframe shops in the world. I thought the number was closer to 10,000. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bobbie Justice Sent: Wednesday, September 14, 2011 2:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Mainframe article re: The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/; No, this can't be right, obviously whoever wrote this article is not reading enough airline magazines. Bobbie Justice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
it#39;s
Hi Ed, you are saying you see no 39 in either this subject line and in the quoted note below. Then your client is doubly broken :) Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, September 14, 2011 10:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets I have no idea what the issue is. The email you sent back to me does not contain the characters you indicated. A friend suggested it#39;s a ISP issue. I will try using m other client and see if the issue follows. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
On 14 September 2011 14:49, Ken Porowski ken.porow...@cit.com wrote: I notice they claim only 4,000 Mainframe shops in the world. I thought the number was closer to 10,000. I have no idea, but I still have my VM Soars with 20,000 licenses poster from IBM. That was from the 1990s, IIRC. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Mr Timothy Prickett Morgan is not and never has been a great fan of mainframes. If you have ever read his comments, he always comes across as being anti-M/F and to some extent anti-IBM. As to the number of M/F sites in the world today? Where did he get this number from? As Bobbie Justice said, he probably doesn't read enough airline magazines! The number is much closer to 6,000, although no one knows for certain, not even IBM. The number of individual systems installed is obviously far greater than that. TPM's resume shows that he has very little background in M/F matters - except writing magazine articles, but mainly about mid-range systems. And as to any experience of working with M/Fs... in the words of the (in)famous Phil Payne, nuff said. ALH -Original Message- From: Ken Porowski ken.porow...@cit.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Wed, Sep 14, 2011 7:49 pm Subject: Re: Mainframe article I notice they claim only 4,000 Mainframe shops in the world. I thought he number was closer to 10,000. -Original Message- rom: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On ehalf Of Bobbie Justice ent: Wednesday, September 14, 2011 2:43 PM o: IBM-MAIN@bama.ua.edu ubject: Re: [IBM-MAIN] Mainframe article re: The Register has another mainframe related article which points out he rising importance of the mainframe and its growth in recent years. ttp://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/ No, this can't be right, obviously whoever wrote this article is not eading enough airline magazines. Bobbie Justice -- or IBM-MAIN subscribe / signoff / archive access instructions, send mail to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search he archives at http://bama.ua.edu/archives/ibm-main.html -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO earch the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: it's
It is not just Ed's mail client that doesn't show the HTML numeric character reference (NCR) that others see. If I look at your message using the web interface (whose address is at the end of all messages), the NCR appears in the subject in the list of messages for September, but when I look at the individual message, the subject shows with an apostrophe instead. Also, if I have hovering descriptions turned on in the Listserv preferences (this requires Javascript), when the mouse is over the subject in the September messages, the text in the desciption box shows an apostrophe instead of the NCR in both the subject and the text body. more about NCRs here: http://en.wikipedia.org/wiki/Numeric_character_reference Bill On Wed, 14 Sep 2011 18:59:55 +, Gibney, Dave gib...@wsu.edu wrote: Hi Ed, you are saying you see no 39 in either this subject line and in the quoted note below. Then your client is doubly broken :) Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, September 14, 2011 10:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets I have no idea what the issue is. The email you sent back to me does not contain the characters you indicated. A friend suggested it#39;s a ISP issue. I will try using m other client and see if the issue follows. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: it's
I sent my previous message using the Listserv web interface, and I see it replaced the NCR in the subject with an apostrophe. I didn't tell it to do that - it did it automatically. On Wed, 14 Sep 2011 14:40:10 -0500, Bill Godfrey yak36...@yahoo.com wrote: It is not just Ed's mail client that doesn't show the HTML numeric character reference (NCR) that others see. If I look at your message using the web interface (whose address is at the end of all messages), the NCR appears in the subject in the list of messages for September, but when I look at the individual message, the subject shows with an apostrophe instead. Also, if I have hovering descriptions turned on in the Listserv preferences (this requires Javascript), when the mouse is over the subject in the September messages, the text in the desciption box shows an apostrophe instead of the NCR in both the subject and the text body. more about NCRs here: http://en.wikipedia.org/wiki/Numeric_character_reference Bill On Wed, 14 Sep 2011 18:59:55 +, Gibney, Dave gib...@wsu.edu wrote: Hi Ed, you are saying you see no 39 in either this subject line and in the quoted note below. Then your client is doubly broken :) Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, September 14, 2011 10:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets I have no idea what the issue is. The email you sent back to me does not contain the characters you indicated. A friend suggested it#39;s a ISP issue. I will try using m other client and see if the issue follows. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
O/T Testing client
I am working on apparently my issue with either my client or ISP issue with
sending text.
Could you let me know (via private email) how your client sees the following
characters.
1. Double quotes ()
2. Single quotes (')
3. ampersand ()
4. at symbol (@)
5. Percent (%)
I think I have an ISP issue but will not know until I receive feedback.
Thanks,
Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
I heard about 7200 that was 10 yrs ago ... Scott J Ford Software Engineer http://www.identityforge.com From: Aled Hughes aledlhug...@aol.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, September 14, 2011 3:38 PM Subject: Re: Mainframe article Mr Timothy Prickett Morgan is not and never has been a great fan of mainframes. If you have ever read his comments, he always comes across as being anti-M/F and to some extent anti-IBM. As to the number of M/F sites in the world today? Where did he get this number from? As Bobbie Justice said, he probably doesn't read enough airline magazines! The number is much closer to 6,000, although no one knows for certain, not even IBM. The number of individual systems installed is obviously far greater than that. TPM's resume shows that he has very little background in M/F matters - except writing magazine articles, but mainly about mid-range systems. And as to any experience of working with M/Fs... in the words of the (in)famous Phil Payne, nuff said. ALH -Original Message- From: Ken Porowski ken.porow...@cit.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Wed, Sep 14, 2011 7:49 pm Subject: Re: Mainframe article I notice they claim only 4,000 Mainframe shops in the world. I thought he number was closer to 10,000. -Original Message- rom: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On ehalf Of Bobbie Justice ent: Wednesday, September 14, 2011 2:43 PM o: IBM-MAIN@bama.ua.edu ubject: Re: [IBM-MAIN] Mainframe article re: The Register has another mainframe related article which points out he rising importance of the mainframe and its growth in recent years. ttp://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/ No, this can't be right, obviously whoever wrote this article is not eading enough airline magazines. Bobbie Justice -- or IBM-MAIN subscribe / signoff / archive access instructions, send mail to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search he archives at http://bama.ua.edu/archives/ibm-main.html -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO earch the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: it's
It's is coming through on my end. The : (colon) is coming through fine. I am confused. Ed - Original Message - From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@bama.ua.edu Cc: Sent: Wednesday, September 14, 2011 1:59 PM Subject: it's Hi Ed, you are saying you see no 39 in either this subject line and in the quoted note below. Then your client is doubly broken :) Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, September 14, 2011 10:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets I have no idea what the issue is. The email you sent back to me does not contain the characters you indicated. A friend suggested it's a ISP issue. I will try using m other client and see if the issue follows. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
I know of at least one 1403-N1 still in regular service, maintained by cannabalized parts from two other units as needed. Rick - Shmuel Metz (Seymour J.) wrote: In 1315958086.61838.yahoomailmob...@web161421.mail.bf1.yahoo.com, on 09/13/2011 at 04:54 PM, Ed Gould ps2...@yahoo.com said: The 3800 printers essentially obsoleted all printers. No. 1. It was too expensive. 2. Some sites required impact printers for multi-part forms. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
You haven't dealt with the government regulatory agencies lately, have you, Ed? Some will not accept electronic copies but instead DEMAND carbon copies. At Clearing, we went round and round with Commerce Dept. types who INSISTED that we had to produce carbons, so we had to rent time on a system that had 3211 printers available. Will our stupid government EVER start thinking just a little like real business people? I sincerely doubt it myself. Rick - Ed Gould wrote: Yes there were follow on printers. I suspect there are very few real need for carbon copies anymore. I suppose, but I suspect that the number has decreased because with electronic copies the need is mute except for cash register and the odd type are needed. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Maybe he found something more ineresting. Like Donald Duck, Mickey Mouse or Bugs Bunny, mayge? Rick - Bobbie Justice wrote: re: The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/; No, this can't be right, obviously whoever wrote this article is not reading enough airline magazines. Bobbie Justice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Another alligator pundit? All mouth and no brains? :-) Rick --- Aled Hughes wrote: Mr Timothy Prickett Morgan is not and never has been a great fan of mainframes. If you have ever read his comments, he always comes across as being anti-M/F and to some extent anti-IBM. As to the number of M/F sites in the world today? Where did he get this number from? As Bobbie Justice said, he probably doesn't read enough airline magazines! The number is much closer to 6,000, although no one knows for certain, not even IBM. The number of individual systems installed is obviously far greater than that. TPM's resume shows that he has very little background in M/F matters - except writing magazine articles, but mainly about mid-range systems. And as to any experience of working with M/Fs... in the words of the (in)famous Phil Payne, nuff said. ALH -Original Message- From: Ken Porowski ken.porow...@cit.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Wed, Sep 14, 2011 7:49 pm Subject: Re: Mainframe article I notice they claim only 4,000 Mainframe shops in the world. I thought he number was closer to 10,000. -Original Message- rom: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On ehalf Of Bobbie Justice ent: Wednesday, September 14, 2011 2:43 PM o: IBM-MAIN@bama.ua.edu ubject: Re: [IBM-MAIN] Mainframe article re: The Register has another mainframe related article which points out he rising importance of the mainframe and its growth in recent years. ttp://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/ No, this can't be right, obviously whoever wrote this article is not eading enough airline magazines. Bobbie Justice -- or IBM-MAIN subscribe / signoff / archive access instructions, send mail to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search he archives at http://bama.ua.edu/archives/ibm-main.html -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO earch the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Rick, As a former Disney employee and resident of Central Florida, you should not associate Mickey or Donald with this 'author'!! :) Glenn - Original Message - From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu Sent: Wed Sep 14 16:23:29 2011 Subject: Re: Mainframe article Maybe he found something more ineresting. Like Donald Duck, Mickey Mouse or Bugs Bunny, mayge? Rick - Bobbie Justice wrote: re: The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/; No, this can't be right, obviously whoever wrote this article is not reading enough airline magazines. Bobbie Justice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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. SunTrust is a federally registered service mark of SunTrust Banks, Inc. Live Solid. Bank Solid. is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Text issue
While I was composing the test email I noticed that there is a switch to rich text option that shows up on my one client and not the other. Sigh.. I am guessing that somehow if I use the IPAD that somehow the ISP is not telling my client to present that option and assumes that I always want RTF. That means its a little bit of both ISP Client. Thanks for the feedback now off to figure who to complain to. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.IMAGELIB
Rick, Well when I worked at Options there wasn't such a need as we got rid of out impact printers and that was in 1990's Ed - Original Message - From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Cc: Sent: Wednesday, September 14, 2011 3:21 PM Subject: Re: SYS1.IMAGELIB You haven't dealt with the government regulatory agencies lately, have you, Ed? Some will not accept electronic copies but instead DEMAND carbon copies. At Clearing, we went round and round with Commerce Dept. types who INSISTED that we had to produce carbons, so we had to rent time on a system that had 3211 printers available. Will our stupid government EVER start thinking just a little like real business people? I sincerely doubt it myself. Rick - Ed Gould wrote: Yes there were follow on printers. I suspect there are very few real need for carbon copies anymore. I suppose, but I suspect that the number has decreased because with electronic copies the need is mute except for cash register and the odd type are needed. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
SHARE button from Anaheim JES2 may be Mickey Mouse, but JES3 is goofy! In a message dated 9/14/2011 3:23:50 P.M. Central Daylight Time, rfocht...@ync.net writes: Like Donald Duck, Mickey Mouse or Bugs Bunny, maybe? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CCW Trace
I have a DASD volume with very high activity and will be running a CCW trace to gather diagnostic info. I have all the info I need to run the trace. Does anyone have (or can you point me to) the CCW trace reduction program. This was a program (basically PROC FREQ) that reduced the target address of the seeks, and converted them to an easily readable format. Does anyone have (or can you point me to) the CCW trace reduction program. IBM had it many moons ago and distributed it with fair regularity. No $$$ for new tools. I suppose I can re-write it if push comes to shove. Thanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
The newest release of Faver from CA was just tested. It reduced our backup time from 58 minutes to 10 minutes and from 11 tapes to 6 tapes. Unfortunately, it is not totally transparent in that it requires a new DD statement, DSSMSGDD. It is invoking ADRDSSU to do the actual dump of the data. So anybody know a zero cost way to dynamically add a //DSSMSGDD DD SYSOUT=* to any step running PGM=GVEXPORT which lacks a //DSSMSGDD statement? grin Which also does not require writing any code and is fully supported? No, I'm not serious. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Tony Harminc wrote, re the number of mainframes in the world: I have no idea, but I still have my VM Soars with 20,000 licenses poster from IBM. That was from the 1990s, IIRC. Yeah, alas, that 20,000 apparently included every VM license ever sold at that point, including ones never installed, or certainly not running any more. So it included 9370s and P/390s and the like, and even IBM didn't think it was very real at the time. I consistently hear numbers in the 5K-10K range, but everyone's guessing (and most of 'em admit it). -- .phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
John, I remember doing something like this with a utility which name escapes me (PDS UTILITY)but it was a company from Farmington Michigan and I had to call their help desk to figure it out. This was 20 years ago. But I remember it was not exactly straight forward how to do. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
All, Isnt it odd no one seems to know number of z/OS,VSE,VM shops in the World or in the USA. I worked for a well known vendor on the z/OS,VE and VM team we had 2500 customers. We pretty much could tell you what they had or what we had in their customer account record. Scott J Ford Software Engineer http://www.identityforge.com From: Phil Smith p...@voltage.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, September 14, 2011 4:57 PM Subject: Re: Mainframe article Tony Harminc wrote, re the number of mainframes in the world: I have no idea, but I still have my VM Soars with 20,000 licenses poster from IBM. That was from the 1990s, IIRC. Yeah, alas, that 20,000 apparently included every VM license ever sold at that point, including ones never installed, or certainly not running any more. So it included 9370s and P/390s and the like, and even IBM didn't think it was very real at the time. I consistently hear numbers in the 5K-10K range, but everyone's guessing (and most of 'em admit it). -- .phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
Scott, There might be an issues between legal and let#39;s say less than legal. A former company that I used to work for had 4 systems and paid IBM for two. The IBM rep knew they were supposedly only for DR hmmm, not really but I digress. IBM rep had full knowledge of the deal. One time I was at the second site and needed a DFDSS fix and I needed to d/l via dial up link and I got some raised questions from IBM. They allowed the d/l. I didn#39;t hear any fallout but there was some. I didn#39;t do anything wrong it was management issue from start to finish. That is why the numbers are probably off. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: it's
In 1316031374.5682.yahoomail...@web161424.mail.bf1.yahoo.com, on 09/14/2011 at 01:16 PM, Ed Gould ps2...@yahoo.com said: It's is coming through on my end. Does your e-mail client have an option to view the raw message text? -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
I realize it's a grave insult to Mickey and Donald to make a direct comparison. Forgive me for a moment of weakness mixed with disgust at the temerity of this so-called author. Rick - Schneck.Glenn wrote: Rick, As a former Disney employee and resident of Central Florida, you should not associate Mickey or Donald with this 'author'!! :) Glenn - Original Message - From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu Sent: Wed Sep 14 16:23:29 2011 Subject: Re: Mainframe article Maybe he found something more ineresting. Like Donald Duck, Mickey Mouse or Bugs Bunny, mayge? Rick - Bobbie Justice wrote: re: The Register has another mainframe related article which points out the rising importance of the mainframe and its growth in recent years. http://www.theregister.co.uk/2011/09/13/bmc_mainframe_survey/; No, this can't be right, obviously whoever wrote this article is not reading enough airline magazines. Bobbie Justice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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. SunTrust is a federally registered service mark of SunTrust Banks, Inc. Live Solid. Bank Solid. is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
I'd kill for those buttons; economics keep me at home. :-( Rick -- Ed Finnell wrote: SHARE button from Anaheim JES2 may be Mickey Mouse, but JES3 is goofy! In a message dated 9/14/2011 3:23:50 P.M. Central Daylight Time, rfocht...@ync.net writes: Like Donald Duck, Mickey Mouse or Bugs Bunny, maybe? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
