Re: We're losing the battle
Pat O'Keefe writes: >The improved SLA on the back-end is anything but "free". The >improved SLAs come only when the applications are redesigned to >take advantage of the improved availability of the underlying >platforms. Multiple applications that share a redesigned >component may get some shared improvements in SLA but only >when the shared component is the SLA's problem child. OK, but there are many occasions, probably particularly on mainframes, when the shared component(s) is(are) the problem child(ren). You're saying there are exceptions -- sure, that's true. But >Adding continuous availability to large applications (or systems >of applications) that weren't designed around the concept takes >a lot of time and effort (read "money"). And a lot of banks aren't >too free with their money right now. An existing solution (even >when based on antiquated technology) has strong appeal in the >current financial climate. It's all comparative. Highly available front-ends are not cheap, and they only offer degrade mode customer service anyhow. As a *general rule*, it is better to spend money once (in one logical place) on highly available infrastructure to deliver high SLAs rather than spend in multiple channels. If reasonably possible, which it usually is. You're saying there are exceptions. Yes, true, no disagreement. You can also smoke tobacco and live past 100. :-) But I really, really don't think this is any sort of radical notion. Let's look at GDPS as one small example. Once an organization implements GDPS, how much does it cost to protect one more 3390-XX volume? Almost nothing is the correct answer, in general. Once you configure one MQ shared queue in the Coupling Facility, how much to configure the second one? Also almost nothing, in general. And so on. It just makes tons of economic sense -- IN GENERAL -- to establish the highly available infrastructure to deliver high SLAs once, then share it as much as possible. To pick an analogy, if you ran a hospital, would it make economic sense to buy standby electrical systems (such as UPS batteries) for each and every piece of critical medical equipment, or would it make better sense to buy one backup generator for the entire hospital? Unless you're a very small hospital, of course it's the latter. (And yes, you might have some rewiring to do in the hospital, but it still makes perfect sense.) And once you've got the backup generator, the cost for that backup service when you plug in another heart monitor is negligible. This is also reason #684 why crafting an accurate and meaningful chargeback regime is hard. Sharing makes overall economic sense to the organization, but imagine levying chargebacks equally for HA services across all users. Users vary in how much they value such services, and the costs of delivering those services are dramatically different after the first user. In theory a rational administrator could charge a much lower rate to certain users *and* collect more total money to fund shared HA services. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
[EMAIL PROTECTED] (Timothy Sipples) writes: > Whether you're seeing these particular trends at your bank or not is > interesting, but from an industry view I think this is a reasonable (and > unsurprising) generalization. (Certainly the biggest application provider > in this market, ACI Worldwide, recognizes these trends.) And you shouldn't > be surprised when you start to see these trends hitting your bank in the > coming years if they haven't already. There's an awful lot of pressure in > the banking industry to gain efficiencies, reduce costs, and improve > service levels. re: http://www.garlic.com/~lynn/2008j.html#10 We're losing the battle for some other topic drift ... a couple recent posts (from a.f.c) about implementation of ATM machine support on VM/CMS platform in the 70s (references to getting higher thruput than acp/tpf implementation on the same hardware) http://www.garlic.com/~lynn/2008j.html#13 http://www.garlic.com/~lynn/2008j.html#15 also had more recent experience earlier in this decade involving modifications to ATM network processing for (NACHA) processing trials ... for (AADS) debit card transactions http://www.garlic.com/~lynn/x959.html#aads ... on the internet. The NACHA RFI response was submitted for us by somebody else, because we weren't members of NACHA http://www.garlic.com/~lynn/nacharfi.htm report on the result of the trials can be found here (23july2001) ... describing some of the processing modifications to support the trials of doing debit transactions over the internet http://internetcouncil.nacha.org/News/news.html indirect reference in article in mar/apr 2005 ibm systems magazine article (although some of the info is slightly garbled) http://www.ibmsystemsmag.com/mainframe/marchapril05/stoprun/10020p1.aspx included some amount of working with ACI. other posts in this thread: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle http://www.garlic.com/~lynn/2008j.html#7 We're losing the battle http://www.garlic.com/~lynn/2008j.html#16 We're losing the battle http://www.garlic.com/~lynn/2008j.html#17 We're losing the battle for other drift, some old ACP/TPF related email http://www.garlic.com/~lynn/2008i.html#email800325 in this recent post http://www.garlic.com/~lynn/2008i.html#39 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Fri, 27 Jun 2008 15:03:20 +0900, Timothy Sipples <[EMAIL PROTECTED]> wrote: >... >So if you improve the SLA for one class of applications, you're probably >also improving it for others, and the others get the improvements >essentially for free. ... Then it becomes tough for any >business to justify spending money on a front-end when the >improved SLA on the back-end is "free." >... The improved SLA on the back-end is anything but "free". The improved SLAs come only when the applications are redesigned to take advantage of the improved availability of the underlying platforms. Multiple applications that share a redesigned component may get some shared improvements in SLA but only when the shared component is the SLA's problem child. Adding continuous availability to large applications (or systems of applications) that weren't designed around the concept takes a lot of time and effort (read "money"). And a lot of banks aren't too free with their money right now. An existing solution (even when based on antiquated technology) has strong appeal in the current financial climate. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
R.S. asks: >.Gentlemen, >I'm getting lost. >What does it mean "front end switch"? The common vernacular in this particular field is to describe that front-end system as an "ATM switch" (for example). "Switch" should not be taken *too* literally, though. But "transaction processing" is a bit too strong, generally speaking, so it's not a good term either. (I prefer something like "front-end queuing system," but there's probably no perfect term.) The system of record with the "correct" bank balance is the back-end. Basically if the back-end is down the front-end stands in to provide a more limited set of services. (That "negative file" described elsewhere in this thread is an excellent example.) There might also be a lower withdrawal limit, funds transfer between accounts may not be available, account balances might not be available, etc. Some organizations refer to this reduced service set as "degrade mode." (We used to describe a bank branch that way when the network connection to the home office was down -- degrade mode would apply, and the teller could provide up to maybe $100 in cash per customer. The branch IT systems and back office systems were engineered to work around the unreliable network connections.) When the back-end comes back up it works with the front-end to reconcile whatever happened during the outage. That probably means some account holders have overdrawn their accounts, and so part of the reconciliation includes getting those accounts over into whatever exception processing the bank has in such cases. There's also probably more fraud, so that falls into another exception bucket. Now it's not THAT hard for a bank to move away from a physically separate front-end toward a logical (virtualized) one. I've pointed out earlier the many reasons driving the trend to simplify. Another one is that this ATM switch function is peculiar to one channel. Banks and other financial service companies are seeing their channels multiply. So they can either buy more front-ends -- which have always been a second-best option even in the best of circumstances anyway. Or they can improve their back-ends to deliver something much closer to continuous service. Or at least they can place the front-ends logically on shared, highly available infrastructure rather than maintain separate boxes with alien software. If the only high service level business involves the ATM cards, that's one thing. But that's not a good description for modern, integrated banking in most countries, and it certainly isn't the trend. Said another way, if the global trading applications for stock exchanges require 24 hour SLAs -- and an awful lot of banks have global investment arms -- what good does it do for those applications to have a front-end ATM switch? Absolutely nothing of course -- a channel-specific switch offers no benefit to other business channels -- and the only value the ATM switch provided was to fix the SLA for core banking, and only for a limited set of services, and only with higher rates of exception (read: more expensive) processing. So if you improve the SLA for one class of applications, you're probably also improving it for others, and the others get the improvements essentially for free. (Well, this is true for IBM mainframes. It's much, much less true with distributed systems.) Then it becomes tough for any business to justify spending money on a front-end when the improved SLA on the back-end is "free." Whether you're seeing these particular trends at your bank or not is interesting, but from an industry view I think this is a reasonable (and unsurprising) generalization. (Certainly the biggest application provider in this market, ACI Worldwide, recognizes these trends.) And you shouldn't be surprised when you start to see these trends hitting your bank in the coming years if they haven't already. There's an awful lot of pressure in the banking industry to gain efficiencies, reduce costs, and improve service levels. The alternative I suppose is that you could shift the back-end logically over to the front-end. But in the case of IBM System z and HP NonStop, the back-end is a heck of a lot bigger with a far richer function set. System z is a broad scope application hosting environment for general business applications using an increasingly wide variety of middleware, programming languages, run-times, etc. That just isn't HP NonStop: never was, and, with each passing year, ever decreasing. So if (when?) you're going to move one side to the other, there's only one realistic direction here. Make sense? I really don't think this is surprising or that this line of thought is particularly profound. It's just common sense. I don't think this is even surprising to HP, which seems to be attempting to reposition HP NonStop in the role of a front-end queuing system for distributed systems, to fix SLAs for a limited set of services using a dual-platform strategy. Of course you can do that with a System z mainframe,
Re: We're losing the battle
> I suspect that "switch only" is simply a way of depreciating the > solution, because it's not mainframe. Not at all. I hear the term "switch" used all day, every day regardless of which platform it's on. Some switches do nothing but switch transactions but most seem to do a lot more. > Date: Thu, 26 Jun 2008 20:27:02 +0200 > From: [EMAIL PROTECTED] > Subject: Re: We're losing the battle > To: IBM-MAIN@BAMA.UA.EDU > > J R wrote: > > This is not unique to Tandem. It's a function of "front end switches". > [...] > > Gentlemen, > I'm getting lost. > What does it mean "front end switch"? > IMHO "the switch" does AT LEAST the following: > - maintains all the communication to ATMs and POSes. > - checks the PIN and the quote > - maintains customers balance (subtract the quote) > > This is *transaction processing system*, not "a switch". > > I suspect that "switch only" is simply a way of depreciating the > solution, because it's not mainframe. > It's simply unfair. Since it's "switch function" only, it is so trivial, > then why it wasn't on mainframe? > > Did I miss the point? > > -- > Radoslaw Skorupka _ The i’m Talkathon starts 6/24/08. For now, give amongst yourselves. http://www.imtalkathon.com?source=TXT_EML_WLH_LearnMore_GiveAmongst -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
J R wrote: This is not unique to Tandem. It's a function of "front end switches". [...] Gentlemen, I'm getting lost. What does it mean "front end switch"? IMHO "the switch" does AT LEAST the following: - maintains all the communication to ATMs and POSes. - checks the PIN and the quote - maintains customers balance (subtract the quote) This is *transaction processing system*, not "a switch". I suspect that "switch only" is simply a way of depreciating the solution, because it's not mainframe. It's simply unfair. Since it's "switch function" only, it is so trivial, then why it wasn't on mainframe? Did I miss the point? -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 26 Jun 2008 08:43:40 -0700, [EMAIL PROTECTED] (Richards, Robert B.) wrote: >Some banks were trying to change off of Tandem, but a major banking >software vendor bought an "up and coming" Linux on System z solution and >essentially killed it in favor of their own, dated technology. I just want the two-handled mugs that Tandem gave people. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Some banks were trying to change off of Tandem, but a major banking software vendor bought an "up and coming" Linux on System z solution and essentially killed it in favor of their own, dated technology. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of J R Sent: Thursday, June 26, 2008 11:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle This is not unique to Tandem. It's a function of "front end switches". It's just that Tandem is the traditional platform of choice for this function. It's hard to convince banks to change from a long standing solution. However, new installations are adopting other alternatives. As I said before, it's not to cover for unavailability of the IBM platform. Rather, it's to stand-in for the unavailability of the "back end application", regardless of what platform it's running on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
This is not unique to Tandem. It's a function of "front end switches". It's just that Tandem is the traditional platform of choice for this function. It's hard to convince banks to change from a long standing solution. However, new installations are adopting other alternatives. As I said before, it's not to cover for unavailability of the IBM platform. Rather, it's to stand-in for the unavailability of the "back end application", regardless of what platform it's running on. > Date: Thu, 26 Jun 2008 09:01:11 -0500 > From: [EMAIL PROTECTED] > Subject: Re: We're losing the battle > To: IBM-MAIN@BAMA.UA.EDU > > I currently work for a bank the uses a Tandem for wire transfer > processing, not as an ATM front end. In a previous life I worked for a > bank that used the Tandem for both of those functions. One thing with > the ATMs is the penalties that are charged by the companies that do the > interbank communications. When one of your banking customers uses their > card in another bank's ATM then companies like Interlink and PLUS get > involved to check their account at your bank and validate balances, etc. > If you're down for even a little while and they can't make that check > then you can get hit with some horrendous penalty charges. At my > previous employer there was a negative file in the Tandem. If the > mainframe was out of service for something like an IPL or IML, then the > Tandem would check the negative file. If the account was in that it was > a no go on the transaction. Otherwise there would be a set minimum > amount the customer could withdraw. That way, as far as Interlink or > PLUS were concerned, we were up and running. > > > _ Introducing Live Search cashback . It's search that pays you back! http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=introsrchcashback -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> I have no idea what's going on in the banking industry in general,; > maybe reliance on Tandem is decreasing. But I see no move at this > bank to move away from them. Our move towards higher availability > has next to nothing to do with ATM support (Tandem's forte); it is > driven by online banking support. I suspect that the ATM support > will eventually start taking more advantage of the mainframe's high > availability, but, as I said in a previous posting, the platform's > availability has little to do with the need for something like Tandem. > It's the applications; it's maintenance of the databases; etc. The > HA front ends for ATMs allow near continuous ATM availability for > customers without having to go though major costly redesigns > and reprogramming. > > Bank IT deparments are pretty conservative in general, and the > current financial environment isn't likely to inspire major changes. > I suspect you will not see many banks that currently use Tandems > stop using them because of high mainframe availability. I'd bet > more on seeing IT staffs being cut, development put on hold, and > greater dependance being put on whatever is in place right now. > > Pat O'Keefe > I currently work for a bank the uses a Tandem for wire transfer processing, not as an ATM front end. In a previous life I worked for a bank that used the Tandem for both of those functions. One thing with the ATMs is the penalties that are charged by the companies that do the interbank communications. When one of your banking customers uses their card in another bank's ATM then companies like Interlink and PLUS get involved to check their account at your bank and validate balances, etc. If you're down for even a little while and they can't make that check then you can get hit with some horrendous penalty charges. At my previous employer there was a negative file in the Tandem. If the mainframe was out of service for something like an IPL or IML, then the Tandem would check the negative file. If the account was in that it was a no go on the transaction. Otherwise there would be a set minimum amount the customer could withdraw. That way, as far as Interlink or PLUS were concerned, we were up and running. * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 25 Jun 2008 12:42:40 -0700, [EMAIL PROTECTED] (Gibney, Dave) wrote: > We now live in a world (z or Wintel or *nix) where downtime does not >have to visibly happen. And customers are permitted to and should insist >on 24/7 service. But the other fact is everyone (well almost) has a >Window$ workstation on their desk that many reboot every day, and >certainly (if updates are properly being applied) doesn't stay up more >than a week or two. The person in the next cubicle had a hard disk crash the other day. She basically used it as a workstation to access the MF and the Unix box - but she was dead in the water for several days. The mind set in most shops does not include making full backups of their PCs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 25 Jun 2008 12:56:09 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: >Nothing will beat the MF in terms of overall performance. That's like saying nothing will beat a cargo ship or train or 18 wheeler in terms of overall performance. But the measure of "overall performance" depends on our goals. I notice that the rising cost of oil have a variety of effects on how we transport things. Trains are getting more use relative to trucks. But we are also building greenhouses to redefine the problem of getting groceries from far away farmland to here. Same thing happens as our security, privacy, and even energy needs change how we do IS. And of course, size. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>... >>Back in the day, Tandem was the dominant fault-tolerant platform. >>However, for almost two decades, sysplex technology has given >>mainframes fault tolerance that Tandem can only dream of. >>So, it's not that Tandem's front end value is lessening but that >>they are no longer the only game in town. > >I do think Tandem (HP NonStop) front-end value is lessening >because of decisions HP and especially software vendors have > made recently. But I think you're exactly right about the fact >that, if you have a highly available IBM mainframe backend, >why do you still need a special queuing front-end? Quite >simply you don't, and that's been the trend, to edit and >to simplify for several reasons. >... I have no idea what's going on in the banking industry in general,; maybe reliance on Tandem is decreasing. But I see no move at this bank to move away from them. Our move towards higher availability has next to nothing to do with ATM support (Tandem's forte); it is driven by online banking support. I suspect that the ATM support will eventually start taking more advantage of the mainframe's high availability, but, as I said in a previous posting, the platform's availability has little to do with the need for something like Tandem. It's the applications; it's maintenance of the databases; etc. The HA front ends for ATMs allow near continuous ATM availability for customers without having to go though major costly redesigns and reprogramming. Bank IT deparments are pretty conservative in general, and the current financial environment isn't likely to inspire major changes. I suspect you will not see many banks that currently use Tandems stop using them because of high mainframe availability. I'd bet more on seeing IT staffs being cut, development put on hold, and greater dependance being put on whatever is in place right now. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-- On the one hand I hear that nothing beats the MF for reliability, security, recoverability, and so on. Then I hear people telling me not be so sure about that. So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? In my not-so-humble opinion: Nothing will beat the MF in terms of overall performance. No business runs on strictly compute-bound or strictly I/O bound code; the mixture may vary but both capabilities are important to the business. While many desktops can compute with awesome speed today, they can't do large volumes of I/O in anything approaching a reasonable time frame. The MF can do thusands of I/O's per second, via multiple channels, but MIGHT not be quite as fast for a purely compute-bound program. Wake me up, if you can, when the non-MF platforms can multi-task with literally thousands of tasks and still get reasonable work done in a reasonable time frame. And whether we like it or not, the MF still has very high reliability, excellent security and a pretty D*** high degree of recoverability. And we've had 40+ years of practice in making improvements in all those areas. (I've seen as many as 4,000 Virtual Machines running in a VS/CMS environment and all were still getting sub-second terminal response time for trivial transactions! On a single 370/168!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
As the OP, I'm sorta inclined to resent this, but I know I was just whining some. Although I think zBoxes and z/OS plus zLinux are the no brainer way to go, I also recognize I am a pro mainframe bigot. My underlying concern, which I related in a later post is the real point. We now live in a world (z or Wintel or *nix) where downtime does not have to visibly happen. And customers are permitted to and should insist on 24/7 service. But the other fact is everyone (well almost) has a Window$ workstation on their desk that many reboot every day, and certainly (if updates are properly being applied) doesn't stay up more than a week or two. This leads to the mindset that downtime is acceptable. And maybe it is for many(most) applications. I don't include financial in that group, and I certainly don't include any related to public safety (Police, Fire, etc) in the group. I've always appreciated Ron's wise words in these fora, hope he doesn't take this personal :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ron Hawkins > Sent: Tuesday, June 24, 2008 9:22 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: We're losing the battle > > Bruno. > > This thread, as with many on this topic, starts out with the assumption > that > UNIX, LINUX and Windows Server Operating Systems, along with server class > hardware are no different to the Home PC they loaded up with Windows XP > in > order to play Warcraft, or the laptop they use for email and terminal > emulators. It only goes downhill from there. > > It gets even more ridiculous when Linux is suddenly an anointed HA OS > simply > because it will run on an IBM Mainframe, along with Solaris and pre-RISC > AIX. I have not figured that out yet. > > As Radoslaw said, "I love Mainframes but I'm not blind." Those that wish > to > make a valid comparison between z/OS and other HA OS need to get their > noses > out of Windows and have a look at how HA is being done on other SERVER > Operating Systems. In many cases it is not platform that provides the HA, > but rather an application running on the OS like Veritas Cluster Server or > HACMP. These HA applications won't even run on XP. > > And what I would give for backup software like Commvault or Netbackup on > the > Mainframe. Backup on Open System Server software is Light years ahead of > anything on the MF, whether it's IBM or ISV software. It's like comparing > a > Ferrari to the first stone wheel... > > I like to take a wider view than the lint in my belly button... > > > Ron > > PS For those that WOW, I'm a level 63 Human Warrior :) > > > > > > Thank you Ron > > I was feeling alone . > > i have been sometimes pulling out applications from mainframe in my > > shop and > > applied all good recipes from centralised processing > > ( dual computer rooms , dual replicated storage bays for dasds , dual > > network, load balancing , dual tape robotics and even ESX vmware to > > drag > > and drop servers on the fly) > > And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS > > linux , Windows data servers , AIX applications , etc ... ) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Bruno Sugliani wrote: agreed 100% i would add that our 19000 inhouse cobol programs do not leave much alternative than to hope for a big life expectancy for our mainframe In some cases the choice is that there is no choice . be it cobol or some fancy software running only on some fancy OS for some fancy department . Ah, so do you need some training to keep your staff up to date on new features / options of COBOL? Or that fancy z/OS UNIX System Services? [Of course, it would have to be in English, although I'd be happy to work with an interpreter. Maybe someone on ibm-main would volunteer. :-) ] Bruno Sugliani zxnetconsult(at)free(dot)fr On Wed, 25 Jun 2008 07:38:49 -0600, Howard Brazee <[EMAIL PROTECTED]> wrote: On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve Comstock) wrote: What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Evaluate your needs and wants, compare them with the costs involved - just as you do with any other purchase. Some people compare computers with transportation. Sometimes a cargo ship is the best solution, other times, trains, large trucks, small trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling work better for particular tasks. Each tool has different standards, different costs, different strengths, and different weaknesses. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques ==> Check out the Trainer's Friend Store to purchase z/OS <== ==> application developer toolkits. Sample code in four<== ==> programming languages, JCL to Assemble or compile, <== ==> bind and test. <== ==> http://www.trainersfriend.com/TTFStore/index.html<== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Steve Comstock wrote: [...] So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? Two reasons: 1. Applications they use run on mainframes only. 2. For the same reason why Englishmen drive on left side. The change is risky and costly. Where are NEW customers of mainframe and z/OS? We sometimes see messages about "another mainframe switched off". Where are the new projects? (disclaimer: I know, there are FEW) -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
agreed 100% i would add that our 19000 inhouse cobol programs do not leave much alternative than to hope for a big life expectancy for our mainframe In some cases the choice is that there is no choice . be it cobol or some fancy software running only on some fancy OS for some fancy department . Bruno Sugliani zxnetconsult(at)free(dot)fr On Wed, 25 Jun 2008 07:38:49 -0600, Howard Brazee <[EMAIL PROTECTED]> wrote: >On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve >Comstock) wrote: >>What's the driving factor that gives mainframes any >>kind of real life expectancy, given that Windows and >>xNIX are now up to MF standards? >Evaluate your needs and wants, compare them with the costs involved - >just as you do with any other purchase. >Some people compare computers with transportation. Sometimes a cargo >ship is the best solution, other times, trains, large trucks, small >trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling >work better for particular tasks. >Each tool has different standards, different costs, different >strengths, and different weaknesses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 24 Jun 2008 21:41:28 -0700, [EMAIL PROTECTED] (Steve Comstock) wrote: >What's the driving factor that gives mainframes any >kind of real life expectancy, given that Windows and >xNIX are now up to MF standards? Evaluate your needs and wants, compare them with the costs involved - just as you do with any other purchase. Some people compare computers with transportation. Sometimes a cargo ship is the best solution, other times, trains, large trucks, small trucks, vans, sedans, race cars, bicycles, Segways, feet, or crawling work better for particular tasks. Each tool has different standards, different costs, different strengths, and different weaknesses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > Following Bruce's talk was some people from tandem (corresponding to Jim > having left research for tandem). Two things mentioned in that > time-frame was Jim defining the TPF thruput (ACP having been renamed TPF > as more non-airlines started using it for transactions) as a transaction > objective for Tandem systems. The other was the study showing that > hardware was becoming significantly more reliable and other factors were > increasingly becoming source of outages (planned, human mistakes, > disturbances in localized geographical area). re: http://www.garlic.com/~lynn/2008j.html#16 We're losing the battle old ACP/TPF related email from the period http://www.garlic.com/~lynn/2008i.html#email800325 in this post http://www.garlic.com/~lynn/2008i.html#39 American Airlines giving some numbers for 120 transaction/second TPF system -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Timothy Sipples) writes: > Nobody said Parallel Sysplex and GDPS are the only high availability > clustered solutions in the market. But this whole thread got started > because of a complaint about *planned* outages. One must not be sloppy > here: "five nines" should have a business definition, and that definition > does not typically distinguish between planned and unplanned outages. (Or > at least people should say something like "five nines, excluding planned > outages of up to [X] duration [Y] times per year.") If you're down, you're > down. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle http://www.garlic.com/~lynn/2008j.html#7 We're losing the battle http://www.garlic.com/~lynn/2008j.html#10 We're losing the battle when we were out marketing ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp ... against tandem (as well as s/88 aka stratus) ... there was a customer with five-nines application availability requirement (five minutes outage/annum). the non-clustered fault-tolerant solutions had software maintenance (scheduled) outages that far exceeded 5min/annum. we had also coined the term disaster survivability and geographic survivability ... i.e. clustering at a distance ... as hardware and other components become more & more reliable ... localized disturbances were becoming a larger percentage of unplanned outages. http://www.garlic.com/~lynn/subtopic.html#available as mentioned earlier in the thread ... long ago and far away, my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture ... where she created peer-coupled shared data. http://www.garlic.com/~lynn/subtopic.html#shareddata Lack of uptake (at the time) resulted in her not staying long in the position. Except for ims hot-standby ... it wasn't until sysplex that you started seeing her architecture being supported. the long mainframe lead time ... was at least partial motivation for ha/cmp product (based on power platform rather than mainframe platform). it was also behind POK & Rochester objecting to ha/cmp contributions to the corporate continuous availability strategy document ... claiming that it would be years before they could have such support. some folklore x-over ... Bruce's talk last month at Jim's tribute pointed out that his formulization of transaction semantics was the real significant enabler opening up online transactions (sufficient trust in computer operations vis-a-vis manual/paper operation). This was during the days of the original relational/sql implementation project at san jose research on vm/cms platform http://www.garlic.com/~lynn/subtopic.html#systemr Following Bruce's talk was some people from tandem (corresponding to Jim having left research for tandem). Two things mentioned in that time-frame was Jim defining the TPF thruput (ACP having been renamed TPF as more non-airlines started using it for transactions) as a transaction objective for Tandem systems. The other was the study showing that hardware was becoming significantly more reliable and other factors were increasingly becoming source of outages (planned, human mistakes, disturbances in localized geographical area). Jim later left Tandem for DEC database group in San Francisco. It was in this time-frame that I had something of an argument with him at '91 Asilomar SIGOPS ... where I was claiming I could do high availability on (clustered) commodity hardware (using ha/cmp methodology as example) and he claiming that it still required proprietary hardware (somewhat reflecting the Tandem and DEC vax/cluster affiliations). I've since noted that not too long later, he then had to be up on the stage for the announcement of the m'soft availability clustering ... recent reference: http://www.garlic.com/~lynn/2008i.html#50 Microsoft versus Digital Equipment Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ron Hawkins writes: >Oh come on Richard. There are Banks all around the world that >have never possessed a MF, and get along quite nicely with five >nines availability on Unix clustered solutions. Last I checked (which was very recently), exactly none of the top 50+ banks are without mainframes, nearly all IBM mainframes. (There might be an exception or two in Japan where there are Fujitsu, Hitachi, and NEC mainframes running operating systems like MSP, XSP, VOS3, and ACOS.) It has also been the trend that the mainframe banks have bought out the smaller non-mainframe banks. I don't think that's coincidence -- the modern mainframe is a fantastic vehicle to support rapid business acquisition. But I have a second point to make below >We should not fool ourselves into thinking that Parallel >Sysplex and GDPS are the only HA clustered solutions in the >market place, whether local, metro or geographically dispersed. >I had UNIX customers doing multi-site RAID-1 over RAID-5 before >Hiperswap was a twinkle in IBM's eye! Damn site easier to >operate too. Nobody said Parallel Sysplex and GDPS are the only high availability clustered solutions in the market. But this whole thread got started because of a complaint about *planned* outages. One must not be sloppy here: "five nines" should have a business definition, and that definition does not typically distinguish between planned and unplanned outages. (Or at least people should say something like "five nines, excluding planned outages of up to [X] duration [Y] times per year.") If you're down, you're down. Note also that "down" in business terms means both completely down and "not responding fast enough, predictably enough." For a credit card company it's that wallet-share question: whether the customer reaches for their Visa or their American Express card. (And there's "stickiness" to that decision: credit card users tend to reach back for the same card.) That's another level of rigor that the "five nines" shorthand often does not capture. Last I checked (again very recently), it still wasn't possible to upgrade your major database version and keep the business running while you do it, even if you have the fanciest and most expensive distributed UNIX cluster in the world. That run-while-upgrading process is routine on z/OS with Parallel Sysplex and DB2 data sharing. And I'm sure z/TPF enthusiasts could point to some really interesting things they can do, to pick another example. There are many others pervasive throughout the hardware, operating system, and middleware. Does it matter? Not to everyone, but of course it matters to many businesses and for many services. The need to avoid planned outages seems to be increasing over time actually, so there's a lot of demand here. J R writes: >The "front ends" need to be bulletproof because "back ends" are >not always available. This has nothing to do with whether the >front and back ends are Tandem or IBM. The front end and back >ends may even be on the same box. It's not necessarily that the >box becomes unavailable but, more likely, that the back end >application does -- sometimes intentionally, sometimes not. >The important thing is that the front end can continue to service >transactions, stand in for the back end and SAF the results. Very good point. Basically an organization introduces front-end receive-and-store queuing systems if they have unreliable backends. And sometimes that's "good enough," but it's always a second-best service level. For example, the ATMs might offer lower limit cash withdrawals (and hold those withdrawal records for later reconciliation), but they won't provide an up-to-date account balance if the backend is offline. >Back in the day, Tandem was the dominant fault-tolerant platform. >However, for almost two decades, sysplex technology has given >mainframes fault tolerance that Tandem can only dream of. >So, it's not that Tandem's front end value is lessening but that >they are no longer the only game in town. I do think Tandem (HP NonStop) front-end value is lessening because of decisions HP and especially software vendors have made recently. But I think you're exactly right about the fact that, if you have a highly available IBM mainframe backend, why do you still need a special queuing front-end? Quite simply you don't, and that's been the trend, to edit and to simplify for several reasons. [De-tiering is good in HA engineering, actually, so if you can eliminate a tier or two "ceteris paribus" you'll improve your statistical predicted availability. Said another way, a pair of "five nines" clusters lashed in sequence together does not quite result in "five nines" end-to-end. (Get out your calculator and give it a try.)] It shouldn't be surprising. In any business, if a middleman no longer offers a unique benefit, why deal with the middleman? Why not just go direct? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architec
Re: We're losing the battle
>>> On Wed, Jun 25, 2008 at 12:41 AM, in message <[EMAIL PROTECTED]>, Steve Comstock <[EMAIL PROTECTED]> wrote: -snip- > The problem I'm having, then, Ron, is identifying exactly > where z/OS belongs today. > > On the one hand I hear that nothing beats the MF for > reliability, security, recoverability, and so on. Then > I hear people telling me not be so sure about that. So > if these other platforms are up to MF levels, and they > are so much cheaper, why would anyone stay with a > mainframe today? Well, in terms of DRA, there is no comparison, particularly if you're talking about a non-trivial number of distributed systems. z/OS has its strengths in a number of areas (I would love to have the same batch capability on Linux), and the fact that 60%+ of business data resides on ECKD emulated storage argues strongly for the continued existence of z/OS, ideally in cooperation with other operating systems, both mainframe based and not. > What's the driving factor that gives mainframes any > kind of real life expectancy, given that Windows and > xNIX are now up to MF standards? The fact that they're not. Period. Particularly not in the area of hardware reliability, and DRA. Distributed systems, whether UNIX or Linux, will likely always have their place. (The z10 closes the "performance gap" but the CPU cycles are still much more expensive compared to RISC or Intel/AMD.) The mainframe will also have its place, and more people are coming to realize that as time goes on. That doesn't necessarily mean z/OS, but z/OS in combination with Linux for System z (itself in combination with z/VM) is likely to be around for quite a while longer. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>>> On Wed, Jun 25, 2008 at 12:21 AM, in message <[EMAIL PROTECTED]@sbcglobal.net>, Ron Hawkins <[EMAIL PROTECTED]> wrote: -snip- > It gets even more ridiculous when Linux is suddenly an anointed HA OS simply > because it will run on an IBM Mainframe, along with Solaris and pre-RISC > AIX. I have not figured that out yet. Umm, no. It's not the fact that Linux is running on the mainframe that creates high availability. As with all other operating systems, it's the infrastructure that supports HA, as well as (sometimes) some applications that are HA aware. Heartbeat, various STONITH tools and so on are what accomplish HA, not the OS itself, per se. You can get HA without the application being HA aware, but it's easier if they are. There are HA Linux clusters that have never been anywhere near a mainframe. The same holds true for Solaris, HP-UX, Tru64, AIX, and others. Having said that, having your operating systems on System z hardware makes getting HA levels of uptime more common, but not more doable. While server class midrange hardware can be very good, it's not nearly as good as System z. Which partly explains the huge price differential between them. (The rest is due to other factors that are far less satisfying to contemplate.) Even on System z, however, you still have to design the architecture as though any part of it can fail in the next few minutes. Otherwise you're just burying your head in the sand. Finally, don't compare server operating systems to Windows XP. I no longer have any love for Microsoft and the various incarnations of their Windows desktop operating systems, but they're not comparable to the server editions in the same family. Microsoft's desktop OSes don't have any sort of HA potential built into them, but their server versions do, via clustering, albeit along the lines of Microsoft's vision of what that means. Given a choice, and application availability, I would go with Linux on System z (running on z/VM) clustering versus Parallel Sysplex, for no other reason than the huge cost savings, and relative simplicity. That's a purely economic evaluation, not a technical one. I supported MVS for 20+ years, and have a great admiration for it. IBM's pricing schemes (along with most ISVs) make it difficult to justify economically these days. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ron Hawkins wrote: Bruno. This thread, as with many on this topic, starts out with the assumption that UNIX, LINUX and Windows Server Operating Systems, along with server class hardware are no different to the Home PC they loaded up with Windows XP in order to play Warcraft, or the laptop they use for email and terminal emulators. It only goes downhill from there. It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. As Radoslaw said, "I love Mainframes but I'm not blind." Those that wish to make a valid comparison between z/OS and other HA OS need to get their noses out of Windows and have a look at how HA is being done on other SERVER Operating Systems. In many cases it is not platform that provides the HA, but rather an application running on the OS like Veritas Cluster Server or HACMP. These HA applications won't even run on XP. And what I would give for backup software like Commvault or Netbackup on the Mainframe. Backup on Open System Server software is Light years ahead of anything on the MF, whether it's IBM or ISV software. It's like comparing a Ferrari to the first stone wheel... I like to take a wider view than the lint in my belly button... Ron PS For those that WOW, I'm a level 63 Human Warrior :) The problem I'm having, then, Ron, is identifying exactly where z/OS belongs today. On the one hand I hear that nothing beats the MF for reliability, security, recoverability, and so on. Then I hear people telling me not be so sure about that. So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques ==> Check out the Trainer's Friend Store to purchase z/OS <== ==> application developer toolkits. Sample code in four<== ==> programming languages, JCL to Assemble or compile, <== ==> bind and test. <== ==> http://www.trainersfriend.com/TTFStore/index.html<== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Bruno. This thread, as with many on this topic, starts out with the assumption that UNIX, LINUX and Windows Server Operating Systems, along with server class hardware are no different to the Home PC they loaded up with Windows XP in order to play Warcraft, or the laptop they use for email and terminal emulators. It only goes downhill from there. It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. As Radoslaw said, "I love Mainframes but I'm not blind." Those that wish to make a valid comparison between z/OS and other HA OS need to get their noses out of Windows and have a look at how HA is being done on other SERVER Operating Systems. In many cases it is not platform that provides the HA, but rather an application running on the OS like Veritas Cluster Server or HACMP. These HA applications won't even run on XP. And what I would give for backup software like Commvault or Netbackup on the Mainframe. Backup on Open System Server software is Light years ahead of anything on the MF, whether it's IBM or ISV software. It's like comparing a Ferrari to the first stone wheel... I like to take a wider view than the lint in my belly button... Ron PS For those that WOW, I'm a level 63 Human Warrior :) > > Thank you Ron > I was feeling alone . > i have been sometimes pulling out applications from mainframe in my > shop and > applied all good recipes from centralised processing > ( dual computer rooms , dual replicated storage bays for dasds , dual > network, load balancing , dual tape robotics and even ESX vmware to > drag > and drop servers on the fly) > And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS > linux , Windows data servers , AIX applications , etc ... ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> I don't know the details, but I know our "Tandems" go into a "store > and forward" mode when anything on the mainframes slows down. > That could be a processor down, CICS regions down, transaction > failures, dasd contention, spin loops (Ok, that one hasn't happened > lately), etc. I don't see their value lessening even if their function > is needed less often. The "front ends" need to be bulletproof because "back ends" are not always available. This has nothing to do with whether the front and back ends are Tandem or IBM. The front end and back ends may even be on the same box. It's not necessarily that the box becomes unavailable but, more likely, that the back end application does -- sometimes intentionally, sometimes not. The important thing is that the front end can continue to service transactions, stand in for the back end and SAF the results. Back in the day, Tandem was the dominant fault-tolerant platform. However, for almost two decades, sysplex technology has given mainframes fault tolerance that Tandem can only dream of. So, it's not that Tandem's front end value is lessening but that they are no longer the only game in town. > Date: Tue, 24 Jun 2008 15:42:11 -0500 > From: [EMAIL PROTECTED] > Subject: Re: We're losing the battle > To: IBM-MAIN@BAMA.UA.EDU > > On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples > <[EMAIL PROTECTED]> wrote: > > >... > >I agree with Chris. In my (more limited) experience, if HP NonStops are > >used they're mainly as front-end switches at card network member > >banks. And their use in this niche role is fading, ... > > I don't know the details, but I know our "Tandems" go into a "store > and forward" mode when anything on the mainframes slows down. > That could be a processor down, CICS regions down, transaction > failures, dasd contention, spin loops (Ok, that one hasn't happened > lately), etc. I don't see their value lessening even if their function > is needed less often. > > I also don't think the presence or absence of parallel Sysplex (or > anything else relating to type of platform) can be singled out as > the villian. It all depends on application and database design, etc. > It doesn't mattter how many 9s worth of platform availability > (hardware, operating system, transaction processors, network, etc.) > if you have to regularly take a database offline for hours. And > applications can be designed poorly on any platform. > > Pat O'Keefe > > _ Need to know now? Get instant answers with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_062008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (R.S.) writes: > In my experience, Tandems are not "switches". They process card > traffic. I'm aware of one migration from mainframe to Tandem. > Here in Poland, vast majority of ATMs and POS's are non-mainframe. > Even no mainframe "behind the Tandem". > Only 3 banks are using mainframes at all. Was 4. The fourth one > decided to drop the mainframe due to costs. The project was succesful > - no entry for re-boot hill. Oh, two big mainframe projects I'm aware > exceeded planned timeframe and budget. > Only one ATM network is using mainframe. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle http://www.garlic.com/~lynn/2008j.html#7 We're losing the battle in the 80s & 90s a lot of ATM stuff was done on Tandem machines with software (base24) from these guys http://www.aciworldwide.com/company/ quicky search on tandem, atm, base24 turns up stuff like this: July 19, 1999, Indian Public Banks Move Online Slowly http://asia.internet.com/news/article.php/650391 tandem wiki page: http://en.wikipedia.org/wiki/Tandem_Computers some issues may be attributed to (after being acquired by HP, tandem line) being moved to Itanium base ... which has had its own issues. more recently ACI has been quite active with IBM (besides over the yrs providing products on some number of other platforms) http://www.aciworldwide.com/partners/sapartners.aspx?pid=118 old related post in this n.g. from last year (also reply to one of your posts): http://www.garlic.com/~lynn/2007s.html#6 ATMs as mentioned in the old post, we marketed our ha/cmp product against them in some number of markets http://www.garlic.com/~lynn/subtopic.html#hacmp -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Patrick O'Keefe wrote: On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples <[EMAIL PROTECTED]> wrote: ... I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, ... I don't know the details, but I know our "Tandems" go into a "store and forward" mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. In my experience, Tandems are not "switches". They process card traffic. I'm aware of one migration from mainframe to Tandem. Here in Poland, vast majority of ATMs and POS's are non-mainframe. Even no mainframe "behind the Tandem". Only 3 banks are using mainframes at all. Was 4. The fourth one decided to drop the mainframe due to costs. The project was succesful - no entry for re-boot hill. Oh, two big mainframe projects I'm aware exceeded planned timeframe and budget. Only one ATM network is using mainframe. Did I mention the majority of HW elements used for sysplex can also be used in "open" systems environment? I mean DASD, FC switches, tapes... Disclaimer: I like mainframes, but I'm not blind. -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples <[EMAIL PROTECTED]> wrote: >... >I agree with Chris. In my (more limited) experience, if HP NonStops are >used they're mainly as front-end switches at card network member >banks. And their use in this niche role is fading, ... I don't know the details, but I know our "Tandems" go into a "store and forward" mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. I also don't think the presence or absence of parallel Sysplex (or anything else relating to type of platform) can be singled out as the villian. It all depends on application and database design, etc. It doesn't mattter how many 9s worth of platform availability (hardware, operating system, transaction processors, network, etc.) if you have to regularly take a database offline for hours. And applications can be designed poorly on any platform. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 24, 2008 1:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle Craddock, Chris wrote: PC programmers don't have the tools they need to make their software bullet-proof because they just don't care... I think it is not that they don't care to have the tools. It is that it doesn't pay to be that pedantic with their coding (or precise if you will). Because it is so much easier to have *a* user reboot than it is to fix the problems, that this is the acceptable way out. Also, it is easier to point fingers at some other issue than it is to fix the problem within your own product. How many times have you heard or read (or been the victim of) that there is some collision between this product and that -- so you can't run both at the same time, or you can't even have both installed on your system at the same time? Granted, this is becoming more rare, but it still happens! And so going forward from about the time of Windows 3.1, the single user, pseudo-multi-task/programming view point is still prevalent. This is how we get memory leaks (poor coding practices), having to reboot to fix certain issues (because the registry can't be updated while some service is running, and it is tied to the kernel). Too many product designs are based on a single user using that product primarily, and the resource hoggishness has been slowly removed with later releases. But this is just one jaded programmer's opinion. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
[snip] > > In my experience, PC programmers simply cannot or will not > perform any > kind of post-mortem dump analysis. And, though Micro$oft operating > systems appear to have the ability to take a "dump", I have never met > anyone that knew how to, or cared to, read one. The only > thing they know > how to do is reproduce a problem under a debugger. If that can't be > done, they chalk everything up to problems with the underlying OS, > drivers, or services. We (z/OS Tech Services) were allowed to ask questions of the vendors back when a previous administration was looking at converting everything to Windows. We had a number of questions. One question and answer stuck in my mind. We asked: "Suppose a batch process fails, how would the programmer debug that?" Their answer: "Recompile the application with debugging active. Then have the programmer single step the application under the debugger until the application fails again. Use the debugger to determine why." Subsequent question: "How long do you estimate this will take if the outage occurred after 2 hours of processing?" No answer to that one. In the deep, dark past, I actually did use a Dr. Watson report to debug a Windows problem. [snip] > These anecdotes illustrate a *huge* cultural difference between our > platform and others. This sort of thing would simply not be > tolerated on > a mainframe! PC programmers don't have the tools they need to > make their > software bullet-proof because they just don't care... > > -- > Edward E Jaffe -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Craddock, Chris wrote: RS said 1. It has little to do. There is something which we can call "IT culture". PC environment (I mean human env) is more likely to "restart-like", while mainframe environment is more likely "tight controlled". Of course, YMMV, this is generalization, etc. etc. [] Funny you should mention that. I will assert that today there is almost nothing significant that you can "fix" (i.e. restore service) faster by rooting around trying to find the problem, than by just restarting the application or the server it is running on. And yes, that's a generalization. Problems do eventually have to be diagnosed, but your chances of doing that well enough during a critical situation are basically zip. Have been for many years now. In my experience, PC programmers simply cannot or will not perform any kind of post-mortem dump analysis. And, though Micro$oft operating systems appear to have the ability to take a "dump", I have never met anyone that knew how to, or cared to, read one. The only thing they know how to do is reproduce a problem under a debugger. If that can't be done, they chalk everything up to problems with the underlying OS, drivers, or services. All seasoned mainframe software developers know that a fair number of problems occur only under "special" circumstances -- often related to timing, asynchronous activity, or other hard-to-control variables. Such problems often can't be reproduced -- even when you *know* what's wrong. Without post-mortem analysis to identify the cause of these problems, such bugs would never be fixed. And, on PCs, they never are. Case in point: I was talking with one of our tech writers a couple of weeks ago, discussing the concepts of supported vs unsupported software for a matrix she was to publish on our web site. I tried to use Micro$oft examples because she's familiar with their products. She told me there are scores of universally-known bugs in supposedly "fully supported" versions of M$ Word that are decades old and still not fixed. The tech writing user community deals with these problems by avoiding them. (Doctor: It hurts when I do that. Then don't do it!) That evening, I pulled up to a gas pump that had one of those flat panel TV screens above. The thing was "stuck" on a Windows BSOD. Somebody was paying to advertise a trap screen! :-D These anecdotes illustrate a *huge* cultural difference between our platform and others. This sort of thing would simply not be tolerated on a mainframe! PC programmers don't have the tools they need to make their software bullet-proof because they just don't care... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
RS said > 1. It has little to do. There is something which we can call "IT > culture". PC environment (I mean human env) is more likely to > "restart-like", while mainframe environment is more likely "tight > controlled". > Of course, YMMV, this is generalization, etc. etc. [] Funny you should mention that. I will assert that today there is almost nothing significant that you can "fix" (i.e. restore service) faster by rooting around trying to find the problem, than by just restarting the application or the server it is running on. And yes, that's a generalization. Problems do eventually have to be diagnosed, but your chances of doing that well enough during a critical situation are basically zip. Have been for many years now. This is one of those places where the economics just don't square with reality. The mainframe approach of keeping the system (and subsystems) up at all costs is based on the economics of having a lot of stuff running concurrently on the same physical resource. The non-mainframe world isn't like that and (arguably) most mainframe apps aren't like that anymore either if they're parallel sysplex enabled. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Craddock, Chris wrote: [...] It just has nothing much to do with "mainframer=wise" or "pfcsk=dumb". It has a lot more to do with corporate policies and training and whether or not the IT staff actually follows the rules. Human nature in other words. 1. It has little to do. There is something which we can call "IT culture". PC environment (I mean human env) is more likely to "restart-like", while mainframe environment is more likely "tight controlled". Of course, YMMV, this is generalization, etc. etc. 2. Usually mainframe shops are big ones. Big shops tend to be better organized than small ones. 3. Technology is important. It's much harder to make a tent tamperproof, while is't easier to make a safe well closed. However you can leave the safe with key under the doormat and have bodyguards aorund the tent. -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ted said > I'm not blaming the tools! > I'm blaming the pfcsk's. > I have never seen a *ix person follow proper change control. > I've seen mainframers do it for over 25 years. > > I'm not bashing PC's, nor did I in any of my responses. > I bashed the (lack of) discipline of pfcsk's! [] I have seen both sides of this and, on average, I would call it a draw. I have seen very disciplined *IX and PC operations and unbelievably sloppy mainframe operations. And of course, I have seen the opposite too. It just has nothing much to do with "mainframer=wise" or "pfcsk=dumb". It has a lot more to do with corporate policies and training and whether or not the IT staff actually follows the rules. Human nature in other words. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Bruno Sugliani) writes: > Like someone said : i backup my servers with TSM on ts7700 in grid > configuration with jaguar at the back , and it works ( and i tried it in > AIX and z/OS and not much difference apart from the bill ) . > Now i am sure that using DVD's in Z/os would slow down restoration , but > then we would not think doing it . re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle tsm started out as renamed adsm. adsm was evoluation of workstation datasave facility ... and workstation datasave facility started out as CMSBACK ... which was deployed extensively internally old cmsback related email http://www.garlic.com/~lynn/lhwemail.html#cmsback and various posts related to (CMSBACK, workstation datasave, adsm, tsm, and other) backup/archive http://www.garlic.com/~lynn/subtopic.html#backup disclaimer, i had created and deployed the original CMSBACK internally ... before it went thru various morphs eventually becoming the current tsm product. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 24 Jun 2008 07:06:54 -0700, [EMAIL PROTECTED] (Wayne Driscoll) wrote: >In my experience, the UNIX and/or PC development teams were more likely to >have change integration tools, as they had to deal with multiple development >environments, while many mainframe products were developed using ISPF >library concatenations, so there was a much smaller number of potential >sources for changes. Many of the modern environments have sophisticated version control tools, and sophisticated testing systems - which are necessary but not sufficient to provide the confidence that are/were the norm in old style applications. Big complicated systems will have bugs and service packs for their lifetimes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Thank you Ron I was feeling alone . i have been sometimes pulling out applications from mainframe in my shop and applied all good recipes from centralised processing ( dual computer rooms , dual replicated storage bays for dasds , dual network, load balancing , dual tape robotics and even ESX vmware to drag and drop servers on the fly) And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS linux , Windows data servers , AIX applications , etc ... ) The people are younger though , and when you are younger you are less experienced . In effect they are sometimes making the same mistakes i was doing 30 years ago . But now they come and ask , and we the "ancient" give them advice or ask them the right questions :" and what happens if blah blah ???" I think the issue is more with the people and their experience or attitude than with the platform . These guys sometimes ask me to put "things" in mainframe and when the cost is ok we do . Like someone said : i backup my servers with TSM on ts7700 in grid configuration with jaguar at the back , and it works ( and i tried it in AIX and z/OS and not much difference apart from the bill ) . Now i am sure that using DVD's in Z/os would slow down restoration , but then we would not think doing it . Bruno Sugliani zxnetconsult(at)free(dot)fr On Tue, 24 Jun 2008 03:07:19 -0700, Ron Hawkins <[EMAIL PROTECTED]> wrote: >Oh come on Richard. There are Banks all around the world that have never >possessed a MF, and get along quite nicely with five nines availability on >Unix clustered solutions. > >We should not fool ourselves into thinking that Parallel Sysplex and GDPS >are the only HA clustered solutions in the market place, whether local, >metro or geographically dispersed. I had UNIX customers doing multi-site >RAID-1 over RAID-5 before Hiperswap was a twinkle in IBM's eye! Damn site >easier to operate too. > >Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
In my experience, the UNIX and/or PC development teams were more likely to have change integration tools, as they had to deal with multiple development environments, while many mainframe products were developed using ISPF library concatenations, so there was a much smaller number of potential sources for changes. For example, the diff tools available even in line mode unix are much more robust that ISPF 3.13. Yes it isn't always about the tools, but about the process, and as the need increases, so does the usage. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Tuesday, June 24, 2008 8:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle On 23 Jun 2008 21:28:35 -0700, in bit.listserv.ibm-main you wrote: >>] Pardon? You've never seen CVS? Or any of its zillions of commercial and open source offspring? I've built entire (mainframe!) products using these tools on PCs. And it wasn't even a hard decision to >make. They're more flexible and easier to use than anything I've used on TSO. > >I may have never seen the tools; I've never seen the discipline - which was my (poorly stated) point. > >>[] Let's stop bashing PCs here. Only a poor workman blames his tools. > >I'm not blaming the tools! >I'm blaming the pfcsk's. >I have never seen a *ix person follow proper change control. >I've seen mainframers do it for over 25 years. > >I'm not bashing PC's, nor did I in any of my responses. >I bashed the (lack of) discipline of pfcsk's! I suspect that the ix and PC development environments that you describe are in departments that formed as a reaction to the perceived (and/or actual) rigidity and unresponsiveness of the mainframe development group. The Unix shop I was in definitely had change control and signoff. I used it in maintenance and development. It was an ex-mainframe shop. Most of the development methodologies that I have heard about include change control and build organization. I am certain that most decent package developers have good change and version control irrespective of platform. > >- >Too busy driving to stop for gas! > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 23 Jun 2008 21:28:35 -0700, in bit.listserv.ibm-main you wrote: >>] Pardon? You've never seen CVS? Or any of its zillions of commercial >>and open source offspring? I've built entire (mainframe!) products using >>these tools on PCs. And it wasn't even a hard decision to >make. They're more flexible and easier to use than anything I've used on TSO. > >I may have never seen the tools; I've never seen the discipline - which was my >(poorly stated) point. > >>[] Let's stop bashing PCs here. Only a poor workman blames his tools. > >I'm not blaming the tools! >I'm blaming the pfcsk's. >I have never seen a *ix person follow proper change control. >I've seen mainframers do it for over 25 years. > >I'm not bashing PC's, nor did I in any of my responses. >I bashed the (lack of) discipline of pfcsk's! I suspect that the ix and PC development environments that you describe are in departments that formed as a reaction to the perceived (and/or actual) rigidity and unresponsiveness of the mainframe development group. The Unix shop I was in definitely had change control and signoff. I used it in maintenance and development. It was an ex-mainframe shop. Most of the development methodologies that I have heard about include change control and build organization. I am certain that most decent package developers have good change and version control irrespective of platform. > >- >Too busy driving to stop for gas! > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Quoting "Chase, John": > "We're sorry, this video is no longer available." Dunno mate, (still) works for me. Go there and search for "zfs" (and "smash" if you need to). Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Shane > > On Mon, 2008-06-23 at 10:55 -0500, gil wrote: > > > Is ZFS "reliable"? > > ... > > (No, not that "ZFS", the real one) > > On my meanderings I have just begun to look at OpenSolaris > (principlly for ZFS and dprobes - and zones). Bumped into a > mention of the following on a blog: > > http://youtube.com/watch?v=CN6iDzesEs0 > > You judge ... "We're sorry, this video is no longer available." -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Oh come on Richard. There are Banks all around the world that have never possessed a MF, and get along quite nicely with five nines availability on Unix clustered solutions. We should not fool ourselves into thinking that Parallel Sysplex and GDPS are the only HA clustered solutions in the market place, whether local, metro or geographically dispersed. I had UNIX customers doing multi-site RAID-1 over RAID-5 before Hiperswap was a twinkle in IBM's eye! Damn site easier to operate too. Ron > Alternatives *are in the process of maturing*. They certainly are not > there yet! I am amazed at the failure tolerance of distributed > application systems. If it is broke, they spend more money on it > without > getting to the root cause: bad architectural design. The mainframe > systems have never been given this kind of leeway. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Kirk Talman writes: >The most common box used for "authorizations" is what used to be >called Tandem. Now called HP NonStop. >Mainframes do much else. They stand at short arm's length to >each other. Chris Craddock replies: >Tandems were used in many online banking applications as >front-end switches. They didn't really process the transactions >beyond queueing and sending them on to the right place. Their >"non-stop" reliability was important to avoid lost transactions >back in the day when CICS couldn't keep up. Probably not so >much of an issue today, but they're probably still doing yeoman >work in the same places they were in 1983 when I first bumped >into them. I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, as Chris alludes to. A big reason is application and middleware availability trends in that industry favoring the IBM mainframe and disfavoring HP NonStop. Another is cost: typically it's more affordable to consolidate. Yet another is HP and its platform technology disruptions. (HP just announced another one this month and is trying to move understandably reluctant customers to Itanium to cut its R&D costs.) Still yet another is the adoption of Parallel Sysplex and GDPS, mooting a front-end queue.? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Sorry, Chris, but availability/(god like function :) does not always equal use by or even perception of the need. The truly greatest disappointment I have with "new age" developers is that they are now running into the same issues that people before me solved decades ago with mainframe development. And they are reinventing when they could do some research and learn from past experience. It has become far to easy to reinvent the wheel! > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Craddock, Chris > Sent: Monday, June 23, 2008 8:41 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: We're losing the battle > > Ted said > > >The change control for application development is probably better on > PC's > > > > This is so WRONG! > > > > I've worked with Change Control/QA for 27+ years. > > I have never seen a package in use by PFCSK's. > > It seems to be hit or miss. > > [] Pardon? You've never seen CVS? Or any of its zillions of > commercial and open source offspring? I've built entire (mainframe!) > products using these tools on PCs. And it wasn't even a hard decision to > make. They're more flexible and easier to use than anything I've used on > TSO. CMS may have some secret sauce I am not aware of, but if you're > comparing tools on TSO with the PC, it is the mainframe ones that come > up short. Sorry. > > > I've worked with change control applications on the mainframe since > 1981 > > (PANVALET, then). > > > > I don't think it's platform dependent, but I have seen too many > managers > > let PC 'fixes' fly through on PC's, that they wouldn't let the > equivalent > > see the light of day on mainframes. > > [] Let's stop bashing PCs here. Only a poor workman blames his > tools. Everyone here has seen ugly changes fly through the net with nary > a swat from the QA or change control process. > > CC > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>] Pardon? You've never seen CVS? Or any of its zillions of commercial and >open source offspring? I've built entire (mainframe!) products using these >tools on PCs. And it wasn't even a hard decision to make. They're more flexible and easier to use than anything I've used on TSO. I may have never seen the tools; I've never seen the discipline - which was my (poorly stated) point. >[] Let's stop bashing PCs here. Only a poor workman blames his tools. I'm not blaming the tools! I'm blaming the pfcsk's. I have never seen a *ix person follow proper change control. I've seen mainframers do it for over 25 years. I'm not bashing PC's, nor did I in any of my responses. I bashed the (lack of) discipline of pfcsk's! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ted said > >The change control for application development is probably better on PC's > > This is so WRONG! > > I've worked with Change Control/QA for 27+ years. > I have never seen a package in use by PFCSK's. > It seems to be hit or miss. [] Pardon? You've never seen CVS? Or any of its zillions of commercial and open source offspring? I've built entire (mainframe!) products using these tools on PCs. And it wasn't even a hard decision to make. They're more flexible and easier to use than anything I've used on TSO. CMS may have some secret sauce I am not aware of, but if you're comparing tools on TSO with the PC, it is the mainframe ones that come up short. Sorry. > I've worked with change control applications on the mainframe since 1981 > (PANVALET, then). > > I don't think it's platform dependent, but I have seen too many managers > let PC 'fixes' fly through on PC's, that they wouldn't let the equivalent > see the light of day on mainframes. [] Let's stop bashing PCs here. Only a poor workman blames his tools. Everyone here has seen ugly changes fly through the net with nary a swat from the QA or change control process. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>The change control for application development is probably better on PC's This is so WRONG! I've worked with Change Control/QA for 27+ years. I have never seen a package in use by PFCSK's. It seems to be hit or miss. I've worked with change control applications on the mainframe since 1981 (PANVALET, then). I don't think it's platform dependent, but I have seen too many managers let PC 'fixes' fly through on PC's, that they wouldn't let the equivalent see the light of day on mainframes. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 23 Jun 2008 10:04:08 -0700, in bit.listserv.ibm-main you wrote: > >Agreed. There are statistics and damn statistics. Numbers can be made to >say anything these days. > >Alternatives *are in the process of maturing*. They certainly are not >there yet! I am amazed at the failure tolerance of distributed >application systems. If it is broke, they spend more money on it without >getting to the root cause: bad architectural design. The mainframe >systems have never been given this kind of leeway. >--- >And probably never will have this sort of leeway. Until IT management >learns to place business needs first and platform second. They need to >learn to select platforms based on business needs, not on PERCEIVED ease >of use. And the advocates of smaller platforms better start thinking >real hard about change control and quality control, backup and recovery, >disaster recovery, and many of the other problems we've already >addressed, in some cases very well, on those "dinosaurs" we call mainframes. > The change control for application development is probably better on PC's. The IDE's for C# that I have seen described are something I wanted 20+ years ago. IBM and CA should go back and read the SHARE/Guide Language Futures Task Force Report. Quality control is an organizational problem, not a platform problem. Tivoli has non-mainframe backup software and for disk to removable hard drive, Acronis TrueImage does a nice full volume backup with compression which can be reloaded onto a new drive using a backup CD. You can also restore individual files from the backup. As a former user of FDR, I feel right at home with Acronis. I think they also will back up to DVD and have both incremental and backup all changes from a baseline backup. It all depends on how much money and people resource an organization is willing to put into the process. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Mon, 2008-06-23 at 10:55 -0500, gil wrote: > Is ZFS "reliable"? > ... > (No, not that "ZFS", the real one) On my meanderings I have just begun to look at OpenSolaris (principlly for ZFS and dprobes - and zones). Bumped into a mention of the following on a blog: http://youtube.com/watch?v=CN6iDzesEs0 You judge ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OT: CC the Rapper; was: Re: We're losing the battle
Craddock, Chris wrote: The most common box used for "authorizations" is what used to be called Tandem. Mainframes do much else. They stand at short arm's length to each other. [] Tandems were used in many online banking applications as front-end switches. They didn't really process the transactions beyond queueing and sending them on to the right place. Their "non-stop" reliability was important to avoid lost transactions back in the day when CICS couldn't keep up. Probably not so much of an issue today, but they're probably still doing yeoman work in the same places they were in 1983 when I first bumped into them. CC Chris, I just opened last week's New Yorker magazine and found a review of a new rap opera written by Chris Craddock. Way to go, man! Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques ==> Check out the Trainer's Friend Store to purchase z/OS <== ==> application developer toolkits. Sample code in four<== ==> programming languages, JCL to Assemble or compile, <== ==> bind and test. <== ==> http://www.trainersfriend.com/TTFStore/index.html<== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
2008/6/23 Timothy Sipples <[EMAIL PROTECTED]>: > You can be darn sure the card approval service -- the GDPS-based (likely) > application that approves or denies your card transaction -- is still > working round the clock. So the mainframe is still working. > > Chances are the Web front end is not (yet) on the mainframe, and that might > be the problem. There could also be problems with the architecture -- > somebody might have thought it would be a good idea to replicate the > billing database, and so that has to close when the master billing database > is in a batch cycle because it would be out of sync and present the > customer with an old version of the truth. > > Now, the Web customer self-service applications might have very different > SLAs than card approval, and that might even be a sensible business > decision [snip] I use Google Adwords on a very small scale, and I am amused to see that every few weeks they have what they call a "short scheduled downtime", usually in midday Saturday. In their case, "short" is 5 1/2 hours! Well it's only the admin interface; the ads continue to be served and the money collected, but still - what are they doing with their hugely multi-processor architecture that requires this? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>So instead of spending money on 9 nines, spend it on more data centers. More data centres contribute towards more nines (imo). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> The most common box used for "authorizations" is what used to be called > Tandem. Mainframes do much else. They stand at short arm's length to > each other. [] Tandems were used in many online banking applications as front-end switches. They didn't really process the transactions beyond queueing and sending them on to the right place. Their "non-stop" reliability was important to avoid lost transactions back in the day when CICS couldn't keep up. Probably not so much of an issue today, but they're probably still doing yeoman work in the same places they were in 1983 when I first bumped into them. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The most common box used for "authorizations" is what used to be called Tandem. Mainframes do much else. They stand at short arm's length to each other. IBM Mainframe Discussion List wrote on 06/23/2008 04:36:22 AM: > You can be darn sure the card approval service -- the GDPS-based (likely) > application that approves or denies your card transaction -- is still > working round the clock. So the mainframe is still working. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
--- I use much more robust mechanisms for backup/restore on Windows, i.e. IBM 3494 with 3592 drives or STK SL8500 with LTO4 and T1A. Why don't you do it? --- Facetious response noted. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Rick Fochtman wrote: -- It all depends on how such things are measured. Our dominance isn't as pervasive as it once was, as alternatives have matured. Is that losing? [...] And let's face it, backup/restore mechanisms for Windoze-based (or ?ix) platforms just aren't very robust. I just spent the better part of two days restoring a 400G hard drive from DVD backup and it was NOT FUN! And I use regular incremental backups! I use much more robust mechanisms for backup/restore on Windows, i.e. IBM 3494 with 3592 drives or STK SL8500 with LTO4 and T1A. Why don't you do it? Do you have something "more robust" for mainframe ? Oh, sometimes I use CD-R for mainframe data, however I'm aware of its "strenghts". My $0.02 -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Agreed. There are statistics and damn statistics. Numbers can be made to say anything these days. Alternatives *are in the process of maturing*. They certainly are not there yet! I am amazed at the failure tolerance of distributed application systems. If it is broke, they spend more money on it without getting to the root cause: bad architectural design. The mainframe systems have never been given this kind of leeway. --- And probably never will have this sort of leeway. Until IT management learns to place business needs first and platform second. They need to learn to select platforms based on business needs, not on PERCEIVED ease of use. And the advocates of smaller platforms better start thinking real hard about change control and quality control, backup and recovery, disaster recovery, and many of the other problems we've already addressed, in some cases very well, on those "dinosaurs" we call mainframes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-- This wasn't an option when the costs of each data center and the costs of data synchronization between data centers was prohibitive, but times change. We are looking at floods, earthquakes, terrorism making the concept of a single data center obsolete for large enterprises. So instead of spending money on 9 nines, spend it on more data centers. -- AGREED! The cost of a DR service for a large enterprise can be prohibitive, whereas the cost of maintaining a second data center is slowly coming down. I predict that we will be subject to a floor function here, but it's highly likely to be less expensive than a DR service. And the cost and timeliness of cutting over will be far smaller, both in terms of customer impact and corporate dollars. And this is all assuming that you can find a DR service with enough resources to handle your large enterprise. Remember that you might not be the only victims; you might have to share the site with other shops, like we did, during the "Great Chicago Flood" in the early 90's. (Lots of roses to SunGard; they did us fine, but we were a fairly small shop.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-- It all depends on how such things are measured. Our dominance isn't as pervasive as it once was, as alternatives have matured. Is that losing? I've said it before and I'll say it again: each platform has strengths and weaknesses. Which platform is the "right" platform depends on the needs of the business. One of the biggest problems we encounter is that management types very seldom look at the business from this viewpoint and end up making decisions that might not be the best. I'd hate to try building work-processing documents on a z/OS platform, when so many very highly usable packages exist for the Intel-based platform. But I'd ALSO hate like the dickens to have to go data-mining for a few transactions in a multi-million transaction database on a PC. And let's face it, backup/restore mechanisms for Windoze-based (or ?ix) platforms just aren't very robust. I just spent the better part of two days restoring a 400G hard drive from DVD backup and it was NOT FUN! And I use regular incremental backups! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Mon, 23 Jun 2008 09:21:52 -0600, Howard Brazee wrote: > >I've read that Apple will be changing to a reliable file system with >Snow Leopard. I haven't read that Microsoft will be ready with one >soon. > What's "reliable"? There were rumors (wishful thinking?) that Apple was considering ZFS. Didn't happen in Leopard. Perhaps in Snow Leopard. Is ZFS "reliable"? What is required for reliability? Data journaling? RAID? Concurrent remote copy? Could Microsoft be made reliable by Samba sharing from a reliable server? (No, not that "ZFS", the real one. Or are they the same? Isn't either one tradmarked?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 22 Jun 2008 13:36:13 -0700, [EMAIL PROTECTED] (Thomas Kern) wrote: >Not all Federal data centers see any value in dinosaurs, even dinosaurs with >penguins. Neither dinosaur nor penguin is as good as Windows. >Management will suffer to have network infrastructure running under some >form of linux (Centos or Fedora, but nothing with a support contract). But >Webservers, Database servers, file servers, print servers, they belong to >Windows because the true Federal Desktop is Windows and everything must be >like that. I've read that Apple will be changing to a reliable file system with Snow Leopard. I haven't read that Microsoft will be ready with one soon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Agreed. There are statistics and damn statistics. Numbers can be made to say anything these days. Alternatives *are in the process of maturing*. They certainly are not there yet! I am amazed at the failure tolerance of distributed application systems. If it is broke, they spend more money on it without getting to the root cause: bad architectural design. The mainframe systems have never been given this kind of leeway. I'd better stop now before I get my blood pressure up. - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] - -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee Sent: Monday, June 23, 2008 11:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle On 22 Jun 2008 04:35:06 -0700, [EMAIL PROTECTED] (Richards, Robert B.) wrote: >I wouldn't say we are necessarily losing the battle. It all depends on how such things are measured. Our dominance isn't as pervasive as it once was, as alternatives have matured. Is that losing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 22 Jun 2008 14:24:35 -0700, [EMAIL PROTECTED] (Gibney, Dave) wrote: > The issue that needs addressing is: Why, when technology has reached our > current level, is ANY customer visible downtime acceptable? Those "other > components" could, with today's capability, be properly redundant and > designed/coded/implemented such that the "SYSTEM" is never down at the public > interfaces. > It happens, that after dark on a weekend is MY best time to do my finances. > Yet, that is often when the "system is undergoing maintenance. > And the folks parked in daylight at the call center couldn't even understand > my irritation. > > I know that my little site at a University can't afford 9 nines, but damn > it, the credit card companies should be able to afford it, their fees are > significant to both buyer and seller. How much is each additional nine worth? Of course the solution for ubiquitous up time, is probably to have a distributed system that is designed to work when data centers go down. If you have multiple data centers spread around large geographic areas, then our cost analysis in giving one computer more nines changes. This wasn't an option when the costs of each data center and the costs of data synchronization between data centers was prohibitive, but times change. We are looking at floods, earthquakes, terrorism making the concept of a single data center obsolete for large enterprises. So instead of spending money on 9 nines, spend it on more data centers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 22 Jun 2008 04:35:06 -0700, [EMAIL PROTECTED] (Richards, Robert B.) wrote: >I wouldn't say we are necessarily losing the battle. It all depends on how such things are measured. Our dominance isn't as pervasive as it once was, as alternatives have matured. Is that losing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> >>It seems that I thought major banks had Sysplexes behind them, I guess > >not! :( > >Banks not only have SYSPLEXes most have GDPS also and are bound by law > >to very stringent down time restrictions. I doubt that your inability to > >access is due to the zOS backend systems. More likely a web interface is > >down. [] DO not! Do so too! Nyah! What a storm in a teacup. We've gone from an anecdotal story of some credit card function being unavailable to the end of civilization as we know it. For the record, a typical online banking system has lots of components in between the customer and the executable transaction. Many of those are outside of the z/OS environment altogether. And while many of the high end financial customers (banks etc) exploit parallel sysplex, quite a few don't. Some even do bank processing on non-mainframe systems Without knowing the exact nature of the "failure" there is no way to speculate about the cause. Even if the bank wasn't using GDPS and parallel sysplex, it is pretty unlikely the underlying cause was a z/OS outage. Not exactly grounds for opening a vein is it? CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Mon, 23 Jun 2008 08:20:21 -0400, Veilleux, Jon L <[EMAIL PROTECTED]> wrote: >>In a message dated 6/22/2008 12:46:04 A.M. Central Daylight Time, >[EMAIL PROTECTED] writes: >>It seems that I thought major banks had Sysplexes behind them, I guess >not! :( >Banks not only have SYSPLEXes most have GDPS also and are bound by law >to very stringent down time restrictions. I doubt that your inability to >access is due to the zOS backend systems. More likely a web interface is >down. I don't think so ( GDPS and sysplex) . Banks have strict regulations about their installation and their security . But they are mainly under recommendations and not obligations as for their down time . AFAIK some people on this list work for banks that do not have parallel sysplex , but i guess they cannot talk about it as the decision had to most likely been taken according to financial reasons , and against their professional recommendations . And i know plenty that are not parallel sysplex in Europe , and they are not small banks . As for the likeliness of some web interface being down or maintained , i agree. The chances that this is the reason are high . Bruno Sugliani zxnetconsult(at)free(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
>In a message dated 6/22/2008 12:46:04 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >It seems that I thought major banks had Sysplexes behind them, I guess not! :( Banks not only have SYSPLEXes most have GDPS also and are bound by law to very stringent down time restrictions. I doubt that your inability to access is due to the zOS backend systems. More likely a web interface is down. Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
You can be darn sure the card approval service -- the GDPS-based (likely) application that approves or denies your card transaction -- is still working round the clock. So the mainframe is still working. Chances are the Web front end is not (yet) on the mainframe, and that might be the problem. There could also be problems with the architecture -- somebody might have thought it would be a good idea to replicate the billing database, and so that has to close when the master billing database is in a batch cycle because it would be out of sync and present the customer with an old version of the truth. Now, the Web customer self-service applications might have very different SLAs than card approval, and that might even be a sensible business decision And that's a clue. Why don't you write a letter to the credit card company CEO asking him/her why the Web customer service application is not as available as card approval? There are increasing numbers of people who need service at 2 a.m. -- people who travel to places like Japan, for example. It may no longer be a sensible business strategy to have these front-tier outages at 2:00 a.m. The Web needs to grow up, fast, for many of these businesses. Unless and until customers demand higher availability for services that are important to them, the CEO won't know about it. It's all about business. For that matter, do you have credit cards with companies that don't shut down? Cancel the ones that do, and move to the ones that don't. Let the company management know why you moved. I live in Japan and have a bank account with a certain major U.S. bank that supposedly never sleeps. This particular banking service is even called "Global Executive Banking." Now, you would think this type of banking, from a bank that advertises that it never sleeps, would offer something approximating 24 hour service. At least 23, right? You would be wrong. Full banking services are only available Monday through Friday from 8:00 a.m. to 5:00 p.m. New York time. (That's currently 9:00 p.m. to 6:00 a.m. Tokyo time, Monday night through Saturday morning.) And by "full," I mean things like a simple wire transfer. A few, limited banking services are available for a couple more hours. (The banking interns are working the longer hours?) This for "global executives," who you'd think would be among the bank's top customers. Certainly given the high fees and paltry interest paid, that would seem to be the case. I am closing the account as soon as I possibly can, and I'll let the bank know why. This level of service is simply unacceptable. In fact, one really wonders whether anybody offering this "service" actually spoke with a "global executive." As a reminder, I speak only for myself. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
> -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of R.S. > Sent: Sunday, June 22, 2008 8:40 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: We're losing the battle > > Gibney, Dave wrote: > > I tried to access two different credit card sites just now. Both > > can't help due to system maintenance. One site announced maintenance > > hours starting 2am, or one hour from when I started trying. > > > > > > > >It seems that I thought major banks had Sysplexes behind them, I > > guess not! :( > > Parallel Sysplex has nothing to do with that. You're talking about > *banking system* which consist of many elements, optionally including PS. > Even if the PS is there and is really available, it doesn't mean the > system (banking system) will be available. > I work under SLA which allows me to have 8 hours of planned outage per > year. No sysplex. I have never reached the limit, because I easily > "share" outages demanded by other components. > In such case PS adds almost no value, and is not the factor of banking > system availability. > > Just my €0.02 > > -- > Radoslaw Skorupka > Lodz, Poland > > > -- > BRE Bank SA > ul. Senatorska 18 > 00-950 Warszawa > www.brebank.pl > The issue that needs addressing is: Why, when technology has reached our current level, is ANY customer visible downtime acceptable? Those "other components" could, with today's capability, be properly redundant and designed/coded/implemented such that the "SYSTEM" is never down at the public interfaces. It happens, that after dark on a weekend is MY best time to do my finances. Yet, that is often when the "system is undergoing maintenance. And the folks parked in daylight at the call center couldn't even understand my irritation. I know that my little site at a University can't afford 9 nines, but damn it, the credit card companies should be able to afford it, their fees are significant to both buyer and seller. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Not all Federal data centers see any value in dinosaurs, even dinosaurs with penguins. Neither dinosaur nor penguin is as good as Windows. Management will suffer to have network infrastructure running under some form of linux (Centos or Fedora, but nothing with a support contract). But Webservers, Database servers, file servers, print servers, they belong to Windows because the true Federal Desktop is Windows and everything must be like that. /Tom Kern On Sun, 22 Jun 2008 07:33:40 -0400, Richards, Robert B. <[EMAIL PROTECTED]> wrote: >Dave, > >Most major banks that I am aware of do have parallel sysplexes in their >data centers. I suspect that we are not talking about mainframe system >availability here but rather whether their distributed servers which are >running the front-end banking applications are highly available. High >availability on IBM's System p is on the verge of becoming a real >possibility since the Power 6/AIX 6 stuff was announced, but that >infrastructure design certainly is not widespread across the banking >footprint as of yet! > >I wouldn't say we are necessarily losing the battle. Linux on System z >(among other things) has been working on leveling the playing field for >awhile now. Server consolidation on "Project Green" type initiatives, >etc. are also in vogue. The smarter shops are attempting to stop the >unrestrained proliferation of blades and racks. > >"We've only begun to fight!" > >Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Ed Finnell) writes: > They do, but my suspicion is that in multi-tiered model some things > got overlooked in the PCI/HIPPA redesign-all those bytes, so little time! previous post (in this thread) http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle mentioned a post in information security blog. the main part of that particular blog thread was related to majority of the breaches that get in the news (something that PCI has been targeted at addressing). the thread started out regarding a study that something like 84% of IT managers believe they need to comply with breach notification and 61% don't even believe they should notify law enforcement. parts of the thread is repeated here http://www.garlic.com/~lynn/2008i.html#21 Worst Security Threats? after working on what is now frequently referred to as *electronic commerce* (mentioned earlier in this thread), we were brought into the x9a10 financial standard working group which in the mid-90s, had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. as part of that we did detailed end-to-end, risk, threat, and vulnerability studies. a couple highlights 1) security proportional to risk ... crooks/attackers may be able to outspend defenders 100-to-1. the information for the crooks is basically worth the value of the account balance or credit limit. the information for the merchants is basically worth some part of profit off the transaction. the value of the information to the crooks may be worth 100 times more than the value to the merchants ... as a result, the crooks may be able to outspend 100 times attacking the system. traditional military lore has something like attackers needing 3-5 times the resources to attack a fortified fixed position. potentially being able to marshall 100 times the resources almost guarantees a breach someplace. 2) account number and transaction information has diametrically opposing security requirements ... on one hand the information has to be kept confidential and never used or divulged (countermeasure to account fraud flavor of identity theft). on the other hand, the information is required to be available for numerous business processes as part of normal transaction processing. we've periodically commented that even if the planet was buried under miles of information hiding cryptography, that it still couldn't prevent information leakage. so one of the things done in x9a10 as part of the x9.59 financial transaction standard was to slightly tweak the paradigm ... making the information useless to the attackers. x9a10 & x9.59 didn't address any issues regarding eliminating breaches ... it just eliminated the threat/risk from such breaches (and/or information leakage). http://www.garlic.com/~lynn/x959.html#x959 now the major use of SSL in the world today is that previously mentioned stuff now frequently referred to as *electronic commerce* ... where it is used to hide account number and payment transaction information. The x9.59 financial standard effectively eliminates that SSL use since it no longer is necessary to hide that information (as countermeasure to account fraud form of identity theft). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Loosing the battle? There are so many cultures, shops, platforms and thinks. You reach the goals when you work so hard for that, as individual or workgroup , not only ensuring your position. All of us need to worry about the talent inside of us, not for technology, because technology was made for us and the explotation depends of our skills. Luis Miguel Martinez Senior IT Specialist --- El dom 22-jun-08, Anne & Lynn Wheeler <[EMAIL PROTECTED]> escribió: De:: Anne & Lynn Wheeler <[EMAIL PROTECTED]> Asunto: Re: We're losing the battle A: IBM-MAIN@BAMA.UA.EDU Fecha: domingo, 22 junio, 2008, 12:02 pm The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (R.S.) writes: > Parallel Sysplex has nothing to do with that. You're talking about > *banking system* which consist of many elements, optionally including > > PS. > Even if the PS is there and is really available, it doesn't mean the > system (banking system) will be available. I work under SLA which > allows me to have 8 hours of planned outage per year. No sysplex. I > have never reached the limit, because I easily "share" outages > demanded by other components. In such case PS adds almost no value, > and is not the factor of banking system availability. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle working on ha/cmp we looked at customer that required five-nines availability ... five minute outage (planned & unplanned) per year. on the other hand ... one of the large financial transaction networks has claimed 100% availability over extended number of years ... using triple redundant IMS hot-standby and multiple geographic locations. slight drift ... recent Information Security blog post http://www.garlic.com/~lynn/2008i.html#17 Does anyone have any IT data center disaster stories? made a passing reference in previous post with regard to contention with the communication division. the tcp/ip mainframe product had significant performance issues ... consuming nearly a full 3090 processor getting 44kbytes/sec thruput. I enhanced the product with RFC1044 support and in some tuning tests at Cray research got 1mbyte/sec (hardware limitation) sustained between a Cray and a 4341-clone (using only a modest amount of the 4341) ... aka nearly three orders of magnitude increase in the ratio of bytes transferred per instruction executed. another area of conflict ... as part of the hsdt project http://www.garlic.com/~lynn/subnetwork.html#hsdt the friday before we were to leave on trip to the other side of the pacific to discuss some custom built hardware for hsdt ... somebody (from the communication division) announced a new online conference in the area of high-speed communication ... and specified the following definitions: low-speed <9.6kbits medium-speed19.2kbits high-speed 56kbits very high-speed 1.5mbits the following monday on the wall of conference room on the other side of the pacific were these definitions: low-speed <20mbits medium-speed100mbits high-speed 200-300mbits very high-speed >600mbits -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Yahoo! Deportes Beta ¡No te pierdas lo último sobre el torneo clausura 2008! Entérate aquí http://deportes.yahoo.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (R.S.) writes: > Parallel Sysplex has nothing to do with that. You're talking about > *banking system* which consist of many elements, optionally including > > PS. > Even if the PS is there and is really available, it doesn't mean the > system (banking system) will be available. I work under SLA which > allows me to have 8 hours of planned outage per year. No sysplex. I > have never reached the limit, because I easily "share" outages > demanded by other components. In such case PS adds almost no value, > and is not the factor of banking system availability. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle working on ha/cmp we looked at customer that required five-nines availability ... five minute outage (planned & unplanned) per year. on the other hand ... one of the large financial transaction networks has claimed 100% availability over extended number of years ... using triple redundant IMS hot-standby and multiple geographic locations. slight drift ... recent Information Security blog post http://www.garlic.com/~lynn/2008i.html#17 Does anyone have any IT data center disaster stories? made a passing reference in previous post with regard to contention with the communication division. the tcp/ip mainframe product had significant performance issues ... consuming nearly a full 3090 processor getting 44kbytes/sec thruput. I enhanced the product with RFC1044 support and in some tuning tests at Cray research got 1mbyte/sec (hardware limitation) sustained between a Cray and a 4341-clone (using only a modest amount of the 4341) ... aka nearly three orders of magnitude increase in the ratio of bytes transferred per instruction executed. another area of conflict ... as part of the hsdt project http://www.garlic.com/~lynn/subnetwork.html#hsdt the friday before we were to leave on trip to the other side of the pacific to discuss some custom built hardware for hsdt ... somebody (from the communication division) announced a new online conference in the area of high-speed communication ... and specified the following definitions: low-speed <9.6kbits medium-speed19.2kbits high-speed 56kbits very high-speed 1.5mbits the following monday on the wall of conference room on the other side of the pacific were these definitions: low-speed <20mbits medium-speed100mbits high-speed 200-300mbits very high-speed >600mbits -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
In a message dated 6/22/2008 12:46:04 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: It seems that I thought major banks had Sysplexes behind them, I guess not! :( >> They do, but my suspicion is that in multi-tiered model some things got overlooked in the PCI/HIPPA redesign-all those bytes, so little time! **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Gibney, Dave wrote: I tried to access two different credit card sites just now. Both can't help due to system maintenance. One site announced maintenance hours starting 2am, or one hour from when I started trying. It seems that I thought major banks had Sysplexes behind them, I guess not! :( Parallel Sysplex has nothing to do with that. You're talking about *banking system* which consist of many elements, optionally including PS. Even if the PS is there and is really available, it doesn't mean the system (banking system) will be available. I work under SLA which allows me to have 8 hours of planned outage per year. No sysplex. I have never reached the limit, because I easily "share" outages demanded by other components. In such case PS adds almost no value, and is not the factor of banking system availability. Just my €0.02 -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Richards, Robert B.) writes: > Most major banks that I am aware of do have parallel sysplexes in their > data centers. I suspect that we are not talking about mainframe system > availability here but rather whether their distributed servers which are > running the front-end banking applications are highly available. High > availability on IBM's System p is on the verge of becoming a real > possibility since the Power 6/AIX 6 stuff was announced, but that > infrastructure design certainly is not widespread across the banking > footprint as of yet! > > I wouldn't say we are necessarily losing the battle. Linux on System z > (among other things) has been working on leveling the playing field for > awhile now. Server consolidation on "Project Green" type initiatives, > etc. are also in vogue. The smarter shops are attempting to stop the > unrestrained proliferation of blades and racks. ha/cmp project started two decades ago http://www.garlic.com/~lynn/subtopic.html#hacmp old post about deploying ha/cmp scaleup before the project got redirected and we were told to not work on anything more than four processors http://www.garlic.com/~lynn/95.html#13 misc. old email regarding ha/cmp scaleup activity http://www.garlic.com/~lynn/lhwemail.html#medusa i've frequently commented that (much) earlier, my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture where she created peer-coupled shared data ... misc. past posts http://www.garlic.com/~lynn/subtopic.html#shareddata but, except for IMS hot-standby ... it saw very little take-up until much later with sysplex (and parallel sysplex) activity ... which contributed to her not staying very long in the position. another issue in that period was that she had constant battles with the communication division over protocols used for the infrastructure. in the early sna days ... she had co-authoried "peer-coupled networking" architecture (AWP39) ... so some in the communication division may viewed efforts as somewhat competitive. while she was in POK, they had come to a (temporary) truce ... where communication protocols had to be used for anything that crossed the boundary of the glasshouse ... but she could specify the protocols used for peer-coupled operation within the walls of the glasshouse. part of the ha/cmp not on mainframe platform was avoiding being limited by communication division. for some topic drift, other past posts mentioning conflict with communication division when we came up with 3-tier architecture and were out pitching it to customer executives http://www.garlic.com/~lynn/subnetwork.html#3tier recent ha/cmp related post (from thread mentioning tribute to Jim Gray) http://www.garlic.com/~lynn/2008i.html#50 Microsoft versus Digital Equipment Corporation http://www.garlic.com/~lynn/2008i.html#51 Microsoft versus Digital Equipment Corporation the first talk at the tribute was by Bruce Lindsay mentioning that Jim's formalizing of transaction semantics was the great enabler for online transactions (providing the necessary trust in computer operation to move off the manual/paper operation). now related to the meeting mentioned in this referenced post http://www.garlic.com/~lynn/95.html#13 two of the people mentioned in the meeting, later show up in a small client/servere startup responsible for something called a commerce server. we were called in to consult because they wanted to do transactions on the server ... and they had this technology that the startup had invented called SSL which they wanted to use. As part of doing payment transactions on the server ... there was the creation of something called a "payment gateway" that servers would interact with. lots of past posts mentioning this thing called payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway btw, we used ha/cmp for the payment gateway implementation (with some number of enhancements and compensating procedures). this is now frequently referred to as "electronic commerce". recent post related some other aspects of the period (in an information security blog) http://www.garlic.com/~lynn/2008i.html#94 Lynn - You keep using the term "we" - who is "we"? one of the other things mentioned at the tribute, was Jim's work on analysing where the majority of outages are happening (frequently cited study that outages are rairly hardware anymore). when we were out marketing ha/cmp product, we had coined the terms "disaster survivability" and "geographic survivability" ... to differentiate from simple disaster/recovery. we were also asked to write a section for the corporate continuous availability strategy document. however, the section was removed because both rochester and POK complained that they wouldn't be able to match (what we were doing) for some number of years http://www.garlic.co
Re: We're losing the battle
Dave, Most major banks that I am aware of do have parallel sysplexes in their data centers. I suspect that we are not talking about mainframe system availability here but rather whether their distributed servers which are running the front-end banking applications are highly available. High availability on IBM's System p is on the verge of becoming a real possibility since the Power 6/AIX 6 stuff was announced, but that infrastructure design certainly is not widespread across the banking footprint as of yet! I wouldn't say we are necessarily losing the battle. Linux on System z (among other things) has been working on leveling the playing field for awhile now. Server consolidation on "Project Green" type initiatives, etc. are also in vogue. The smarter shops are attempting to stop the unrestrained proliferation of blades and racks. "We've only begun to fight!" Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Sunday, June 22, 2008 1:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: We're losing the battle I tried to access two different credit card sites just now. Both can't help due to system maintenance. One site announced maintenance hours starting 2am, or one hour from when I started trying. It seems that I thought major banks had Sysplexes behind them, I guess not! :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
We're losing the battle
I tried to access two different credit card sites just now. Both can't help due to system maintenance. One site announced maintenance hours starting 2am, or one hour from when I started trying. It seems that I thought major banks had Sysplexes behind them, I guess not! :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
