Re: how-to Sysplex? - the LOGR and exploiters part
Barbara, we don't data share with DB2, so we don't see the problems with RRS offloads. Does the introduction of the data sharing in a subplex force you to share structures for the logstreams, even though they are sub-plexed? The problem in itself is NOT DB2 data sharing, it is the fact that DB2 uses RRS for some administrative tasks unequivocally. I am NOT a DB2 person. From what I understand, in order to see some of the current DB2 definitions, you need RRS to be active. Again, it is NO problem to separate RRS to use different log streams on different subplexes. It is the fact that RRS in turn uses the LOGR that causes the problems (from what I understand, in several different components). In all cases it is the design for LOGR offload to harden data to DASD at disconnect from the logstream. Short reminder of how the design currently works: Connector to logstream disconnects. LOGR issues an (XCF) signal to all remaining connectors to that logstream that offload is necessary. All remaining connectors enter the race condition to do the offload. At this point, things like number of CPUs ond lpar weight come into play as to *who* wins that race. In the case of operlog, it may be someone on a subplex that does not share the SMS constructs. Result: corrupted log stream. In the case of RRS, it may be that someone from another system (in another subsysplex) has just started to browse a log stream 'the other group' creating a temporary connection to the log stream that is in the process of being offloaded. Again, offload can happen then in the wrong subplex. Result: corrupted log stream. In the case of SMF, offload can happen on a system that is in itself in shutdown, so it may happen that the offload gets forcibly terminated by that system being wait stated from the v xcf, offline. Result: corrupted log stream. All of you going to share: Please raise a requirement against the LOGR offload process to be redesigned! (But please don't ask me how :-) ) simply connects to the operlog structure and reads it out. There is no check in place if operlog is actually *enabled* on that system! And, that's how it should be. And *that* is probably well hidden in some manual. I had expected different behaviour, namely only the ability to browse the log stream on the systems where operlog is written to. Until I saw the corrupted operlog, I had no reason to assume that it is otherwise. We run both, with operlog being considered mostly a nuisance because it shows 'too much'. Most people prefer syslog, anyway. But they are not the ones who have to investigate shutdown and IPL problems when there is no JES2! In the meantime, 'I have adapted.' FWIW, I submitted a SHARE requirement years ago to allow multiple OPERLOG log streams in a sysplex. The intent was that each system could substitute its XCF group name into the log stream name. Then you could have an OPERLOG for each JESplex. I think THAT would be useful! Can I have the number, please? I would like to concur with that! (Mark will not want to configure his systems that way, but then at least you have a 'choice'.) That leaves the offload problem, though! That's why (E)JES implements a feature called Syslog auto cmd routing. Which is kinda available for S/MCS consoles as CONTROL V,CMDSYS=name. CMDSYS is also an attribute for an EMCS console, but I am missing how to specify that via SDSF (that controls how my SDSF console is set up). And while I can probably change the cmdsys setting via some sort of RACF command, I am probably not authorized to issue those RACF commands! Best regards, Barbara -- 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
Software delivery via internet or tape
This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? Best regards, Barbara -- 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: Software delivery via internet or tape
I use a batch job PGM=FTP and connect directly. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Sunday, August 23, 2009 11:47 PM To: IBM-MAIN@bama.ua.edu Subject: Software delivery via internet or tape This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? Best regards, Barbara -- 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: how-to Sysplex? - the LOGR and exploiters part
The problem in itself is NOT DB2 data sharing, it is the fact that DB2 uses RRS for some administrative tasks unequivocally. I am NOT a DB2 person. From what I understand, in order to see some of the current DB2 definitions, you need RRS to be active. It uses RRS for DDF, for sure. I was involved in a DDF POC (2004) and RRS had to be 'customised'. It caused a political battle because RRS was considered part of the OS, which was supported by a different group than the one supporting DB2. If anybody's interested in the ins and outs, hit the archives. I posted the (then) current redbooks explaining the process. - Too busy driving to stop for gas! -- 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: Software delivery via internet or tape
Well... First, I can get direct ftp connection from mainframe if I would request and justify it (BTDT). Mainframe is not worse than any other computer vbg Second - it is not so big problem to have dedicated PC just for IBM software installation purposes. It costs much less than any tape drive, even maintenance fee for the drives. Regular PC nowadays has few hundreds gigabytes of HDD, DVD burner - so you can easily download and store your files and you can make archive copies of DVD plates. Just my $0.02 BTW: I don't like Internet Delivery for quite another reason: complexity. Regular, tape-based installation - CBPDO, ServerPac - is complex enough, however at acceptable level (read: I have no problems with that g). Internet Delivery adds several steps which further complicates the process and demand much more disk space. For some cases I needed 4 times more space than for regular CBPDO (AFAIR: zip, unizpped HFS file, fake tape datatasets, finally relfiles). So I would expect to simplify the installation process, Internet Delivery itself is not a problem IMHO. Just my second $0.02 Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Software delivery via internet or tape
Hi Barbara, We have just done the download, of z/OS 1.10, to PC and upload to the mainframe. The physical size of the download to the PC was over 8 Gig. The Download Director worked fine and it loaded each individual dataset that you would have seen on the tape, all without errors. As we don't have a large pipe, it took a weekend plus to download the data. The upload required more HFS space than can be found on a 3390-9. The ROOT file was the largest, followed by the SMPPTS, SMPPTS1 and the AAJVHFS file. Finally have it all on the mainframe but have not yet started the actual install. The actual upload failed numerous times as I was loading the data onto 3390-3s as I did not have any 3390-9 at that point in time. The only issues I had uploading the data was running out of space multiple times. I am not sure I would want to do this again and as most of my sites have 3590 or 3592 I will be suggesting we order on those in future. It just takes too much of my time and too much space to perform the download/upload of z/OS. Regards, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, 24 August 2009 4:47 PM To: IBM-MAIN@bama.ua.edu Subject: Software delivery via internet or tape This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? Best regards, Barbara -- 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: Software delivery via internet or tape
From the z/OS 1.11 Announcement Letter dated August 18, 2009 Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) and service orders on DVD media. Though IBM recommends using Internet delivery when ordering z/OS products or service, eliminating tape handling, the option to specify DVD physical delivery may provide an option for those who cannot accept Internet delivery. See the previous stated direction to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media, as announced in Software Announcement 208-186, dated August 05, 2008. Don't know if this address the original concern though. -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 11:57:30 +0200, ma...@tiscali wrote: From the z/OS 1.11 Announcement Letter dated August 18, 2009 Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) and service orders on DVD media. ... Have they described the data format of the DVD offering? How many DVDs will be required to contain a major product? -- gil -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 19:46:20 +1000, Paul Gillis wrote: We have just done the download, of z/OS 1.10, to PC and upload to the mainframe. The physical size of the download to the PC was over 8 Gig. The Download Director worked fine and it loaded each individual dataset that you would have seen on the tape, all without errors. As we don't have a large pipe, it took a weekend plus to download the data. The upload required more HFS space than can be found on a 3390-9. The ROOT file was the largest, followed by the SMPPTS, SMPPTS1 and the AAJVHFS file. Finally have it all on the mainframe but have not yet started the actual install. The actual upload failed numerous times as I was loading the data onto 3390-3s as I did not have any 3390-9 at that point in time. The only issues I had uploading the data was running out of space multiple times. Can you run an FTP server on the PC (Microsoft, Filezilla, whatever) and bypass the upload step, and rely on the restart capability of RECEIVE FROMNETWORK to recover from errors? (What's the largest single data set, zipped, which would need to be retried in case of error?) -- gil -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 05:43:36 -0500, Paul Gilmartin paulgboul...@aim.com wrote: Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) and service orders on DVD media. ... Have they described the data format of the DVD offering? How many DVDs will be required to contain a major product? And how do I read those DVDs on z/OS? Or do I read them on the PC and then run into all the space problems during upload that Paul described? (I had run into the same back in z/OS 1.4 days, and I agree, this takes much too much time!) Via CD is how Beta Systems delivers their products, and believe me, I don't like it. Let's restate the question: How many of you can use RECEIVE FROMNETWORK directly, without starting other supporting programs? Barbara -- 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: Software delivery via internet or tape
HI, When I create MFNetDisk one of my dream was to share 3390 disks or tapes from any distance using TCP and PC. One of the best targeting was to enable sharing installation files from distance without the need to FTP anything. Imagine accessing the MVS SMP from any location directly to IBM site. Just put the SMPPTS as input with the storage in remote IBM site using MFNetDisk and it is done. Another option was to deliver PC file (each PC file is 3390 disk or tape) and by running the MFNetDisk application in MVS to be able to install the MVS from the PC as MF tapes or as MF 3390 disks. Maybe I did not think enough about it, maybe I am wrong, maybe security, RACF or what ever I am not aware, but just thinking about other options to install software. But On Mon, Aug 24, 2009 at 1:43 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 24 Aug 2009 11:57:30 +0200, ma...@tiscali wrote: From the z/OS 1.11 Announcement Letter dated August 18, 2009 Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) and service orders on DVD media. ... Have they described the data format of the DVD offering? How many DVDs will be required to contain a major product? -- gil -- 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: Software delivery via internet or tape
Count me in, Barbara. I would hate to go back now. I've gotten used to the speed and easiness of ShopzSeries. PTFs available for download in less than five minutes. Product orders fulfilled within a few hours. Actual RECEIVE FROMNETWORK time varies by the amount of content, but I submit it and move on to other work. Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.gov - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, August 24, 2009 6:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Software delivery via internet or tape On Mon, 24 Aug 2009 05:43:36 -0500, Paul Gilmartin paulgboul...@aim.com wrote: Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac(r), ProductPac(r)) and service orders on DVD media. ... Have they described the data format of the DVD offering? How many DVDs will be required to contain a major product? And how do I read those DVDs on z/OS? Or do I read them on the PC and then run into all the space problems during upload that Paul described? (I had run into the same back in z/OS 1.4 days, and I agree, this takes much too much time!) Via CD is how Beta Systems delivers their products, and believe me, I don't like it. Let's restate the question: How many of you can use RECEIVE FROMNETWORK directly, without starting other supporting programs? Barbara -- 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: Software delivery via internet or tape
While the SOD doesn't provide any detail on how z/OS will exploit this option, I seem to remember that right now z/VM is optionally delivered on DVD and that it can be installed using the z9/z10 internal DVD device... -- 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: Annoying FIND Behaviors (Was: ISPF Counter)
IMHO, that's exactly how an intuitive application should behave. I can only second that! TSO command processors are obliged to implement proper ATTN handling. ISPF programs should as well. -- Peter Hunkeler Credit Suisse -- 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: Fw: Fw: Binder API...broke or working as designed
On Sun, 23 Aug 2009 16:00:22 -0500, William H. Blair wrote: Now, granted, the binder could be rewritten in another language that did not require LE, such as (dare I say it?!) Assembler. That, along with a better functional interface, could make it truly useful, even amazing. In what language is the binder written? I would have imagined PL/S. And I would have imagined that PL/S didn't require LE. Why do you so strongly advocate Assemble as opposed to, say, PL/S or Metal C, which ought not to require LE? -- gil -- 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: Software delivery via internet or tape
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, August 24, 2009 1:47 AM To: IBM-MAIN@bama.ua.edu Subject: Software delivery via internet or tape This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? Best regards, Barbara I use Download Director from ShopzSeries. It is reliable, as far as I can tell. I then zip up the entire subdirectory which is downloaded. I copy that zip file to my Linux/Intel system. I unzip it on the Linux/Intel system. I then connect the z/OS to my Linux/Intel system using NFS. I do a RECEIVE FROMNTS in SMP/E, pointing the Linux system's data. Yes, it is much slower than going directly to z/OS or using tape. But it does work reliably for me. One of the reasons that I use my Linux/Intel (desktop) is because I control it entirely. I have problems with management by wasting z/OS DASD volumes for UNIX files that I don't use often. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell 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: Software delivery via internet or tape
While the SOD doesn't provide any detail on how z/OS will exploit this option, I seem to remember that right now z/VM is optionally delivered on DVD and that it can be installed using the z9/z10 internal DVD device... Looking at my z/VM product DVDs, and thinking, 'Yes, that's right. I installed z/VM from the HMC, so why couldn't SMP/E under MVS access the HMC DVD drive as well . . . So, just speculating, would 'FROMNETWORK' become 'FROMHMC'? -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 08:04:27 -0500, Martin Kline wrote: While the SOD doesn't provide any detail on how z/OS will exploit this option, I seem to remember that right now z/VM is optionally delivered on DVD and that it can be installed using the z9/z10 internal DVD device... Looking at my z/VM product DVDs, and thinking, 'Yes, that's right. I installed z/VM from the HMC, so why couldn't SMP/E under MVS access the HMC DVD drive as well . . . So, just speculating, would 'FROMNETWORK' become 'FROMHMC'? Some might be uncomfortable with anything that adds wear and tear to a mechanical component of the HMC. Will the HMC accept an auxiliary DVD reader in a USB port? An alternatived I think of is a Live DVD (like Knoppix), containing o The software product in RECEIVE FROMNETWORK format. o A Linux OS with FTP server configured. Ought to work on PC or on Intel Mac. o A wizard to configure TCP/IP. Insert the DVD in the reader; restart; configure TCP/IP and run RECEIVE FROMNETWORK on z/OS. -- gil -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 05:54:45 -0500, Barbara Nitz nitz-...@gmx.net wrote: On Mon, 24 Aug 2009 05:43:36 -0500, Paul Gilmartin paulgboul...@aim.com wrote: Statements of direction IBM intends to provide the capability to deliver the z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) and service orders on DVD media. ... Have they described the data format of the DVD offering? How many DVDs will be required to contain a major product? And how do I read those DVDs on z/OS? Or do I read them on the PC and then run into all the space problems during upload that Paul described? (I had run into the same back in z/OS 1.4 days, and I agree, this takes much too much time!) Via CD is how Beta Systems delivers their products, and believe me, I don't like it. Let's restate the question: How many of you can use RECEIVE FROMNETWORK directly, without starting other supporting programs? We do. Probably most shops that use internet delivery do. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Software delivery via internet or tape
I use internet delivery, direct FTP from IBM to mainframe. Barbara Nitz nitz-...@gmx.net 08/24/09 2:46 AM This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? Best regards, Barbara -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Software delivery via internet or tape
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, August 24, 2009 8:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Software delivery via internet or tape On Mon, 24 Aug 2009 08:04:27 -0500, Martin Kline wrote: While the SOD doesn't provide any detail on how z/OS will exploit this option, I seem to remember that right now z/VM is optionally delivered on DVD and that it can be installed using the z9/z10 internal DVD device... Looking at my z/VM product DVDs, and thinking, 'Yes, that's right. I installed z/VM from the HMC, so why couldn't SMP/E under MVS access the HMC DVD drive as well . . . So, just speculating, would 'FROMNETWORK' become 'FROMHMC'? Some might be uncomfortable with anything that adds wear and tear to a mechanical component of the HMC. Will the HMC accept an auxiliary DVD reader in a USB port? An alternatived I think of is a Live DVD (like Knoppix), containing o The software product in RECEIVE FROMNETWORK format. o A Linux OS with FTP server configured. Ought to work on PC or on Intel Mac. o A wizard to configure TCP/IP. Insert the DVD in the reader; restart; configure TCP/IP and run RECEIVE FROMNETWORK on z/OS. -- gil And, if desired, that could possibly work on a desktop PC as well. Nice idea! But I'm not sure that IBM would want you to boot another/different OS on the HMC's hardware. Perhaps a virtualized appliance? VMWare has such things. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell 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: Software delivery via internet or tape
I use internet delivery for anything up to a PDO. Tried the MVS release download but got tired of the amount of time and the number of retries, so a tape is better and in truth doesn't take too much longer in elapsed time. Jack Kelly 202-502-2390 (Office) -- 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: Software delivery via internet or tape
- Original Message - From: Barbara Nitz nitz-...@gmx.net Newsgroups: bit.listserv.ibm-main Sent: Monday, August 24, 2009 2:47 AM Subject: Software delivery via internet or tape This is probably a bad time to enquire about it (as most of you are at Share), but here goes: I read in the SOD: IBM plans to discontinue delivery of software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS products or service which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media. Internet delivery is IBM's flagship delivery method; therefore, future software delivery enhancements will be focused on Internet delivery. Seeing how 'internet delivery' is the prefered method, how many of you are allowed to have a direct ftp connection to IBM? We certainly are NOT allowed to have that! So 'internet delivery' means downloading to a PC (provided there is enough space on the PC, and I don't even know if the 'toaster' - citrix clients - can download via ftp), then uploading to z/OS again, provided there is enough space there, too. Takes hours, is full of errors. How are others handling this? RECEIVE FROMNETWORK is the greatest thing since sliced bread. Unfortunately, too many PHB's won't allow the mainframe access to the Internet. It's OK for the company Email server to be there, but the mainframe? NFW! Or as Bill the Cat would say, GAG, ACK, BARFFF! There, I feel better. 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: how-to Sysplex? - the LOGR and exploiters part
You could request new DEFINE/UPDATE LOGSTREAM options to control which systems are permitted to perform offloads. Perhaps something along the lines of: OFFLOAD_SYSTEMS( [INCLUDE(sysname1 [,sysname2]...)] [EXCLUDE(sysname1 [,sysname2]...)] ) Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, August 24, 2009 2:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: how-to Sysplex? - the LOGR and exploiters part Barbara, we don't data share with DB2, so we don't see the problems with RRS offloads. Does the introduction of the data sharing in a subplex force you to share structures for the logstreams, even though they are sub-plexed? The problem in itself is NOT DB2 data sharing, it is the fact that DB2 uses RRS for some administrative tasks unequivocally. I am NOT a DB2 person. From what I understand, in order to see some of the current DB2 definitions, you need RRS to be active. Again, it is NO problem to separate RRS to use different log streams on different subplexes. It is the fact that RRS in turn uses the LOGR that causes the problems (from what I understand, in several different components). In all cases it is the design for LOGR offload to harden data to DASD at disconnect from the logstream. Short reminder of how the design currently works: Connector to logstream disconnects. LOGR issues an (XCF) signal to all remaining connectors to that logstream that offload is necessary. All remaining connectors enter the race condition to do the offload. At this point, things like number of CPUs ond lpar weight come into play as to *who* wins that race. In the case of operlog, it may be someone on a subplex that does not share the SMS constructs. Result: corrupted log stream. In the case of RRS, it may be that someone from another system (in another subsysplex) has just started to browse a log stream 'the other group' creating a temporary connection to the log stream that is in the process of being offloaded. Again, offload can happen then in the wrong subplex. Result: corrupted log stream. In the case of SMF, offload can happen on a system that is in itself in shutdown, so it may happen that the offload gets forcibly terminated by that system being wait stated from the v xcf, offline. Result: corrupted log stream. All of you going to share: Please raise a requirement against the LOGR offload process to be redesigned! (But please don't ask me how :-) ) simply connects to the operlog structure and reads it out. There is no check in place if operlog is actually *enabled* on that system! And, that's how it should be. And *that* is probably well hidden in some manual. I had expected different behaviour, namely only the ability to browse the log stream on the systems where operlog is written to. Until I saw the corrupted operlog, I had no reason to assume that it is otherwise. We run both, with operlog being considered mostly a nuisance because it shows 'too much'. Most people prefer syslog, anyway. But they are not the ones who have to investigate shutdown and IPL problems when there is no JES2! In the meantime, 'I have adapted.' FWIW, I submitted a SHARE requirement years ago to allow multiple OPERLOG log streams in a sysplex. The intent was that each system could substitute its XCF group name into the log stream name. Then you could have an OPERLOG for each JESplex. I think THAT would be useful! Can I have the number, please? I would like to concur with that! (Mark will not want to configure his systems that way, but then at least you have a 'choice'.) That leaves the offload problem, though! That's why (E)JES implements a feature called Syslog auto cmd routing. Which is kinda available for S/MCS consoles as CONTROL V,CMDSYS=name. CMDSYS is also an attribute for an EMCS console, but I am missing how to specify that via SDSF (that controls how my SDSF console is set up). And while I can probably change the cmdsys setting via some sort of RACF command, I am probably not authorized to issue those RACF commands! Best regards, Barbara -- 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: Binder API...broke or working as designed
- Original Message - From: Dave Day david...@consolidated.net Newsgroups: bit.listserv.ibm-main Sent: Friday, August 21, 2009 4:17 PM Subject: Binder API...broke or working as designed I'm using the Binder API to read ESD records for a Program Object. The sequence of the records returned are not in the order the csects are in, in the object. What I'm seeing is this: Class Offset for csect AA 1CCA4A Element Offset 52 Class Offset for csect BB 1CF6BC Element Offset 2CC4 Class Offset for csect CC 1CCAA0 Element Offset A8 I would have expected csect BB to be in the ESD buffer at it's relative position as far as Class and Element Offset. I did not expect these entries to be in the buffer in non ascending order. I'll change my code to check and place them in the internal map in correct order, but this sure seems broke to me. --Dave Day Dave, Had a long talk with the Binder API developer here at SHARE. Unlike what other posters have said here, he is very willing to hear what you have to say. But he can't address bugs or requirements in this forum. It's possible that what you're seeing is a bug, so he'd like you to open a PMR to see exactly what you're doing, and maybe he can help. After that, as Bill Klein says, perhaps a requirement should be opened. soapbox Unfortunately, too many people on IBM-Main expect IBM to respond here, instead of either opening a PMR or a requirement. There are a number of individuals who constantly complain about how badly things are implemented by IBM, but those same individuals haven't submitted a single requirement to fix them. You should only be allowed to complain after your PMR is closed WAD or your requirement is closed SUG or REJ. /soapbox 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
TYPRUN=SCAN
TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? Gene Lynd -- 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: Binder API...broke or working as designed
Dave, Had a long talk with the Binder API developer here at SHARE. Unlike what other posters have said here, he is very willing to hear what you have to say. But he can't address bugs or requirements in this forum. It's possible that what you're seeing is a bug, so he'd like you to open a PMR to see exactly what you're doing, and maybe he can help. After that, as Bill Klein says, perhaps a requirement should be opened. Tom, Thanks for taking the time to talk with him. If you would, get his email address, name, or some way for me to contact him, and send it to me. It is a customer load module that is doing this, sent to me to try to get to the bottom of a problem. I don't know what restrictions I am working under vis-a-vis a NDA with the customer. Would seem to me this shouldn't make any difference to them, but I don't know for sure, and will check. --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: TYPRUN=SCAN
CA has a JCL check. It seems to catch all JCL errors -- Original message from Lynd, Eugene C. eugene.c.l...@saic.com: -- TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? Gene Lynd -- 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: TYPRUN=SCAN
Using TYPRUN=SCAN does not catch all possible JCL errors, but it's a good start to ensuring that your job will run. TYPRUN=SCAN requests that the system scan this job's JCL for syntax errors, without executing the job or allocating devices. This parameter asks the system to check for: * Spelling of parameters and some subparameters that is not correct. * Characters that are not correct. * Unbalanced parentheses. * Misplaced positional parameters on some statements. * In a JES3 system only, parameter value errors or excessive parameters. * Incorrect syntax on JCL statements in cataloged procedures invoked by any scanned EXEC statements. You might still encounter JCL errors after using TYPRUN=SCAN, because this request checks the JCL only through the converter, not the interpreter. The difference is that the converter basically checks all expressions to the left of an equal sign plus some expressions to the right of an equal sign (and issues messages that start with IEFC), while the interpreter checks all expressions to the right of an equal sign (and issues messages that start with IEF). For example, a data set name containing a qualifier that exceeds eight characters, such as DSN=L9755TB.JCL.TEST19970103 would not be flagged by TYPRUN=SCAN but would be caught by the interpreter. From manual Reusable JCL collection. HTH, Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lynd, Eugene C. Sent: Monday, August 24, 2009 10:01 AM To: IBM-MAIN@bama.ua.edu Subject: TYPRUN=SCAN TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? Gene Lynd -- 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: Software delivery via internet or tape
On Mon, 24 Aug 2009 08:52:13 -0500, McKown, John wrote: Some might be uncomfortable with anything that adds wear and tear to a mechanical component of the HMC. Will the HMC accept an auxiliary DVD reader in a USB port? An alternatived I think of is a Live DVD (like Knoppix), containing o The software product in RECEIVE FROMNETWORK format. o A Linux OS with FTP server configured. Ought to work on PC or on Intel Mac. o A wizard to configure TCP/IP. Insert the DVD in the reader; restart; configure TCP/IP and run RECEIVE FROMNETWORK on z/OS. And, if desired, that could possibly work on a desktop PC as well. Nice idea! But I'm not sure that IBM would want you to boot another/different OS on the HMC's hardware. Perhaps a virtualized appliance? VMWare has such things. Desktop, of course. Until I re-read, I didn't know I had been ambiguous; I never meant to suggest rebooting the HMC. -- gil -- 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: TYPRUN=SCAN
On Mon, 24 Aug 2009 11:00:35 -0400, Lynd, Eugene C. wrote: TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? TYPRUN=SCAN is a farce. Submit with TYPRUN=HOLD, then cancel the job with SDSF. Or start with IEFBR14 and bypass all further steps with IF ... ENDIF. -- gil -- 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: Library Server and extended shelf support - resolution
For anyone else who might be looking to try this, I have now resolved my problems. I seem to have got round many issues by setting directory mode attributes, but there are two ways where the behaviour after PTF UK47562 has changed to be significant for our installation. - The default for LOGDIR was /usr/lpp/booksrv/cgi-bin (and is documented as such in the program directory) but it actually uses /usr/lpp/booksrv. - The catalog rebuild process expects to find the index files (.bki) in the /shelves directories. Previously it was happy to have the indexes in the /books directory (as shown in some examples). Other minor differences include that the storage requirement for the rebuild catalog job has increased significantly, but that was hardly unexpected and at least resulted in meaningful error messages. And I didn't need any LIBPATH, ICU_DATA or PATH environment variables. Good luck if you do try. -- 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: Software delivery via internet or tape
I also use RECEIVE FROMNETWORK directly. Brought the last CICS serverpac down that way. Will do 1.11 soon :) Let's restate the question: How many of you can use RECEIVE FROMNETWORK directly, without starting other supporting programs? Barbara -- 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: how-to Sysplex? - the LOGR and exploiters part
The inconvenient truth of all things sysplex is that sysplex is a shared everything architecture which means for it to work correctly, everything must be available everywhere in the plex. Subdividing the plex with old fashioned ideas like Prod runs on SYSA, development runs on SYSB and the sysprog sandbox is SYSC can only lead to operational inconvenience (at best) or disaster (worst) It isn't 1989 any more folks. It is time to shift gears. This stuff (only) works when you don't try to fight it. If you keep configuring systems like it is 1989, you will get operational results like it is 1989. (Ooh, did I say that out loud? My bad!) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
Possible data loss with HSM Patch enabled
Abstract: Possible data loss for z/OS 1.8, 1.9 and 1.10 with fix and HSM PATCH enabled for OA22507 Description: Only users of HSM with the PATCH enabled for APAR OA22507 to change GDG scratch processing during migration are affected. With this function enabled HSM may erroneously invalidate data sets which would prevent the data sets from being moved to a new tape volume during RECYCLE processing. The data may be lost if no backup exists. p Please see APAR OA30149 for additional information and actions to determine exposure. Recommended Actions: Please remove the PATCH to prevent the problem until fix for OA30149 is available and can be installed. http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/20090824.html NOTICE OF CONFIDENTIALITY The information contained in this communication, including but not limited to any accompanying document(s) and/or attachment(s), is privileged and confidential and is intended solely for the above-named individual(s). If you are not the intended recipient, please be advised that any distribution, copying, disclosure, and/or use of the information contained herein is strictly prohibited. If you received this communication in error, please destroy all copies of the communication, whether in electronic or hard copy format, and immediately contact the Security Office at EdFund at (916) 526-7539 or securityoff...@edfund.org. 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: how-to Sysplex? - the LOGR and exploiters part
I agree that it is an inconvenient truth: IBM has designed the sysplex to work best when resources are equally accessible by every system. However, the real world does not seem to be a symmetric. So forcing the square peg (i.e., real world) into the round hole (sysplex), may not accomplish a customer's goals. Therefore, IBM's sysplex design may need some alterations as well. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Monday, August 24, 2009 12:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: how-to Sysplex? - the LOGR and exploiters part The inconvenient truth of all things sysplex is that sysplex is a shared everything architecture which means for it to work correctly, everything must be available everywhere in the plex. Subdividing the plex with old fashioned ideas like Prod runs on SYSA, development runs on SYSB and the sysprog sandbox is SYSC can only lead to operational inconvenience (at best) or disaster (worst) It isn't 1989 any more folks. It is time to shift gears. This stuff (only) works when you don't try to fight it. If you keep configuring systems like it is 1989, you will get operational results like it is 1989. (Ooh, did I say that out loud? My bad!) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Software delivery via internet or tape
We use DVD all the time. Of course, we run Flex/ES and z/OS 1.9. Scott J Ford www.identityforge.com From: McKown, John jmck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Sent: Monday, August 24, 2009 9:52:13 AM Subject: Re: Software delivery via internet or tape -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, August 24, 2009 8:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Software delivery via internet or tape On Mon, 24 Aug 2009 08:04:27 -0500, Martin Kline wrote: While the SOD doesn't provide any detail on how z/OS will exploit this option, I seem to remember that right now z/VM is optionally delivered on DVD and that it can be installed using the z9/z10 internal DVD device... Looking at my z/VM product DVDs, and thinking, 'Yes, that's right. I installed z/VM from the HMC, so why couldn't SMP/E under MVS access the HMC DVD drive as well . . . So, just speculating, would 'FROMNETWORK' become 'FROMHMC'? Some might be uncomfortable with anything that adds wear and tear to a mechanical component of the HMC. Will the HMC accept an auxiliary DVD reader in a USB port? An alternatived I think of is a Live DVD (like Knoppix), containing o The software product in RECEIVE FROMNETWORK format. o A Linux OS with FTP server configured. Ought to work on PC or on Intel Mac. o A wizard to configure TCP/IP. Insert the DVD in the reader; restart; configure TCP/IP and run RECEIVE FROMNETWORK on z/OS. -- gil And, if desired, that could possibly work on a desktop PC as well. Nice idea! But I'm not sure that IBM would want you to boot another/different OS on the HMC's hardware. Perhaps a virtualized appliance? VMWare has such things. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell 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 -- 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: TYPRUN=SCAN
I have never come across this (or anything like this) in hundreds (thousands with automation ?) of times using TYPRUN=SCAN. 1) Has it always been a farce ? 2) Are there lots of other scenarios where it doesn't work ? 3) What is exactly is the root cause of this farcical behavior ? The DISP=SH example should be easily flagged as an error in any programming environment. (Spell check for Hotmail even flags the English spelling of behaviour as an error). TIA, Brendan Date: Mon, 24 Aug 2009 15:13:04 -0400 From: eugene.c.l...@saic.com Subject: TYPRUN=SCAN To: IBM-MAIN@bama.ua.edu TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? TYPRUN=SCAN is a farce. Submit with TYPRUN=HOLD, then cancel the job with SDSF. Or start with IEFBR14 and bypass all further steps with IF ... ENDIF. -- gil Gil nailed it - I now just add the IEFBR14 and IF ... ENDIF, and it looks like that will work (and better than a user could easily do manually). Thanks to all. Gene Lynd -- 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 _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009 -- 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: Hourglass usermod question
DSNXGRDS is my big concern. It seems like it gets hit every time I put on DB2 maint. DSNXGRDS has who knows how many CSECTs and Hourglass zaps 4 (I thought it was more) and expands one of them. So I could use something like Mark Z's example but hit a copy of DSNXGRDS - just to keep Hourglass functions out of prod DB2's. -- 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: Binder API...broke or working as designed
Dave Day wrote: Tom, Thanks for taking the time to talk with him. If you would, get his email address, name, or some way for me to contact him, and send it to me. Are you same Dave Day I know from TDMs in Poughkeepsie? If so, you should already are familiar with Barry Lichtenstein. His email is on his presentations and also available via http://whois.ibm.com. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Binder API...broke or working as designed
Tom Conley offered this: You should only be allowed to complain after your PMR is closed WAD. Been there, done that, got the T-shirt. That's what started the various (and ultimately not fruitful) technical dialogs with STL. We actually had two of them. Another customer was involved the second time. Neither one went anywhere (to our satisfaction). The only difference was that the second time we knew in advance that it was likely to be a water haul. But some different folks in IBM were involved the second time, so we gave it the college try. But in the end, the result was the same: sorry, but that's just the way it works. The problem is that while one can't APAR a violation of the principle of least astonishment, IBM themselves can and does sometimes document that that is how certain things work. -- WB -- 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: Fw: Fw: Binder API...broke or working as designed
Paul Gilmartin asks: In what language is the binder written? As far as I know, PL/X. But the binder itself is not actually the problem. It's the C/C++ / LE-dependent routines that the binder [API] invokes; they are the cause of the entanglements that the binder [API] suffers from, apparently. At least that is IBM's explanation. We just took them at their word on this. Note that these routines are involved even if one doesn't have a line of C/C++ code. The binder uses (what they call) C/C++ functions to perform some of _its_ functions. Very entangled. Very surprising (to us, and some other customers as well). I have no interest in a semantic discussion. If the binder API requires LE, then does the binder require LE? For the purposes of our (then-intended) application, the answer was in fact yes. But you can argue the point if you wish. The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. Why not? It's not our fault. It's an LE restriction. And, if anyone is going to document it, then it should be LE, not us [the binder]. But you don't document anywhere that you use LE, so how would we know that, prior to invoking the binder API, we should look up all these LE restrictions? OK, we'll document that you can't invoke the binder in that manner. And they did. And so, that ETR was closed with WAD: not a binder problem. I would have imagined PL/S. And I would have imagined that PL/S didn't require LE. You are so right. So ... IF the binder [API] DID require LE, YOU would be astonished ... right? Well, we were. Why do you so strongly advocate Assemble as opposed to, say, PL/S or Metal C, which ought not to require LE? I consider PL/X equivalent to Assembler for the issues that are under discussion (there's no runtime involved). Besides, I didn't strongly advocate Assembler. I just suggested it as one implementation approach that, if adhered to, would [obviously, like other things] avoid any LE entanglements. I think you're reading far too much into what I have said. The binder suffers from LE restrictions. That surprised us, and I think it violates the principle of least astonishment. There are other ways in which the binder [API] violates the principle of least astonishment. The scuttlebutt from some IBM contact at SHARE is that Well, this might be a bug. OK, so what? It's worked that way since PM2 (at least), so if it's a bug, then it's an old, old bug. But my point was that it obviously astonished Dave Day, just as it astonished us, and I attempted to inform him that other astonishments could be around the corner -- that's the way the binder is. I never said that it was not a bug (in fact, I don't know), or that it should not be APARed, or that a SHARE requirement should not be written to address it. I just said that it was astonishing, like so much else (like nearly everything else we tried) with the binder [API]. That's all. But I did say it was BAD (broken as designed). In our world, IBM does not always consider that to be a bug to be fixed. -- WB -- 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: TYPRUN=SCAN
Brendan Friel asks: 1) Has it always been a farce ? Yes. At least since 1974. 2) Are there lots of other scenarios where it doesn't work ? Yes. Several have been elucidated here, already. 3) What is exactly is the root cause of this farcical behavior ? The DISP=SH example should be easily flagged as an error in any programming environment. This, too, has already been covered. TYPRUN=SCAN simply says (to JES): Be a good boy here will you and run this JCL through the converter, OK? That's it. That's _all_ it does. That's all it has _ever_ done. Nothing else. Accordingly, it is the case that only errors that _can_ be found by the converter _will_ be found. Errors that can be found _only_ by the interpreter will (obviously) _not_ be found (simply because the interpreter will not get involved). And, in addition to that, errors that can only be found by the initiator will also _not_ be found (simply because the initiator will _also_ not get involved). -- WB -- 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: BCDS Summary Report?
Dave, Such a report could be created from DCOLLECT Using the 'Report Generator' - ISMF option G on z/OS V1R10 and later Start with the sample ARCGDB01 DCOLLECT BACKUP DATA report. Using the 'device class of backup volume' (UBDEVCL) you should be able to limit the data to just tapes. Mike Wood RMM Development On Fri, 21 Aug 2009 10:52:57 -0400, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote: I've been asked to provide the total amount of data stored by HSM on tape? ML2 was no problem as the following worked perfectly: LIST DSN MCDS SELECT(ML2) SUMMARY Unfortunately I cannot find a similar function for the BCDS. We also have FDR report available if that is of any help. Any suggestions? Thank You, Dave O'Brien NIH Contractor -- 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: TYPRUN=SCAN
TYPRUN=SCAN has had this type of behaviour since at least the mid '80's. I suspect it has been like this for a lot longer. Regards, Sam On Mon, Aug 24, 2009 at 8:43 PM, Brendan Friel bjpafr...@hotmail.comwrote: I have never come across this (or anything like this) in hundreds (thousands with automation ?) of times using TYPRUN=SCAN. 1) Has it always been a farce ? 2) Are there lots of other scenarios where it doesn't work ? 3) What is exactly is the root cause of this farcical behavior ? The DISP=SH example should be easily flagged as an error in any programming environment. (Spell check for Hotmail even flags the English spelling of behaviour as an error). TIA, Brendan Date: Mon, 24 Aug 2009 15:13:04 -0400 From: eugene.c.l...@saic.com Subject: TYPRUN=SCAN To: IBM-MAIN@bama.ua.edu TYPRUN=SCAN does not do a complete job of syntax-checking JCL. For example, DISP=SH is not flagged by the scan, but gets a JCL error if submitted normally (z/OS 01.09.00). A user did a ton of TYPRUN=SCAN submissions manually, and while I was playing with a tool to automate the process I encountered this inconvenient truth. Anyone know of more examples, or of a fix? TYPRUN=SCAN is a farce. Submit with TYPRUN=HOLD, then cancel the job with SDSF. Or start with IEFBR14 and bypass all further steps with IF ... ENDIF. -- gil Gil nailed it - I now just add the IEFBR14 and IF ... ENDIF, and it looks like that will work (and better than a user could easily do manually). Thanks to all. Gene Lynd -- 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 _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009 -- 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: TYPRUN=SCAN
TYPRUN=HOLD is just as much a farce. All of the following (plus a whole lot more) don't get caught till execution: //DD1 DD UNIT=CRUD - Invalid unit name //DD2 DD DSN=A12345678.FILE - 9 character qualifier //DD3 DD DISP=(OLD,CRUD) - Invalid keyword operand Only products like CA-JCLCheck or ThruPut Manager can get these. -- 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: BCDS Summary Report?
Mike, Thank you for the response. The required information has been gleaned using FDReport. I will however explore your suggestion for my own edification. Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Mike Wood [mikew_w...@uk.ibm.com] Sent: Monday, August 24, 2009 3:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BCDS Summary Report? Dave, Such a report could be created from DCOLLECT Using the 'Report Generator' - ISMF option G on z/OS V1R10 and later Start with the sample ARCGDB01 DCOLLECT BACKUP DATA report. Using the 'device class of backup volume' (UBDEVCL) you should be able to limit the data to just tapes. Mike Wood RMM Development On Fri, 21 Aug 2009 10:52:57 -0400, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote: I've been asked to provide the total amount of data stored by HSM on tape? ML2 was no problem as the following worked perfectly: LIST DSN MCDS SELECT(ML2) SUMMARY Unfortunately I cannot find a similar function for the BCDS. We also have FDR report available if that is of any help. Any suggestions? Thank You, Dave O'Brien NIH Contractor -- 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: Binder API...broke or working as designed
Dave Day wrote: Tom, Thanks for taking the time to talk with him. If you would, get his email address, name, or some way for me to contact him, and send it to me. Are you same Dave Day I know from TDMs in Poughkeepsie? If so, you should already are familiar with Barry Lichtenstein. His email is on his presentations and also available via http://whois.ibm.com. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 Ed, Thanks. I didn't have a name or contact within IBM for the Binder. Now I do. And yes, tis me whom you know from the TDM in Poughkeepsie. I didn't remember a presentation on the Binder, but there was a lot at the last TDM that my brain just threw into the bit bucket. --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
Binder API...broke or working as designed
*JUST* on the issue of the Binder API requiring the LE run-time, I have a question for you (WB) Were your discussions with STL done before or after Metal-C became available? It would seem to me (and I certainly could be ENTIRELY wrong on this), that a SHARE requirement to provide a Metal-C (no LE library required) version of the Binder API *might* receive a positive IBM response NOW. While asking for a no LE version of the Binder API *before* Metal-C was available received a negative response. As I have said before, I just don't see the harm in creating a SHARE requirement for this (or any other Binder enhancement). Occassionally (not all that often) IBM does provide solutions for SHARE requirements where similar individual site marketting requests get rejected. William H. Blair wmhbl...@comcast.net wrote in message news:hdemimhlcnkiedehaemeaegaadac.wmhbl...@comcast.net... Paul Gilmartin asks: In what language is the binder written? As far as I know, PL/X. But the binder itself is not actually the problem. It's the C/C++ / LE-dependent routines that the binder [API] invokes; they are the cause of the entanglements that the binder [API] suffers from, apparently. At least that is IBM's explanation. We just took them at their word on this. Note that these routines are involved even if one doesn't have a line of C/C++ code. The binder uses (what they call) C/C++ functions to perform some of _its_ functions. Very entangled. Very surprising (to us, and some other customers as well). I have no interest in a semantic discussion. If the binder API requires LE, then does the binder require LE? For the purposes of our (then-intended) application, the answer was in fact yes. But you can argue the point if you wish. The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. Why not? It's not our fault. It's an LE restriction. And, if anyone is going to document it, then it should be LE, not us [the binder]. But you don't document anywhere that you use LE, so how would we know that, prior to invoking the binder API, we should look up all these LE restrictions? OK, we'll document that you can't invoke the binder in that manner. And they did. And so, that ETR was closed with WAD: not a binder problem. I would have imagined PL/S. And I would have imagined that PL/S didn't require LE. You are so right. So ... IF the binder [API] DID require LE, YOU would be astonished ... right? Well, we were. Why do you so strongly advocate Assemble as opposed to, say, PL/S or Metal C, which ought not to require LE? I consider PL/X equivalent to Assembler for the issues that are under discussion (there's no runtime involved). Besides, I didn't strongly advocate Assembler. I just suggested it as one implementation approach that, if adhered to, would [obviously, like other things] avoid any LE entanglements. I think you're reading far too much into what I have said. The binder suffers from LE restrictions. That surprised us, and I think it violates the principle of least astonishment. There are other ways in which the binder [API] violates the principle of least astonishment. The scuttlebutt from some IBM contact at SHARE is that Well, this might be a bug. OK, so what? It's worked that way since PM2 (at least), so if it's a bug, then it's an old, old bug. But my point was that it obviously astonished Dave Day, just as it astonished us, and I attempted to inform him that other astonishments could be around the corner -- that's the way the binder is. I never said that it was not a bug (in fact, I don't know), or that it should not be APARed, or that a SHARE requirement should not be written to address it. I just said that it was astonishing, like so much else (like nearly everything else we tried) with the binder [API]. That's all. But I did say it was BAD (broken as designed). In our world, IBM does not always consider that to be a bug to be fixed. -- WB -- 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: Binder API...broke or working as designed
Were your discussions with STL done before or after Metal-C became available? Yes: before AND after. I had to examine my archives and files to answer your question. They took place around these dates: Most weeks every month during: o February through August 2001 o March through June 2002 o August through November 2002 o July 2008 and scattered days in-between. I consider the February 2001 through November 2002 extended conversation the first engagement. The second one was held in July 2008 when IBM came to us (and another customer) for explanation. Basically, we just re-sent the same emails we had sent to IBM before in 2001-2002 to the new point person du month for the issue -- with newly-written cover letters and more patient explanations attached. As I have said before, I just don't see the harm in creating a SHARE requirement for this There would obviously be no extraordinary harm in doing so. Since Dave Day has a head start, let's see how far he gets with his problem. But I suspect he isn't going to get into any issue that resulted in our abandoning the use of the binder API at this end. He observed something odd and unexpected that very much surprised him. Now, will IBM consider what he has found to be a bug (this time)? I have a prediction: No. It will be a WAD. We shall see (if we're lucky). -- WB -- 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: Fw: Fw: Binder API...broke or working as designed
On Mon, 24 Aug 2009 14:56:05 -0500, William H. Blair wmhbl...@comcast.net wrote: ... The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. ... Warning: The following comment is based on total ignorance. It seems like better (but MUCH longer term) goal would be to have the restrictions in LE relaxed ot removed. If IBM is going to use LE functions as general purpose subroutines these functions work where needed and expected. Since I don't know what functions and restrictions are involved, I may be suggesting that fundimental laws of the universe be changed. But since the whole excercise may be tilting at windmills, this is just a probably just a bigger windmill. Pat O'Keefe -- 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: how-to Sysplex? - the LOGR and exploiters part
On 8/24/2009 at 10:10 AM, in message b0c6f15b0908240910g27b48cbdqe9b138a6ee7da...@mail.gmail.com, Chris Craddock crashlu...@gmail.com wrote: The inconvenient truth of all things sysplex is that sysplex is a shared everything architecture which means for it to work correctly, everything must be available everywhere in the plex. Subdividing the plex with old fashioned ideas like Prod runs on SYSA, development runs on SYSB and the sysprog sandbox is SYSC can only lead to operational inconvenience (at best) or disaster (worst) It isn't 1989 any more folks. It is time to shift gears. This stuff (only) works when you don't try to fight it. If you keep configuring systems like it is 1989, you will get operational results like it is 1989. (Ooh, did I say that out loud? My bad!) As a VSE shop migrating to z/OS I have little understanding of these things. In VSE we have two development guests (under VM) and two production, and never the twain shall meet. In my VSE mindset I think that under z/OS we would have development LPARs separate from production LPARs. Is this not the case? Are there special z/OS things (I am not a Sysprog) that keep test jobs nicely segregated from prod, even when running in the same LPAR? The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- 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: Fw: Fw: Binder API...broke or working as designed
There you go thinking logically again Pat... On Mon, Aug 24, 2009 at 5:45 PM, Patrick O'Keefe patrick.oke...@wamu.netwrote: On Mon, 24 Aug 2009 14:56:05 -0500, William H. Blair wmhbl...@comcast.net wrote: ... The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. ... Warning: The following comment is based on total ignorance. It seems like better (but MUCH longer term) goal would be to have the restrictions in LE relaxed ot removed. If IBM is going to use LE functions as general purpose subroutines these functions work where needed and expected. Since I don't know what functions and restrictions are involved, I may be suggesting that fundimental laws of the universe be changed. But since the whole excercise may be tilting at windmills, this is just a probably just a bigger windmill. ROTFLMAO! It would be easier to redefine the speed of light or the fine structure constant of the universe than get a do-over on LE. Without going into gory details, the LE runtime is written in such a way as to be completely unusable by privileged programs, or indeed even by programs that are ephemeral (like exits) and only briefly need a runtime to provide working storage and perhaps recovery. The existence of Metal C is tacit acknowledgement of that fact. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Software delivery via internet or tape
RECEIVE FROMNETWORK is the greatest thing since sliced bread. Unfortunately, too many PHB's won't allow the mainframe access to the Internet. It's OK for the company Email server to be there, but the mainframe? NFW! Or as Bill the Cat would say, GAG, ACK, BARFFF! I envy all of you out there who can use receive fromnetwork. We're in the other category. And we were just informed that 'our' alternative will be delivery to DVD. (Someone needs to grow a very long arm to be able to put the DVDs into the HMCs) Thanks to all who took the time to respond and share *their* woes with me. I feel with you (same scars). Best regards, Barbara -- 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: how-to Sysplex? - the LOGR and exploiters part
The inconvenient truth of all things sysplex is that sysplex is a shared everything architecture which means for it to work correctly, everything must be available everywhere in the plex. While I respect CC, greatly, I disagree with must. Subdividing the plex with old fashioned ideas like Prod runs on SYSA, development runs on SYSB and the sysprog sandbox is SYSC can only lead to operational inconvenience (at best) or disaster (worst) I have seen/worked with 'partitioned' SYSPLEX environments. I've had up to 5 images in a SYSPLEX, not as large as some, and more in a GDPS environment. We shared IMS DB2 in up to three, and CICS with DB2 in up to two. I've partitioned off two MASPLEX environments, and had two separate development environments. I've also worked with a 'shared nothing' SYSPLEX, except for system, consoles, RACF, etc. I'm not trying to brag, rather to point out that I don't think must is accurate. SYSPLEX facilitates sharing, but it doesn't make it mandatory. It isn't 1989 any more folks. It is time to shift gears. This stuff (only) works when you don't try to fight it. If you keep configuring systems like it is 1989, you will get operational results like it is 1989. Again, I disagree. SYSPLEX gives you many options. (Ooh, did I say that out loud? My bad!) As a VSE shop migrating to z/OS I have little understanding of these things. In VSE we have two development guests (under VM) and two production, and never the twain shall meet. In my VSE mindset I think that under z/OS we would have development LPARs separate from production LPARs. That is a valid configuration. Is this not the case? Yes. And, you can enforce it through security and configuration options. For example: 1. Only assign test classes to the development LPARs. 2. Don't start TSO on production. 3. Use your security product to restrict access to production. 4. etc. Are there special z/OS things (I am not a Sysprog) that keep test jobs nicely segregated from prod, even when running in the same LPAR? I would not run test prod on the same LPAR, but that's me. - Too busy driving to stop for gas! -- 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: how-to Sysplex? - the LOGR and exploiters part
Don, You could request new DEFINE/UPDATE LOGSTREAM options to control which systems are permitted to perform offloads. Perhaps something along the lines of: OFFLOAD_SYSTEMS( [INCLUDE(sysname1 [,sysname2]...)] [EXCLUDE(sysname1 [,sysname2]...)] ) This was written so nicely :-), I went and checked the books if it's a function in 1.11. Pity it isn't. I like the idea, though. Now who is going to write the requirement?!? g,dr The inconvenient truth of all things sysplex is that sysplex is a shared everything architecture which means for it to work correctly, everything must be available everywhere in the plex. Subdividing the plex with old fashioned ideas like Prod runs on SYSA, development runs on SYSB and the sysprog sandbox is SYSC can only lead to operational inconvenience (at best) or disaster (worst) It isn't 1989 any more folks. It is time to shift gears. This stuff (only) works when you don't try to fight it. If you keep configuring systems like it is 1989, you will get operational results like it is 1989. Sorry Chris, but this is spoken like someone living in a cloud. Unfortunately, with the apparent exception of very few huge installations, money is the biggest concern. And software pricing. And no amount of name-calling you're living behind the times is going to change *that* management approach (a few enlightened individuals maybe excepted, but I haven't met any personally.) Oh, and did I mention that response times for IMS shared queues are sooo bad (confirmed by IMS development) that we CANNOT do sysplex sharing (also confirmed by IMS development)? What are we supposed to do? Pay twice (or more) as much just because we cannot establish 'real' data sharing as defined by IBM? Not use sysplex pricing to reduce software costs in order to still *have* a mainframe/MVS/zOS? Out in the real world we're stuck with the mindset 'SYSA is production, SYSB is development, SYSC is sysprog sandbox', and please keep them separated but join them for pricing reasons! How do you suggest 'we not fight them'? Barbara -- 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: Software delivery via internet or tape
A couple comments: 1. RECEIVE FROMNETWORK is absolutely the way to go if at all possible, agreed. Engage your friendly IBM representative if you need to have a security discussion about doing this. (One would think you're going to be using a network-segregated staging LPAR anyway. The RECEIVE FROMNETWORK connection can also tolerate firewalls, either mainframe-hosted or not.) 2. If unfortunately you have to use an intermediate PC -- and I really wish you wouldn't -- you don't have to transfer files twice, manually. It's much easier to set up an NFS or SMB shared drive (Drive Z or Drive M) on your mainframe. Connect your PC to that, then as you download the files save them directly to Drive Z. For example, instead of C:\Download it's Z:\Download -- or the equivalent on a Linux PC. Download Director works with network drives, too. 3. If you need NFS for Microsoft Windows, you can get Microsoft's version here for Windows XP Professional and Windows 2000: http://www.microsoft.com/downloads/details.aspx?familyid=896c9688-601b-44f1-81a4-02878ff11778displaylang=en Windows Vista Enterprise, Windows Vista Ultimate, and Windows Server 2003 R2 (and later Windows releases) come with NFS (client at least) as an installable feature. There are also third party alternatives. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- 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
