Re: Mainframe Charge Back Software
Pacific Systems Management in Australia provide TheBill. http://psm.cx/ Regards, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Barry Sent: Tuesday, 31 March 2009 9:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Charge Back Software On Mon, 30 Mar 2009 16:55:18 -0500, Tom Eden tbe2...@comcast.net wrote: What software are people using for mainframe chageback? Is there anything besides JARS or MICS out there. Yes. SAS Institute has SAS ITRM suite solution/approach. IBM has zTDS and the successor to CIMS, now called Tivoli UAM. Some clients are developing their own KISS approach, using Merrill's MXG and their locally-developed and maintained SAS-based code. We have a Links page where you can reach most, if not all, the vendors' public information on the available products: http://sbbworks.com/links.htm Regards, Scott Barry SBBWorks, Inc. -- 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: System z10 Articles in IBM Journal of RD
These are all hardware articles, they ae Not Software Articles When is Your Meeting with Donovan Data Systems ? What's your message, Mr. Noname? System z denotes hardware; why would you expect software articles? -- 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: Another One Bites the Dust
Makes me wonder if anyone ever implemented SAP on time and under budget. Sorry to hear of the demise of the dino. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 cell: 770-666-7969 email: daniel_mclaugh...@us.crawco.com web: www.crawfordandcompany.com Dave Cartwright davecartwri...@uk.agcocorp.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 03/31/2009 03:07 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Another One Bites the Dust -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Dave Cartwright davecartwri...@uk.agcocorp.com Subject: Another One Bites the Dust --- We turned our mainframe off yesterday. Z9BC running zOS 1.4 (yes! Had a 1.7 system ready, but there didn't seem any point). I didn't know whether to continue the More Layoffs thread, but stuck with tradition. I am fighting redundancy, but not very hopeful. Replaced by SAP on P-Series, a mere $50 million over budget. Thanks for all the fish. 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 Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: Another One Bites the Dust
Makes me wonder if anyone ever implemented SAP on time and under budget. A friend of mine worked as a consultant on non-mainframe platforms. In his experience no one ever implemented SAP as completely as had been planned at the beginning of the project. Bob Shannon -- 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 Charge Back Software
Pacific Systems Management in Australia provide TheBill. http://psm.cx/ This is very interesting to know Chargeback Systems are alive and well down under. But looking at the website, I notice a number of things which make me nervous. 1. Copyright on the web page is 2002 2. Supported systems are mainframes (good show) 3. Supported systems are UNIX (OK) 4. Supported systems are AS/400 (thought these were iSeries now) 5. Supported systems are Windows NT (so has 2000, XP, and Vista not just made it their way yet). Maybe these mainframers are just to busy to update a web page with more current info. If indeed anyone is using these in a current z/OS V1.9 or later with also maybe feeding zLinux info out of Velocity Software's info, would be curious. Around here the main focus for the last number has been Disaster Recovery since 9/11. I am predicting there will be a movement towards Chargeback soon to attempt to define where IT costs are residing. My view of Chargeback is it has two sides; COST and REVENUE. The revenue side is easy because in the end someone always has to pay (may be contentous but it still the money comes). The difficult side is the COST because IT likes to bury costs for others in side deals besides masking costs for items and then lumping them into either overhead or historically in the mainframes CPU charge. In summary, I hope this firm is real and can offer an alternative to SAS, IBM, CA, PACE (Komand), and a number which escape me for now. jim -- 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: Data erase on stacked backend tapes.
-Original Message- We have the need to erase any residual data on some stacked backend vsm tapes. I've heard you can do this with FATS/FATAR but wondered if there is any other method to do this? Everything else I have seen seems to require the tapes be added to your tape management system and even then there is some doubt that this will work. Thanks John When you say residual data are you in fact meaning that you want to erase any data on the tape that exists past the very last file on the tape through to the physical end of the cartridge or are you wanting to erase the entire tape? Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for Innovation Data Processing, Inc. -- 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
Zos 1.9
Last weekend we converted to zos 1.9 with only the following problem. When the programmers use 'sibbatch', while processing an ksds, there is a extra data extent created, that is not cataloged. Since these are orphaned, It does not take long to fill up a sms pool where they reside. If we use 'adrdssu', the problem does not occur. The hardware is v2xf. Any thoughts or ideas? Thank you in advance Bill Carroll DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- 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: Another One Bites the Dust
I once was technical lead on a SAP project that finished on time and under budget. It was back in 1994, SAP R2, running on MVS 4.3 and CICS 3.3 with a VSAM database -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Shannon Sent: Tuesday, March 31, 2009 5:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Another One Bites the Dust Makes me wonder if anyone ever implemented SAP on time and under budget. A friend of mine worked as a consultant on non-mainframe platforms. In his experience no one ever implemented SAP as completely as had been planned at the beginning of the project. Bob Shannon -- 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
secure file transfer FROM z/OS
What protocols are available to enable secure file transfer with z/OS being the client. I've RTFM but not found a great deal and the archives are not helping me very much. Jim McAlpine -- 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: secure file transfer FROM z/OS
Jim, The two primary non-proprietary protocols and IBM products are: - FTPS (TLS). This is supported by z/OS Communications Server. - SSH SFTP. This is supported by z/OS Ported Tools - OpenSSH. FTPS pros - Full dataset support by z/OS CS Generally, better native z/OS features than Ported Tools SSH FTPS cons - Uses multiple sockets which can be tricky wrt firewalls, NAT routers, etc Requires compatible FTPS server SFTP pros - Single socket connection, much more firewall friendly SSH/SFTP tends to be more widely available on partner *nix systems than FTPS SFTP cons - Ported Tools version of OpenSSH doesn't support MVS datasets, SMF, etc. Other options - - We offer a free extension to Ported Tools OpenSSH that adds MVS dataset support and SMF logging to SFTP. - We also offer a free proxy tool that can be used to tunnel regular FTP over an SSH connection. - SSH Communications offers their own completely separate SSH/SFP product (Tectia). Kirk Wolf Dovetailed Technologies http://dovetail.com PS Are you interested in more information on z/OS SSH SFTP ? We plan on offering a free webinar on Ported Tools OpenSSH and SFTP. Please drop me an email if you are interested and I'll add you to announcement list when it is available. On Tue, Mar 31, 2009 at 9:24 AM, Jim McAlpine jim.mcalp...@gmail.comwrote: What protocols are available to enable secure file transfer with z/OS being the client. I've RTFM but not found a great deal and the archives are not helping me very much. Jim McAlpine -- 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: A foolish consistancy or 3390 cyl/track architecture
Perhaps there is more to the emulation of CKD than the thread touches on. Disk Drives stopped recording in CYLS some time ago because the time for head switching is greater than the minimum seek time. Drives today record in a serpentine method across the platters, doing a switch-back (best word I can think of) to the next head at intervals defined by the HDD designers. The whole idea of tracks and CYLS is really dead and buried as far as the real hardware is concerned. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, March 27, 2009 2:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] A foolish consistancy or 3390 cyl/track architecture On Fri, 27 Mar 2009 14:41:10 -0500, Chase, John wrote: Well, if IBM's new DASD architecture were manufactured in the same manner as previous DASD devices, you would have 278,921,216 tracks on each surface. What diameter do you think such platters would be? How long would it take the access arm to traverse the radius? How much power would it take to spin them fast enough to be usable? :-) Long ago, I attended a Preview of XA presentation at which the IBM presenter (Bill Malleck?) stated that smaller rotational latency could be achieved only with smaller platters. Mechanical disruption happens at a surface velocity roughly the speed of sound -- sqrt( Young's modulus / density ). The problem engineers were confronting was oxide flying off the substrate. By analogy, Have you ever watched the chef making pizza, throwing the dough in the air to form the crust? Notice that he only puts the sauce on after. Tetrahedral carbon platters? Graphene? (They're working on it.) -- 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: secure file transfer FROM z/OS
Thanks Kirk, just the info I needed. Jim McAlpine On Tue, Mar 31, 2009 at 4:24 PM, Kirk Wolf k...@dovetail.com wrote: Jim, The two primary non-proprietary protocols and IBM products are: - FTPS (TLS). This is supported by z/OS Communications Server. - SSH SFTP. This is supported by z/OS Ported Tools - OpenSSH. FTPS pros - Full dataset support by z/OS CS Generally, better native z/OS features than Ported Tools SSH FTPS cons - Uses multiple sockets which can be tricky wrt firewalls, NAT routers, etc Requires compatible FTPS server SFTP pros - Single socket connection, much more firewall friendly SSH/SFTP tends to be more widely available on partner *nix systems than FTPS SFTP cons - Ported Tools version of OpenSSH doesn't support MVS datasets, SMF, etc. Other options - - We offer a free extension to Ported Tools OpenSSH that adds MVS dataset support and SMF logging to SFTP. - We also offer a free proxy tool that can be used to tunnel regular FTP over an SSH connection. - SSH Communications offers their own completely separate SSH/SFP product (Tectia). Kirk Wolf Dovetailed Technologies http://dovetail.com PS Are you interested in more information on z/OS SSH SFTP ? We plan on offering a free webinar on Ported Tools OpenSSH and SFTP. Please drop me an email if you are interested and I'll add you to announcement list when it is available. On Tue, Mar 31, 2009 at 9:24 AM, Jim McAlpine jim.mcalp...@gmail.com wrote: What protocols are available to enable secure file transfer with z/OS being the client. I've RTFM but not found a great deal and the archives are not helping me very much. Jim McAlpine -- 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: A foolish consistancy or 3390 cyl/track architecture
Ron Hawkins pisze: Perhaps there is more to the emulation of CKD than the thread touches on. Disk Drives stopped recording in CYLS some time ago because the time for head switching is greater than the minimum seek time. Drives today record in a serpentine method across the platters, doing a switch-back (best word I can think of) to the next head at intervals defined by the HDD designers. The whole idea of tracks and CYLS is really dead and buried as far as the real hardware is concerned. Last but not least: there is no more canonical geometry - I mean fixed number of bytes (sectors) per track. The longer (physically) track the more bytes it keeps. All we know formula O=2*PI*r. However even the most modern operating system like Unix or Windows do not know about it. The systems still treat disk like it would have fixed (equal) capacity tracks. They have to, because drive electronics still cheats (emulates) canonical geometry. Talking about future we should also consider non-disk devices (flash SSD). -- 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: A foolish consistancy or 3390 cyl/track architecture
--snip- Perhaps there is more to the emulation of CKD than the thread touches on. Disk Drives stopped recording in CYLS some time ago because the time for head switching is greater than the minimum seek time. Drives today record in a serpentine method across the platters, doing a switch-back (best word I can think of) to the next head at intervals defined by the HDD designers. The whole idea of tracks and CYLS is really dead and buried as far as the real hardware is concerned. --unsnip-- Long ago, when I worked in a heavily-modified CP67/CMS environment (on 168's and 2305's), we had a fairly sophisticated mechanism for handling page files on the 2305's. Each track was written with three page records, and a gap record between each pair of page records. We learned that the gap record afforded us enough time to swap exposures on the 2305, so we could read three pages, from the same track, on three different exposures of the 2305, in one revolution. We did the writing on a different trio of exposures as well. (Thank you, Grant Tegtmeier.) I would venture to guess that modern DASD storage uses a far more sophisticated version of the same mechanism to read/write records on multiple physical drives today, even though the logical perception, from the program point of view is the traditional view. Back to the original starting point of this thread: I, for one, am grateful for the solidification of a single geometry. Recomputing space parameters and updating legacy applications can become a MAJOR and EXPENSIVE process, frought with errors and omissions. By maintaining the same geometry, we can let these old applications, etc. die off by attrition, rather than having to spend valuable resources updating legacy code and JCL because a new device is being brought into the shop. The fact that a device has more cylinders available should NOT be a matter for application programmers to be concerned about; let the system manage the space, and the systems programmers worry about the details, if they really feel it's necessary. Same opinion concerning tracks. By leaving the basic geometry alone, a shop can go forward with new development and let the programmers learn about SMS-friendly space requests. My two cents worth. :-) -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- 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: Another One Bites the Dust
Dave, I wish you the best of luck, either in maintaining your position or finding a new one. Friends always. Dave Cartwright wrote: We turned our mainframe off yesterday. Z9BC running zOS 1.4 (yes! Had a 1.7 system ready, but there didn't seem any point). I didn't know whether to continue the More Layoffs thread, but stuck with tradition. I am fighting redundancy, but not very hopeful. Replaced by SAP on P-Series, a mere $50 million over budget. Thanks for all the fish. 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 -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- 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: System z10 Articles in IBM Journal of RD
Hello Miklos, CPMF is intended only for IBM internal use now when analyzing performance problems. Marian Gasparovic IBM Slovakia On Mon, Mar 30, 2009 at 12:52 PM, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: Hi Thank you very much for the link. I have read , till now only IBM System z10 performance improvements with software and hardware synergy The CPMF is seems to us very interesting feature , as we try to optimize our C++ code, and the Performance Analyzer reports are not very usefull for us. We have here a z9 S07. The question, if there is a posibility to make some performance evaluation tests in a z10 via CPMF. Timothy Sipples wrote: I'm not sure if anyone has mentioned yet that IBM has published a series of technical articles on the System z10 design and architecture in the IBM Journal of Research and Development: http://www.research.ibm.com/journal/rd53-1.html If you're interested in a lot of technical detail, there's some good reading. Enjoy. -- 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 -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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: Another One Bites the Dust
Best of Luck to you on your pursuits. I have been there, I Dave, Best of Luck to you on your pursuits. I have been there, I was 4000 miles from home across the big pond in Europe I hope all works out for you ok.. Best Wishes, Scott J Ford www.identityforge.com From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Tuesday, March 31, 2009 12:06:50 PM Subject: Re: Another One Bites the Dust Dave, I wish you the best of luck, either in maintaining your position or finding a new one. Friends always. Dave Cartwright wrote: We turned our mainframe off yesterday. Z9BC running zOS 1.4 (yes! Had a 1.7 system ready, but there didn't seem any point). I didn't know whether to continue the More Layoffs thread, but stuck with tradition. I am fighting redundancy, but not very hopeful. Replaced by SAP on P-Series, a mere $50 million over budget. Thanks for all the fish. 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 -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- 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
IBM Patents efforts to justify offshoring
http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9130750source=NLT_PM (watch the wrap) March 30, 2009 (Computerworld) IBM last week filed a patent application for an offshore outsourcing methodology that is intended to help companies minimize the financial risks associated with sending work overseas. The patent application describes a computer-driven approach for putting values on both the quantitative and qualitative attributes of a global resource sourcing strategy. For instance, the methodology takes into account the language skills and morale of offshore workers, as well as a list of the hard numbers involved in setting up an offshore operation, including labor rates and currency valuations. In short, IBM is attempting to reduce offshoring considerations to a mathematic model — or, in the words of the application, a robust and reusable sourcing template for identifying and analyzing global resource pools. For IBM itself, the patent filing couldn't be any timelier. The company submitted the application to the U.S. Patent Trademark Office last Thursday, the same day it confirmed that it is eliminating more jobs in its North American operations. IBM didn't disclose any details about the planned cutbacks, but allia...@ibm, a union local that isn't recognized as an official bargaining unit, has said it expects between 4,000 and 5,000 workers to be let go. The union thinks the cuts are part of a plan by IBM to send more jobs overseas, following an earlier round of reductions in January. In the patent application, IBM said the described methodology allows decision-makers to conveniently trade off one or more qualitatively defined levels between one or more factors in terms of quantifiable, direct, costs. The methodology also looks at some scary assumptions as part of its mathematical models — scary, that is, if you're a U.S.-based IT worker. In a hypothetical assessment, the application sets up an example that includes a company having 50% of resources in China by 2010. Here's an example of the specific metrics that the methodology takes into account: Suppose that employees hired in country A possess level 1 communication skills, while employees in country B possess level 2 skills. Additionally, suppose that the job satisfaction of employees hired in country A is rated to be at level 2, while that of employees hired in country B is rated at level 1. In this case, a lower score implies higher job satisfaction. Since communication skill levels and job satisfaction levels can't be directly compared, it's useful to quantify in terms of cost the differences between the levels, both within the same factor and across different ones. The patent application explains why IBM thinks it's important to look at a broad range of variables when making global sourcing decisions. By simply looking at wages and material costs, the organization may indirectly increase other costs such as those associated with poorer quality workers and/or materials, IBM said. That could include loss of customers, lower productivity, increased product returns and higher worker attrition, the company said, adding that a company needs to consider both direct and indirect costs associated with its resources. This isn't the first time that IBM has filed for a patent related to an offshoring methodology. An application filed in 2007 described a software-driven approach for identifying at least a portion of a human-resource within an organization for outsourcing. -- 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: A foolish consistancy or 3390 cyl/track architecture
Ron, Thanks for clearing up how the current drives actually work. It just seems like IBM could get away from the track and cylinder stuff, which artificially restricts the amount of storage you use. If you use short blocksizes, or long ones that just go over 1/2 track, you waste an awfull lot of space. Of course, well written SMS routines can correct that, but it still makes things a lot more complicated than it should be. Eric Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Ron Hawkins ron.hawkins1...@sbcglobal.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Tuesday, March 31, 2009 10:31 AM Subject: Re: A foolish consistancy or 3390 cyl/track architecture Perhaps there is more to the emulation of CKD than the thread touches on. Disk Drives stopped recording in CYLS some time ago because the time for head switching is greater than the minimum seek time. Drives today record in a serpentine method across the platters, doing a switch-back (best word I can think of) to the next head at intervals defined by the HDD designers. The whole idea of tracks and CYLS is really dead and buried as far as the real hardware is concerned. Ron -- 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: IBM Patents efforts to justify offshoring
I briefly read the patent application, and I notice that it doesn't seem to mention if the model includes back-testing / accuracy measurements. Hmmm. BTW: Rumor is that IBM has a massive supercomputing grid running a secret AI application called Blue Patent Shoes that automatically generates process / methods patents. On Tue, Mar 31, 2009 at 12:17 PM, Ed Gould ps2...@yahoo.com wrote: http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9130750source=NLT_PM (watch the wrap) March 30, 2009 (Computerworld) IBM last week filed a patent application for an offshore outsourcing methodology that is intended to help companies minimize the financial risks associated with sending work overseas. The patent application describes a computer-driven approach for putting values on both the quantitative and qualitative attributes of a global resource sourcing strategy. For instance, the methodology takes into account the language skills and morale of offshore workers, as well as a list of the hard numbers involved in setting up an offshore operation, including labor rates and currency valuations. In short, IBM is attempting to reduce offshoring considerations to a mathematic model — or, in the words of the application, a robust and reusable sourcing template for identifying and analyzing global resource pools. For IBM itself, the patent filing couldn't be any timelier. The company submitted the application to the U.S. Patent Trademark Office last Thursday, the same day it confirmed that it is eliminating more jobs in its North American operations. IBM didn't disclose any details about the planned cutbacks, but allia...@ibm, a union local that isn't recognized as an official bargaining unit, has said it expects between 4,000 and 5,000 workers to be let go. The union thinks the cuts are part of a plan by IBM to send more jobs overseas, following an earlier round of reductions in January. In the patent application, IBM said the described methodology allows decision-makers to conveniently trade off one or more qualitatively defined levels between one or more factors in terms of quantifiable, direct, costs. The methodology also looks at some scary assumptions as part of its mathematical models — scary, that is, if you're a U.S.-based IT worker. In a hypothetical assessment, the application sets up an example that includes a company having 50% of resources in China by 2010. Here's an example of the specific metrics that the methodology takes into account: Suppose that employees hired in country A possess level 1 communication skills, while employees in country B possess level 2 skills. Additionally, suppose that the job satisfaction of employees hired in country A is rated to be at level 2, while that of employees hired in country B is rated at level 1. In this case, a lower score implies higher job satisfaction. Since communication skill levels and job satisfaction levels can't be directly compared, it's useful to quantify in terms of cost the differences between the levels, both within the same factor and across different ones. The patent application explains why IBM thinks it's important to look at a broad range of variables when making global sourcing decisions. By simply looking at wages and material costs, the organization may indirectly increase other costs such as those associated with poorer quality workers and/or materials, IBM said. That could include loss of customers, lower productivity, increased product returns and higher worker attrition, the company said, adding that a company needs to consider both direct and indirect costs associated with its resources. This isn't the first time that IBM has filed for a patent related to an offshoring methodology. An application filed in 2007 described a software-driven approach for identifying at least a portion of a human-resource within an organization for outsourcing. -- 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
SMF70PMU question
Can anyone confirm if the SMF70PMU parameter in the RMF TYPE70 records is in service units? If not, what are the units? Seconds, milliseconds, widgets or what? Thanks, Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: SMF70PMU question
No, its an arbitrary number that has a maximum of 200 units which would be 20% of a general purpose CP. This would be in relation to blocked workloads and how much CP to give them to get them dispatched and serviced to possibly release resources being held by the blocker. --- On Tue, 3/31/09, Horne, Jim - James S jim.s.ho...@lowes.com wrote: From: Horne, Jim - James S jim.s.ho...@lowes.com Subject: SMF70PMU question To: IBM-MAIN@bama.ua.edu Date: Tuesday, March 31, 2009, 5:57 PM Can anyone confirm if the SMF70PMU parameter in the RMF TYPE70 records is in service units? If not, what are the units? Seconds, milliseconds, widgets or what? Thanks, Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: SMF70PMU question
Hi Jim, This is a count (the number of blocked dispatchable units being promoted during the interval). Best regards, Don ** Don Deese, Computer Management Sciences, Inc. Voice: (804) 776-7109 Fax: (8043) 776-7139 http://www.cpexpert.org ** At 12:57 PM 3/31/2009, you wrote: Can anyone confirm if the SMF70PMU parameter in the RMF TYPE70 records is in service units? If not, what are the units? Seconds, milliseconds, widgets or what? Thanks, Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: SMF70PMU question
Don, To make sure I understand what you are saying, it would be fair to say that the number is the number of elements promoted during the interval, right? Why does the SMF manual have to go out of its way to be confusing? (Don't bother answering that; it's a rhetorical questions.) Thanks, Jim Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Don Deese Sent: Tuesday, March 31, 2009 3:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF70PMU question Hi Jim, This is a count (the number of blocked dispatchable units being promoted during the interval). Best regards, Don ** Don Deese, Computer Management Sciences, Inc. Voice: (804) 776-7109 Fax: (8043) 776-7139 http://www.cpexpert.org ** At 12:57 PM 3/31/2009, you wrote: Can anyone confirm if the SMF70PMU parameter in the RMF TYPE70 records is in service units? If not, what are the units? Seconds, milliseconds, widgets or what? Thanks, Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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 NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: SMF70PMU question
Patrick, I appreciate the reply but I believe you have confused SMF70PMU with SMF70PMT. Thanks, Jim -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Falcone Sent: Tuesday, March 31, 2009 2:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF70PMU question No, its an arbitrary number that has a maximum of 200 units which would be 20% of a general purpose CP. This would be in relation to blocked workloads and how much CP to give them to get them dispatched and serviced to possibly release resources being held by the blocker. NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: SMF70PMU question
On Tue, 31 Mar 2009 14:48:52 -0400, Horne, Jim - James S jim.s.ho...@lowes.com wrote: To make sure I understand what you are saying, it would be fair to say that the number is the number of elements promoted during the interval, right? Why does the SMF manual have to go out of its way to be confusing? (Don't bother answering that; it's a rhetorical questions.) The SMF books says Number of blocked dispatchable units being promoted during the interval. What is confusing in that description? -- Horst Sinram IBM System z Capacity Management Workload Management -- 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: SMF70PMU question
The SMF books says Number of blocked dispatchable units being promoted during the interval. What is confusing in that description? I think the OP may be confused as to what it means. - 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: SMF70PMU question
unit is very ambiguous, especially considering how many different ways RMF uses it. Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Horst Sinram Sent: Tuesday, March 31, 2009 3:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF70PMU question On Tue, 31 Mar 2009 14:48:52 -0400, Horne, Jim - James S jim.s.ho...@lowes.com wrote: To make sure I understand what you are saying, it would be fair to say that the number is the number of elements promoted during the interval, right? Why does the SMF manual have to go out of its way to be confusing? (Don't bother answering that; it's a rhetorical questions.) The SMF books says Number of blocked dispatchable units being promoted during the interval. What is confusing in that description? -- Horst Sinram IBM System z Capacity Management Workload Management -- 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 NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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
Big Iron Bucks the Trend
More evidence of the recession-proof mainframe. You can see why CA is investing so heavily in developing Mainframe 2.0 ... http://www.ca.com/us/products/collateral.aspx?cid=192430 http://www.esj.com/articles/2009/03/31/Big-Iron-Bucks-Trend.aspx Compared to today, Big Iron shops a decade ago were hemorrhaging capacity. In 2000, roughly 3.5 million MIPS were installed on mainframe systems, according to CA Inc.; CA officials expect that customers will buy about the same amount of capacity this year alone. After a September of turmoil in the financial services sector, IBM Corp. officials also predicted a strong 2009 for Big Iron. http://www.schaeffersresearch.com/commentary/content/ibm+corp+soars+on+positive+2009+earnings+outlook/observations.aspx?click=homeID=90641 System z was the only one of IBM's four server businesses to post a year-over-year gain in revenues. In fact, Armonk's x86 server fortunes took a particular drubbing in Q4 of 2008, plunging by nearly one-third (30.5 percent, per Gartner's tally). The upshot, industry watchers say, is that far from transitioning away from Big Iron, customers seem to be doubling down. -- 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: A foolish consistancy or 3390 cyl/track architecture
On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld eric- ibmm...@wi.rr.com wrote: ... It just seems like IBM could get away from the track and cylinder stuff, which artificially restricts the amount of storage you use. If you use short blocksizes, or long ones that just go over 1/2 track, you waste an awfull lot of space. ... ... it still makes things a lot more complicated than it should be. I think that logic may not apply. It all depends on how the emulation works. The wasted track space may not take any space on the real hardware. We may be protected from our old stupidity (but I'm sure there is lots of new stupidity to make up for that). It's still complicated. Now you have to know which old guideleines still hold, which can be discarded, and what new guidelines are needed. 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: SMF70PMU question
If it said Number of blocked units being promoted during the interval. You would have a point, but since it states dispatchable units it removes the ambiguity. === Wayne Driscoll Omegamon DB2 L3 Support/Development wdrisco(AT)us.ibm.com === Horne, Jim - James S jim.s.ho...@lowes.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 03/31/2009 02:18 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: SMF70PMU question unit is very ambiguous, especially considering how many different ways RMF uses it. Jim Horne Systems Programmer Large Systems Engineering Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 jim.ho...@lowes.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Horst Sinram Sent: Tuesday, March 31, 2009 3:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF70PMU question On Tue, 31 Mar 2009 14:48:52 -0400, Horne, Jim - James S jim.s.ho...@lowes.com wrote: To make sure I understand what you are saying, it would be fair to say that the number is the number of elements promoted during the interval, right? Why does the SMF manual have to go out of its way to be confusing? (Don't bother answering that; it's a rhetorical questions.) The SMF books says Number of blocked dispatchable units being promoted during the interval. What is confusing in that description? -- Horst Sinram IBM System z Capacity Management Workload Management -- 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 NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: Big Iron Bucks the Trend
On Tue, 31 Mar 2009 12:22:47 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: ...After a September of turmoil in the financial services sector ... ... ...far from transitioning away from Big Iron, customers seem to be doubling down. ... Those customers left after the turmoil in the financial sector, that is. sigh 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: SMF70PMU question
If it said Number of blocked units being promoted during the interval. You would have a point, but since it states dispatchable units it removes the ambiguity. Maybe for people with English as a first language. It would probably read better as jobs/tasks/Units of Work. But, 'unit' is an over-used term in IBM-Speak. Rather than dunning somebody for 'being confused', we should be dunning the author for incomplete staff work. Remember, the purpose of clear communication is not to ensure you're understood. Rather, it's to ensure you're not mis-understood. Whenever I communicate something and the listener/reader claims mis-understanding, I don't condemn them. I attempt to clarify -- and, I KNOW I don't always succeed. - 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
OSA-ICC Concerns
We are looking to install two OSA cards to support two ICC OSC ports to handle our remote consoles. We have a z890 installed and my concern is when the CE applies maintenance to the OSC will this interrupt these active consoles? Are these OCS ports handled any differently from the OSD's in regard to maintenance by CE? Since I will have two OSC I can plan for the outage (if it exists) on one while running off the other. TIA, Rogers This E-Mail transmission (and/or the documents accompanying it) may contain information belonging to the sender which is confidential, privileged and/or exempt from disclosure under applicable law. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this E-Mail transmission in error, please immediately notify us by return E-Mail or telephone to arrange for return of its contents including any documents. -- 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: OSA-ICC Concerns
had same concerns...kept ce onsite..just incase to back off maint if needed...but so far--had applied (2) sets of maint...and no problems... -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- 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: A foolish consistancy or 3390 cyl/track architecture
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. patrick.oke...@wamu.net (Patrick O'Keefe) writes: I think that logic may not apply. It all depends on how the emulation works. The wasted track space may not take any space on the real hardware. We may be protected from our old stupidity (but I'm sure there is lots of new stupidity to make up for that). It's still complicated. Now you have to know which old guideleines still hold, which can be discarded, and what new guidelines are needed. cyl/track ckd architecture are left over from 1960s trade-offs ... cyl/track provided a direct 1:1 logical/physical correspondance so that uses (application developers) could wring every possible bit out of the infrastructure. ckd allowed for leaving information data structure indexes out on disk ... rathing than caching them in real-storage. this traded-off i/o channel, controller, and device thruput against extremely (much more) scarce and expensive real stroage. the ckd architecture trade-off was already shifting in by the mid-70s ... where bottleneck had significantly switched from being real storage to i/o thruput (and starting to see use of electronic storage for caching and/or staging information to compensate for the increasing bottlenecked i/o resources). I was being called into some number of severe thruput bottlenecked customer situations where the problem turned out how to minimize the use of PDS directory VTOC multi-track search. at the same time, the disk price/bit was drastically dropping ... so the cost effort to optimize every last bit of disk space was starting to cost more than the disk bits saved. FBA bascially addressed both issues; 1) it drastically simplified the logical structure users and application developers had to deal with and 2) eliminated the whole search infrastructure; recognizing that it was more efficient to cache/save high use data structures in electronic storage so that I/O read/write operations would directly specify required record. I was told that even if I provided fully developed, tested, and integrated MVS FBA support ... it would still cost (an additional) $26M to ship (changes to documentation, education, etc). Supposedly I had to show incremental revenue/sales as result of shipping MVS FBA support (i.e. on the order of $200m-$300m in incremental disk sales). The theory was customers were buying as much disk as they required and the only thing that MVS FBA support would provide would be the disks sold would be FBA rather than CKD (but no incremental sales). Any argument about infrastructure and long-term life-cycle savings with any MVS shift to FBA was discounted (as well as indirect sales because of simpler/faster development) I also was pontificating about how relative system disk thruput had dropped by factor of ten times over a period of yrs. Eventually some executive in the disk division asked their performance group to refute my statements. After several weeks, they came back and basically said that I had slightly understated the issue; i.e. disks may have gotten five times faster ... but with fewer arms and/or more data/arm to access, the avg. thruput per access (because of higher loading and queuing issues) was possibly only three times better. At the same time, processor had gotten possibly 50 times faster (processors 50 times faster, disks 5 times faster ... ratio of disk:processor thruput had declined by order of magnitude). Applications using 60s disk i/o techniques weren't able to keep the processors busy ... w/o heavy leveraging of electronic storage. In any case, the disk performance group turned the study around into a SHARE presentation recommending how to optimize disk configurations (basically attempting to mitigate the thrutput bottlenecks). In the meantime trying to get ECKD debugged and working as a subset solution for the multi-track search overhead ... was a monumental undertaking. lots of past posts mentioning ckd, multi-track search, fba, etc http://www.garlic.com/~lynn/submain.html#dasd semi-related, misc. past posts mentioning getting to play disk engineer in bldg 14 (disk engineering) bldg 15 (disk product test). http://www.garlic.com/~lynn/subtopic.html#disk then as all physical disk technology shifted to FBA ... there was another major effort required to continue to emulate CKD infrastructure on top of an underlying infrastructure that is fundamentally FBA. slightly related to the technology paradigm trade-off CKD/FBA shift was the discussions in the '70s between the STL IMS group and SJR system/r relational database group (original relational/sql) http://www.garlic.com/~lynn/submain.html#systemr The IMS group position was that direct record pointers as part of the data infrastructure required half the disk space as System/R (relational, later sql/ds, db2, etc) and significantly fewer disk i/os. Basically the internal index structure used by
Re: A foolish consistancy or 3390 cyl/track architecture
You may be right, but from your reply you apparently don't know for sure whether bad blocksizes actually take up more dasd or not. Does anyone know whether this affects the total amount of dasd or not that can be used? I would think that since you have to define the dasd on a new box, that once it is defined and all used, that you would have the potential for so many TB, but the actual data that you store would still be affected by blocksizes. I know when I was at Washington University, we got a new Shark that had 15TB (I think), and was triple the capacity of the old one. I know we defined all the dasd that we had defined on the old one, and then set up a whole new copy of everything. We then flashed everything (5TB), which took less than a minute, although the under the cover copying took a lot longer. We still had 5TB left, which they were using up for DB2 stuff when my contract ended. I suspect that once another 2.5TB was defined, and its mirror image to be flashed was defined, that no more dasd could be defined, but I don't know that for sure. Eric Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Patrick O'Keefe patrick.oke...@wamu.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Tuesday, March 31, 2009 2:22 PM Subject: Re: A foolish consistancy or 3390 cyl/track architecture On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld eric- ibmm...@wi.rr.com wrote: ... It just seems like IBM could get away from the track and cylinder stuff, which artificially restricts the amount of storage you use. If you use short blocksizes, or long ones that just go over 1/2 track, you waste an awfull lot of space. ... ... it still makes things a lot more complicated than it should be. I think that logic may not apply. It all depends on how the emulation works. The wasted track space may not take any space on the real hardware. We may be protected from our old stupidity (but I'm sure there is lots of new stupidity to make up for that). It's still complicated. Now you have to know which old guideleines still hold, which can be discarded, and what new guidelines are needed. 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
StandAlone DSS restore, is FILE(xxx) tape mark ?
Been a while since I did stand alone DSS restores. I see that DSS now has a FILE parameter which can specify the file number from the beginning of the tape. I would assume the number is tape marks, ie with standard label tape file 1 would be FILE(2). Does anyone know, rather than guess like I did? Additionally does anyone know if DSS rewinds the tape before/after a RESTORE, so that FILE would be from the start of the tape or does it try to keep track of where it's at? I assume the best thing will be to use the TAPECNTL directive to be sure. TIA 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: A foolish consistancy or 3390 cyl/track architecture
On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote: You may be right, but from your reply you apparently don't know for sure whether bad blocksizes actually take up more dasd or not. Does anyone know whether this affects the total amount of dasd or not that can be used? When I worked at Wayne State University in Detroit, we bought an RVA. That was IBM's re-branded Iceberg. AFAIK, Sun also sells it as the SVA. On that box, all data stored on disk was compressed. Because any new data written to a track may not fit in the same location, every time data on a track was written, the track was written to a new location, and only the disk space required for the compressed data was used. There was a special utility used to report on how much of the back-end disk storage was used. IIRC, it was called Net Capacity Load. Allocating another volume or creating a snapshot did not increase the NCL. The micorcode has garbage collection routines that accumulate track areas that are no longer used and background tasks that move data around in order to maintain a contiguous area where new tracks can be written. It is a marvelous feat of engineering. And it is no wonder that the Iceberg was so much later getting to markket than originally planned. In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. I suppose you might ask why the disk can't store more short blocks on the track, reducing (or eliminating) the inter-record gap. But then, it wouldn't behave like a 3390, would it? What might that break? -- Tom Marchant -- 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: A foolish consistancy or 3390 cyl/track architecture
Tom Marchant wrote: In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. We grew a couple of our 3390s from just under 64K cylinders to 220K cylinders with a single click on the DS8100's HMC. There was no need to copy data from device X to device Y. Device X simply grew in place while it was still on-line to z/OS. Either way, there must be some serious virtualization going on to make that possible. -- 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: A foolish consistancy or 3390 cyl/track architecture
Tom, I don't think you answered my question. I remember a year or two before we built our datacenter that opened in 1996, we looked at getting the STC box (Now STK). I read a lot about it the time, but in the end we didn't get one. What you wrote below I remember, especially the compression, and writing all new and updated data in a new location. BUT, you define so many volumes. Once you have them defined, and all of the space is allocated, you can't add volumes because they are blocked better, or delete volumes because you just wrote a couple huge files blocked at 150 bytes per block. That just doesn't make sense. (I hope this makes sense!) When we built the PH datacenter, we added a bunch of 3380 and 3390 strings. I never quite understood why we didn't go with the new technowlogy, but they were cheap - at least the purchase price. I don't know if they saved any money after maintenance though. We totally filled up the datacenter with all the dasd. Later, when we got a Hitachi box, and replaced the 3090S with a MP3000, we had a good sized ballroom available. Eric Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Tom Marchant m42tom-ibmm...@yahoo.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Tuesday, March 31, 2009 5:23 PM Subject: Re: A foolish consistancy or 3390 cyl/track architecture On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote: You may be right, but from your reply you apparently don't know for sure whether bad blocksizes actually take up more dasd or not. Does anyone know whether this affects the total amount of dasd or not that can be used? When I worked at Wayne State University in Detroit, we bought an RVA. That was IBM's re-branded Iceberg. AFAIK, Sun also sells it as the SVA. On that box, all data stored on disk was compressed. Because any new data written to a track may not fit in the same location, every time data on a track was written, the track was written to a new location, and only the disk space required for the compressed data was used. There was a special utility used to report on how much of the back-end disk storage was used. IIRC, it was called Net Capacity Load. Allocating another volume or creating a snapshot did not increase the NCL. The micorcode has garbage collection routines that accumulate track areas that are no longer used and background tasks that move data around in order to maintain a contiguous area where new tracks can be written. It is a marvelous feat of engineering. And it is no wonder that the Iceberg was so much later getting to markket than originally planned. In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. I suppose you might ask why the disk can't store more short blocks on the track, reducing (or eliminating) the inter-record gap. But then, it wouldn't behave like a 3390, would it? What might that break? -- Tom Marchant -- 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: A foolish consistancy or 3390 cyl/track architecture
On Tue, 31 Mar 2009 17:50:08 -0500, Eric Bielefeld wrote: I don't think you answered my question. I remember a year or two before we built our datacenter that opened in 1996, we looked at getting the STC box (Now STK). I read a lot about it the time, but in the end we didn't get Actually, now Sun (or SMI). Never was STK officially. There were trademark problems with STC (England's Standard Telephone and Cable); STK was the NYSE stock ticker symbol (like JAVA?), and unlikely to be better, like any other TLA. The branding directives were to use StorageTek, not STK. But keystroke economy often prevailed. one. What you wrote below I remember, especially the compression, and writing all new and updated data in a new location. BUT, you define so many volumes. Once you have them defined, and all of the space is allocated, you can't add volumes because they are blocked better, or delete volumes because you just wrote a couple huge files blocked at 150 bytes per block. That just doesn't make sense. (I hope this makes sense!) When we built the PH datacenter, we added a bunch of 3380 and 3390 strings. I never quite understood why we didn't go with the new technowlogy, but they were cheap - at least the purchase price. I don't know if they saved any money after maintenance though. We totally filled up the datacenter with all the dasd. Later, when we got a Hitachi box, and replaced the 3090S with a MP3000, we had a good sized ballroom available. - Original Message - From: Tom Marchant m42tom-ibmm...@yahoo.com Sent: Tuesday, March 31, 2009 5:23 PM In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. You can't quite get there; you still have the overhead of metadata showing where the interblock gaps appear to be. But if the metadata are subject to compression, LZH may make them nearly vanish -- e.g. the BDWs for equal 150 byte blocks (above) are identical and highly redundant. I suppose you might ask why the disk can't store more short blocks on the track, reducing (or eliminating) the inter-record gap. But then, it wouldn't behave like a 3390, would it? What might that break? Lots of things, people say. But the answer should be FBA, not virtualizing CKD. And FBA should be highly compatible with anything with its own abstraction layer, such as VSAM, PDSE, z/FS, etc. And with paging, which has no user API to low-level I/O, thus with VIO. -- 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: A foolish consistancy or 3390 cyl/track architecture
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Tuesday, March 31, 2009 5:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A foolish consistancy or 3390 cyl/track architecture On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote: Snip When I worked at Wayne State University in Detroit, we bought an RVA. That was IBM's re-branded Iceberg. AFAIK, Sun also sells it as the SVA. On that box, all data stored on disk was compressed. Because any new data written to a track may not fit in the same location, every time data on a track was written, the track was written to a new location, and only the disk space required for the compressed data was used. There was a special utility used to report on how much of the back-end disk storage was used. IIRC, it was called Net Capacity Load. Allocating another volume or creating a snapshot did not increase the NCL. The micorcode has garbage collection routines that accumulate track areas that are no longer used and background tasks that move data around in order to maintain a contiguous area where new tracks can be written. It is a marvelous feat of engineering. And it is no wonder that the Iceberg was so much later getting to markket than originally planned. In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. SNIP Wouldn't this effectively defrag DASD units? But then we would still have to run some kind of defrag just to fix the VTOC (so it wouldn't have so many extent entries for data sets), right? Regards, Steve Thompson -- Postings by this poster may not reflect the views or opinions of poster's employer. -- -- 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: A foolish consistancy or 3390 cyl/track architecture
Bill, No moving parts doesn't mean they don't wear out. There's a lot of redundant capacity in those babies to handle cell failures due to writes. This is why you'll see Flashdrive articles talk about wear leveling algorithms, and also one of the reasons why you won't see Enterprise Flashdrives on the shelf at Frys. They do have huge potential to provide greener high performance, especially in environments where short stroking of the HDD is the norm and I'm sure customer acceptance will bring the price down from the current premium. I'm not sure about your access time comments. So far the performance I have seen is very impressive. Can you elaborate? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Tuesday, March 31, 2009 10:56 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] A foolish consistancy or 3390 cyl/track architecture The Flash Drive concept makes the most sense - no moving parts. The geometry is emulated by the microcode. They just need to get the access time lower. Bill Fairchild Rocket Software From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Tuesday, March 31, 2009 1:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A foolish consistancy or 3390 cyl/track architecture Ron, Thanks for clearing up how the current drives actually work. It just seems like IBM could get away from the track and cylinder stuff, which artificially restricts the amount of storage you use Eric Eric Bielefeld -- 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 Charge Back Software
Jim Marshall brings up a good point. If you were going to implement chargebacks -- insert long discussion here about the perils of bad chargeback regimes -- why would you only charge for mainframes? Aren't there at least clients (PCs, Macs, handhelds, etc.) and networks, for example? Those certainly aren't free. Shouldn't the title of this thread be Enterprise Charge Back Software or Enterprise-Integrated Mainframe Charge Back Software? - - - - - 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
Re: OSA-ICC Concerns
You will have no unplanned disruption to your consoles due to microcode maintenance installed by your CE using the concurrent microcode update process. OSC ports are just one type of OSA port. All OSA ports work the same as far as microcode maintenance is concerned. When the CE installs maintenance, the code changes for each OSA port are pending until each OSA CHPID is individually configured offline to all LPARs. For this to work, the OSA CHPID has to be offline to every LPAR simultaneously. Then, when the CHPID is configured back online to the first LPAR, the pending OSA microcode update is loaded. Until you take overt action to activate the microcode on each OSA port individually, the microcode changes will remain pending - for weeks/months/years, if you never take action. I don't have z890, but on z9 and z10, there is a task on the SE called something like Display Pending OSA/Crypto Changes which lists each OSA CHPID which has microcode updates that are pending this configure off/on process, so that you can keep track of them. To find this task, either use the SE directly, or use Single Object Operations on the HMC to logon to the SE - the task is not on the HMC, as far as I know. The general idea is to have redundant OSA ports configured, and then during a planned time, take the outage for each OSA port one at a time at your convenience. A Power On Reset will also activate any pending changes as well, with the obvious disruption to the entire box. The big hammer, if you will. Brian On Tue, 31 Mar 2009 14:43:31 -0500, Laine, Rogers wrote: We are looking to install two OSA cards to support two ICC OSC ports to handle our remote consoles. We have a z890 installed and my concern is when the CE applies maintenance to the OSC will this interrupt these active consoles? Are these OCS ports handled any differently from the OSD's in regard to maintenance by CE? Since I will have two OSC I can plan for the outage (if it exists) on one while running off the other. TIA, Rogers -- 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: secure file transfer FROM z/OS
Kirk has some good information on file transfer options using common protocols. I've got some more nominees which may be appropriate if you have long running, targeted file transfer needs -- such as a small number of particular servers that need to stay more-or-less permanently attached and transfer a lot of files. Basically the other options would all be file sharing (NFS, CIFS/SMB, etc.) over an IPSec connection (encrypted connection). z/OS supports IPSec and also supports common network file systems like NFS, CIFS/SMB, etc. As Kirk alluded to, there are also numerous private protocol file transfer products, and they do have advantages in many missions. By the way, secure file transfer is a misnomer when used as we're using it here. To be more accurate for the (business-oriented/risk-analyzing) boss I would call this encrypted transfer of raw files without custodial controls. (That name is unwieldy, but it's much closer to the truth. Perhaps someone has a shorter name that still gets the point across.) The file itself could (and usually does) contain extremely sensitive information -- things like customer records, credit card numbers, etc. Once each record is transmitted it leaves the security zone of its parent. To use an analogy, if you have the launch codes for nuclear missiles, yes, it's a good idea if you have to communicate that information to use an encrypted pipe. That's necessary but not sufficient. (The only thing encryption does is prevent somebody from intercepting the file data over the wire.) You better be completely sure both sender and receiver apply appropriate security protocols to such sensitive information. Which is why launch codes don't get spread around a lot, nor should credit card numbers and much other financial information, medical patient records, corporate accounting (in any business), product design secrets, etc. - - - - - 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
