Re: High order bit in 31/24 bit address
In [EMAIL PROTECTED], on 11/07/2007 at 02:32 PM, Phil Payne [EMAIL PROTECTED] said: Back then, though, IBM perceived the lack of a stack as a marketing _adantage_. The competition (Burroughs, CDC, ICL) was all stack-based. No. Not even Burroughs was all stack based and CDC wasn't at all. To say nothing of the remaining dwarves. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High order bit in 31/24 bit address
In [EMAIL PROTECTED], on 11/07/2007 at 03:42 PM, Timothy Sipples [EMAIL PROTECTED] said: And one also wonders whether it would have been so easy for the large EBCDIC installed base What latge EBCDIC install base? EBCDIC was new on the S/360. As we all know, No. EBCDIC puts the letters in the correct numerical order, collating uppercase and lowercase: AaBbCc C1, 81, C2, 82, C3, 83,...? No way, José. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High order bit in 31/24 bit address
On Tue, 20 Nov 2007 15:44:46 -0400, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: ... And one also wonders whether it would have been so easy for the large EBCDIC installed base What latge EBCDIC install base? EBCDIC was new on the S/360. ... I wondered about that, too, but assumed he meant BCD. ... C1, 81, C2, 82, C3, 83,...? No way, José. ... Better dig deeper in your in basket. He retracted that. 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: ATMs (Was: High order bit in 31/24 bit address)
My first real job was in 1984 with Texas American (Bank) Services in Fort Worth. When I started we were in the process of insourcing all of our applications from EDS and one of the first three we brought back in house was ATM processing (followed by ACH and Corporate Trust). TASI built a new operations center in Bedford to be closer to the airport (for cash letter transit) and Memorial Day weekend, 1984 we moved two 3890 sorters, a 3083, 4341 and a 370/148. During the move, IBM loaned us a 4341 and DASD that ran the ATMs and the interface to PULSE for the weekend. Does anyone remember the CICS-based ATM software that the old MTech wrote and marketed? Later on in 1985 I did a tour of duty with UCCEL's ACM/CTS (Asset Card Manager/Consumer Transaction System) CICS=based ATM / card management software. Gary Pat O'Keefe said; That sounds pretty much like the way it works at a bank I am somewhat famiiar with (i.e., my employer). Chris Craddock said; Yep! And oh by the way, it also sounds exactly like the bank that was my employer twenty-mumble years ago. Tandems are extremely common as front-end switch systems in the financial sector. They are not so widely used to process the actual back-end trx and dbms work, but there are quite a few of those too. They did (and still do) a very decent job of 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
Connex was RE: ATMs (Was: High order bit in 31/24 bit address)
I have a wine coloured mug that says Connex on one side and A.O. Smith Data Systems on the other. I worked at a large Canadian bank and we had a joint project going with IBM in the late 80s/early 90s. We installed the Connex software for an internal system with an eye to IBM marketing it as part of the joint project. This was not EFT related at all and I think it was before any of the other banks used it for the inter-bank EFT. The Connex team (mostly one guy - a contractor out of San Francisco who eventually went to Compuware) wrote an API to provide the services our software needed. Our software provided store and forward and workflow services for messaging between the PC and the mainframe. This was phase I. While we were working on phase II, we started talking to IBM Hursley about a new store and forward system they were working on. It was called MQ and was pretty much the death knell for our joint project. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, November 10, 2007 8:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ATMs (Was: High order bit in 31/24 bit address) AOSmith=Deluxe=DeluxeData=DeluxeEelectronicPaymentSystems(DEPS)=eFu nds. You're correct! My bad! It was Deluxe. Fault of a failing memory. (Still thought it was a funny choice of name -- in a league with ACME) -- 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
TYME History was Re: ATMs (Was: High order bit in 31/24 bit address)
On Fri, 9 Nov 2007 17:07:43 -0600, Eric Bielefeld eric- [EMAIL PROTECTED] wrote: As long as its Friday, and there are many posts about ATMs, I'll add mine. I can't remember when I got my first TYME card. It was somewhere between 1975 and 1978, I think. First TYME transaction was in December 1976. Wisconsin is the home of TYME, which stood for Take Your Money Everywhere. I think AO Smith developed the TYME system. I'm pretty sure the company that takes care of it, which was a division of AO Smith, is now called eFunds. (Now I'm sounding like Ed). Actually the TYME system was written by IBM contract programmers and most (if not all) of the work was done at First Wisconsin Bank. I started here in January of 1977. My first manager was had been an analyst for this project. TYME was a TCAM based system and was run on First Wisconsin's systems. http://findarticles.com/p/articles/mi_m0EIN/is_2000_Dec_19/ai_68207822 This article list the four banks that were the ones responsible for it. As Eric indicates it was moved (I don't remember the year) to Deluxe Systems to eliminate the conflict of interest of having First Wisconsin running the system. Doug Henry USBANK (list of bank's name change : First Wisconsin - Firstar - USBANK) -- 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: TYME History was Re: ATMs (Was: High order bit in 31/24 bit address)
Doug, Thanks for correcting my faulty memory. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Doug Henry [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, November 12, 2007 2:38 PM Subject: TYME History was Re: ATMs (Was: High order bit in 31/24 bit address) On Fri, 9 Nov 2007 17:07:43 -0600, Eric Bielefeld eric- [EMAIL PROTECTED] wrote: As long as its Friday, and there are many posts about ATMs, I'll add mine. I can't remember when I got my first TYME card. It was somewhere between 1975 and 1978, I think. First TYME transaction was in December 1976. Wisconsin is the home of TYME, which stood for Take Your Money Everywhere. I think AO Smith developed the TYME system. I'm pretty sure the company that takes care of it, which was a division of AO Smith, is now called eFunds. (Now I'm sounding like Ed). Actually the TYME system was written by IBM contract programmers and most (if not all) of the work was done at First Wisconsin Bank. I started here in January of 1977. My first manager was had been an analyst for this project. TYME was a TCAM based system and was run on First Wisconsin's systems. http://findarticles.com/p/articles/mi_m0EIN/is_2000_Dec_19/ai_68207822 This article list the four banks that were the ones responsible for it. As Eric indicates it was moved (I don't remember the year) to Deluxe Systems to eliminate the conflict of interest of having First Wisconsin running the system. Doug Henry USBANK (list of bank's name change : First Wisconsin - Firstar - USBANK) -- 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: ATMs (Was: High order bit in 31/24 bit address)
AOSmith=Deluxe=DeluxeData=DeluxeEelectronicPaymentSystems(DEPS)=eFunds. Never saw them called Acme! Date: Sat, 10 Nov 2007 00:05:14 + From: [EMAIL PROTECTED] Subject: Re: ATMs (Was: High order bit in 31/24 bit address) To: IBM-MAIN@BAMA.UA.EDU The original company name was ACME Software and they changed it to eFunds. _ Peek-a-boo FREE Tricks Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us -- 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: ATMs (Was: High order bit in 31/24 bit address)
AOSmith=Deluxe=DeluxeData=DeluxeEelectronicPaymentSystems(DEPS)=eFunds. You're correct! My bad! It was Deluxe. Fault of a failing memory. (Still thought it was a funny choice of name -- in a league with ACME) - 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: ATMs (Was: High order bit in 31/24 bit address)
snip--- What's honesty when talking to vendors? Had one deliver a 'so and so is now a vv shop'. Well they were handling the ATM traffic but as best we could tell they were about 0.01% of total processing capacity. --unsnip--- Had a hardware vendor tell me the same thing once. He didn't know that the VP of MIS was a close friend of mine. Exit one vendor, never to be alloweed back in the front door! I really enjoyed reading him his pedigree! :-) -- 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: ATMs (Was: High order bit in 31/24 bit address)
At least most ATMs are still connected to mainframes. Aren't they? Most I dealt with in the mid-1980s were Tandem NonStop. It's an interesting bit of history that the first Tandem machine wasn't available until 1976, well after the first electronic ATM (1967) and lots of other ATMs. From what I've read the first networked ATM appeared in 1968, and the first popular ATM (i.e. same model placed into service by more than one bank) was the IBM 2984 starting in 1973. The IBM 2984 offered variable cash withdrawals and instantly deducted from your account, so it was 100% on-line -- 34 years ago. (I remember my father using our local bank's first ATM, newly installed, when I was a young child. It seemed like magic.) Presumably most if not all of these ATMs connected to IBM System/360s and /370s. Tandem came along after almost a decade of ATMs. But leaving aside possible dumb boxes in the middle, yes, some ATMs are still connected to HP NonStop (formerly Tandem) machines acting as switches, thence to IBM mainframes. ACI Worldwide's BASE24-eps is one very popular ATM solution, for example. A few years ago BASE24 became available for z/OS, so you can guess the trend. (That and, I assume, the fact virtually all Western banks now keep z/OS and core transaction systems running 24x365. Tandem's raison d'être, to keep the ATMs up and queuing limited transactions during nightly or weekly scheduled outage, no longer applies with modern 24 hour SLAs. Think CICS TS/CICSplex, DFSMStvs and others, DB2 data sharing, MQ shared queues, IMS HALDB/IMSplex, z/TPF, Sysplex, etc., etc.) Here's some technical information: http://www.redbooks.ibm.com/abstracts/sg247268.html http://www.redbooks.ibm.com/abstracts/redp4337.html And then there are Japanese ATMs, but that's a digression for another time. - - - - - 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: ATMs (Was: High order bit in 31/24 bit address)
Timothy Sipples wrote: But leaving aside possible dumb boxes in the middle, yes, some ATMs are still connected to HP NonStop (formerly Tandem) machines acting as switches, thence to IBM mainframes. ACI Worldwide's BASE24-eps is one very popular ATM solution, for example. A few years ago BASE24 became available for z/OS, so you can guess the trend. Yes, I can. AFAIK z/OS version is not popular one. I know *big* ATM installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. Timothy: I like mainframes, I have personal interest in mainframe business growth (at least survive), but I see no reason to be unhonest. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: ATMs (Was: High order bit in 31/24 bit address)
In response to what I said: A few years ago BASE24 became available for z/OS, so you can guess the trend. Radoslaw Skorupka writes: Yes, I can. AFAIK z/OS version is not popular one. I know *big* ATM installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. Timothy: I like mainframes, I have personal interest in mainframe business growth (at least survive), but I see no reason to be unhonest. Nor do I see a reason to be dishonest. Which is why I endeavor not to be. We apparently have different evidence in front of us. You apparently observed one organization that migrated ATM switching from z/OS to HP NonStop. (I'm not sure when, so I'm curious about that. If it's z/OS, presumably it was after the year 2000?) Perhaps you have other information as well. I'm not at all surprised that ACI would say, at least at some point in time, that most of their installations are not on the IBM mainframe. When your product only runs on Tandem (practically speaking) for some time, it's hard to have any other starting point. :-) I said you can guess the trend based on my observations. As I said, apparently ours are different. I assume you're honest in your observations, and I know I am in mine. - - - - - 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: High order bit in 31/24 bit address
On 8 Nov 2007 14:04:13 -0800, [EMAIL PROTECTED] (Robert A. Rosenberg) wrote: The one who decided that if they were in a car, they'd be in the back left seat behind the chauffeur or cab driver. I never let my chauffeur use the ATM. -- 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: ATMs (Was: High order bit in 31/24 bit address)
Ed Finnell wrote: In a message dated 11/9/2007 4:14:55 A.M. Central Standard Time, R.Skorupka@(*Ed, I'd prefer to mask my address*) writes: installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. What's honesty when talking to vendors? Had one deliver a 'so and so is now a vv shop'. Well they were handling the ATM traffic but as best we could tell they were about 0.01% of total processing capacity. I believe the platform is rather neutral for this vendor. Obviously I can't believe in vendor's words, when he's trying to sell something. But it wasn't the case. BTW: I'm not sure about one ATM network in Poland, but surely all the rest is not on mainframe. Even in those few banks using mainframes. BTW2: I'm pretty sure, that mainframe is very good platform for ATMs. I heard about huge ATM networks on mainframe. BTW3: I would like to see any statistics saysing about ATM market, not devices like Diebold or NCR, but supporting systems, like BASE24, TRANS24. Of coruse with platform specified. I would be happy seeing large marketshare of mainframes. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: ATMs (Was: High order bit in 31/24 bit address)
In a message dated 11/9/2007 4:14:55 A.M. Central Standard Time, [EMAIL PROTECTED] writes: installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. What's honesty when talking to vendors? Had one deliver a 'so and so is now a vv shop'. Well they were handling the ATM traffic but as best we could tell they were about 0.01% of total processing capacity. ** See what's new at http://www.aol.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: ATMs (Was: High order bit in 31/24 bit address)
ACI has reason to push their Nonstop side of things; that's where they have the least competition. On z/OS, they are not the only game in town. I am aware of at least one vendor that has an EFT Switch that runs on z/OS, Nonstop and 'Nix. IMHO the IBM mainframe is the most suitable platform for EFT/ATM/POS. With parallel sysplex it has fault tolerance which was the main reason that Tandem was the traditional platform of choice. It also has the best cryptographic facility; I've seen papers that claim it to be ten times faster than the other options. It's also inherently more secure, being a tamper-proof integrated facility. Unencrypted keys and data never see the light of day. The other options are outboard and require I/O to perform their function. Most financial institutions use mainframe back-ends. Whether they use mainframes or something else for their front-ends usually comes down to politics and bigotry, depending on who's making the decisions. If the (wo)man in charge came up through the Tandem ranks, well that's probably what they use. Date: Sat, 10 Nov 2007 00:18:08 +0900 From: [EMAIL PROTECTED] Subject: Re: ATMs (Was: High order bit in 31/24 bit address) To: IBM-MAIN@BAMA.UA.EDU In response to what I said: A few years ago BASE24 became available for z/OS, so you can guess the trend. Radoslaw Skorupka writes: Yes, I can. AFAIK z/OS version is not popular one. I know *big* ATM installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. Timothy: I like mainframes, I have personal interest in mainframe business growth (at least survive), but I see no reason to be unhonest. Nor do I see a reason to be dishonest. Which is why I endeavor not to be. We apparently have different evidence in front of us. You apparently observed one organization that migrated ATM switching from z/OS to HP NonStop. (I'm not sure when, so I'm curious about that. If it's z/OS, presumably it was after the year 2000?) Perhaps you have other information as well. I'm not at all surprised that ACI would say, at least at some point in time, that most of their installations are not on the IBM mainframe. When your product only runs on Tandem (practically speaking) for some time, it's hard to have any other starting point. :-) I said you can guess the trend based on my observations. As I said, apparently ours are different. I assume you're honest in your observations, and I know I am in mine. - - - - - 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 _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews -- 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: ATMs (Was: High order bit in 31/24 bit address)
On Nov 9, 2007, at 2:49 AM, Timothy Sipples wrote: At least most ATMs are still connected to mainframes. Aren't they? Most I dealt with in the mid-1980s were Tandem NonStop. It's an interesting bit of history that the first Tandem machine wasn't available until 1976, well after the first electronic ATM (1967) and lots of other ATMs. From what I've read the first networked ATM appeared in 1968, and the first popular ATM (i.e. same model placed into service by more than one bank) was the IBM 2984 starting in 1973. The IBM 2984 offered variable cash withdrawals and instantly deducted from your account, so it was 100% on-line -- 34 years ago. (I remember my father using our local bank's first ATM, newly installed, when I was a young child. It seemed like magic.) Presumably most if not all of these ATMs connected to IBM System/360s and /370s. Tandem came along after almost a decade of ATMs. But leaving aside possible dumb boxes in the middle, yes, some ATMs are still connected to HP NonStop (formerly Tandem) machines acting as switches, thence to IBM mainframes. ACI Worldwide's BASE24-eps is one very popular ATM solution, for example. A few years ago BASE24 became available for z/OS, so you can guess the trend. (That and, I assume, the fact virtually all Western banks now keep z/OS and core transaction systems running 24x365. Tandem's raison d'être, to keep the ATMs up and queuing limited transactions during nightly or weekly scheduled outage, no longer applies with modern 24 hour SLAs. Think CICS TS/CICSplex, DFSMStvs and others, DB2 data sharing, MQ shared queues, IMS HALDB/IMSplex, z/TPF, Sysplex, etc., etc.) Here's some technical information: http://www.redbooks.ibm.com/abstracts/sg247268.html http://www.redbooks.ibm.com/abstracts/redp4337.html And then there are Japanese ATMs, but that's a digression for another time. Timothy, Thanks for the last entry. In the late 80's (early 90's?) we picked up a Tandem at the insistence of management. It was put in the data center and *NEVER* powered up it sat there like all good boat anchors. I never heard who was responsible for the coming of the the machine. It must have been high up though or I would have heard. At the time were were CICS and had IDMS. A few years go by and CICS and DB2 are there and are still there. Why they needed it was anybodies guess. But I guess they had to spend money to show the brokerage houses we were on the spot. We had pretty good uptime, if there was an outage it was a TP issue. I think (I could be wrong) they only outage we had was an MVS crash and that was for 30 minutes. This was over 10 years, I worked it out and it was in the 99.9 range but I guess that wasn't good enough. There might have been IDMS problems that I never heard of so the numbers may have been different from the above. The IDMS DBA's were quite secretive, Ed -- 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: ATMs (Was: High order bit in 31/24 bit address)
On Nov 9, 2007, at 12:17 PM, J R wrote: -SNIP-- Most financial institutions use mainframe back-ends. Whether they use mainframes or something else for their front-ends usually comes down to politics and bigotry, depending on who's making the decisions. If the (wo)man in charge came up through the Tandem ranks, well that's probably what they use. J R: I have worked for 2 banks in my life. The First one (out of business now) had their online savings system on the MF no PC's (or mini's) anywhere to be seen. The second was different. I don't pretend to understand it but can skimpily talk about it. The MF was the back end and if it was down we were penalized (read big bucks) if it was down as a mini (someplace) took over. I never banked there (for various unrelated reasons). The system I use in real life (ATM) has never been down (at least when I tried to use it) so I guess I am a happy customer (read ATM not the bank). Ed -- 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: ATMs (Was: High order bit in 31/24 bit address)
My experience has shown that most ATM's are 'connected' to HP/Tandem NonStop systems. The bank I support does use a Tandem NonStop machine to 'drive' their 1500 some ATM's. The 'driving' of the ATM's is defined as loading/managing the ATM machine's software, receiving/transmitting messages to/from the ATM's, collecting error information, etc. When the ATM user requests a 'function' that needs to check the user's account balance, the Tandem application software ( called: Base24 ) builds a message to our back- end CICS applications. So, the ATM is 'kinda' connected to the mainframe, just not directly. However, I can tell you that when I first began working here in 1991, we had a DOS/VSE system that directly controlled the ATMs. The CICS application was in-house written, somewhat fragile, and since the O/S was DOS/VSE, nothing like Parallel Sysplex, DB2 data sharing, etc. I had a 15 minute outage window, once a month to maintenance the O/S, hardware, etc. There had been a project to replace the HP/Tandem Base24 system with a z/OS-based Base24-eps solution. However, that project never really got going. HTH Glenn Miller -- 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
ATMs (Was: High order bit in 31/24 bit address)
Resending. Forgot to remove the crappola at the bottom. ;-) Date: Fri, 9 Nov 2007 13:17:10 -0500 ACI has reason to push their Nonstop side of things; that's where they have the least competition. On z/OS, they are not the only game in town. I am aware of at least one vendor that has an EFT Switch that runs on z/OS, Nonstop and 'Nix. IMHO the IBM mainframe is the most suitable platform for EFT/ATM/POS. With parallel sysplex it has fault tolerance which was the main reason that Tandem was the traditional platform of choice. It also has the best cryptographic facility; I've seen papers that claim it to be ten times faster than the other options. It's also inherently more secure, being a tamper-proof integrated facility. Unencrypted keys and data never see the light of day. The other options are outboard and require I/O to perform their function. Most financial institutions use mainframe back-ends. Whether they use mainframes or something else for their front-ends usually comes down to politics and bigotry, depending on who's making the decisions. If the (wo)man in charge came up through the Tandem ranks, well that's probably what they use.Date: Sat, 10 Nov 2007 00:18:08 +0900 From: [EMAIL PROTECTED] Subject: Re: ATMs (Was: High order bit in 31/24 bit address) To: IBM-MAIN@BAMA.UA.EDU In response to what I said: A few years ago BASE24 became available for z/OS, so you can guess the trend. Radoslaw Skorupka writes: Yes, I can. AFAIK z/OS version is not popular one. I know *big* ATM installation which migrated from z/OS to NonStop. People from ACI claimed that most of their installtions are not on mainframe. Timothy: I like mainframes, I have personal interest in mainframe business growth (at least survive), but I see no reason to be unhonest. Nor do I see a reason to be dishonest. Which is why I endeavor not to be. We apparently have different evidence in front of us. You apparently observed one organization that migrated ATM switching from z/OS to HP NonStop. (I'm not sure when, so I'm curious about that. If it's z/OS, presumably it was after the year 2000?) Perhaps you have other information as well. I'm not at all surprised that ACI would say, at least at some point in time, that most of their installations are not on the IBM mainframe. When your product only runs on Tandem (practically speaking) for some time, it's hard to have any other starting point. :-) I said you can guess the trend based on my observations. As I said, apparently ours are different. I assume you're honest in your observations, and I know I am in mine. - - - - - 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] _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews -- 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: ATMs (Was: High order bit in 31/24 bit address)
On Fri, 9 Nov 2007 13:10:04 -0600, Glenn Miller [EMAIL PROTECTED] wrote: My experience has shown that most ATM's are 'connected' to HP/Tandem NonStop systems. ... The 'driving' of the ATM's is defined as loading/managing the ATM machine's software, receiving/transmitting messages to/from the ATM's, collecting error information, etc. When the ATM user requests a 'function' that needs to check the user's account balance, the Tandem application software ( called: Base24 ) builds a message to our back- end CICS applications. So, the ATM is 'kinda' connected to the mainframe, just not directly. ... That sounds pretty much like the way it works at a bank I am somewhat famiiar with (i.e., my employer). I don't know the details (and probably shouldn't mention them if I did) but they ATMs effectively talk with the mainframes for any mainframe-based transactions, but the Tandem/HP is always there, and stands in for the mainframe if anything slows down communication with the mainframe transactions. Because of the Tandems, the ATMs are never offline. The Tandem applications go into some sort of store and forward mode when communication with mainframe's transaction servers gets bogged down for any reason. 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: ATMs (Was: High order bit in 31/24 bit address)
My experience has shown that most ATM's are 'connected' to HP/Tandem NonStop systems There is a package (CONNEX) originally written for tandem that was ported to z/OS (ESA at the time) used for managing ATM's Credit Card machines. Two banks in Canada and a large Australian bank use it. The original name of the company supplying the product always made me laugh: Acme Software. Sounds like where the coyote got his computer programmes from. - 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: ATMs (Was: High order bit in 31/24 bit address)
As long as its Friday, and there are many posts about ATMs, I'll add mine. I can't remember when I got my first TYME card. It was somewhere between 1975 and 1978, I think. I remember when Milwaukee County promoted me to a Sysprog, there was an ATM machine across the street in the County Courthouse. It was so nice to just walk across the street at lunch hour and deposit my check, instead of having to go to the bank. Wisconsin is the home of TYME, which stood for Take Your Money Everywhere. I don't think they have called it that for a long time, but I know Wisconsin was one of the first states to come out with ATMs shareable by different banks. When they first started advertising, they said that you would never have to pay any fees to take your money out, and I never did pay fees for a long time. I still don't pay fees, but then I know which ATMs to go to. I also take out money when I pay for my groceries, as they don't charge a fee for that. I also used to work at Marine Bank, long since eaten up by bigger banks. It says Chase on top of the building I used to work in now. Marine Bank used to run all their online systems under TCAM back then (1980 to 1984) when I worked for them. I remember one time during that time period seeing an article in the morning paper about the TYME system. One of the programmers at Marine bank had put in a change to the system, and every transaction came out wrong. I just realized I had a brain glitch - I can't remember what the consequences were, but it wasn't good. I think AO Smith developed the TYME system. I'm pretty sure the company that takes care of it, which was a division of AO Smith, is now called eFunds. (Now I'm sounding like Ed). Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Ted MacNEIL [EMAIL PROTECTED] There is a package (CONNEX) originally written for tandem that was ported to z/OS (ESA at the time) used for managing ATM's Credit Card machines. Two banks in Canada and a large Australian bank use it. The original name of the company supplying the product always made me laugh: Acme Software. Sounds like where the coyote got his computer programmes from. - 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: ATMs (Was: High order bit in 31/24 bit address)
The CONNEX product ( supplied by eFunds corporation ) was one of the products that was considered as a replacement for the Tandem/Base24 environment. The Base24-eps z/OS version was also considered. From what I saw, the CONNEX product really looked nice, very mainframe centric. For example, some amount ( maybe all, don't remember ) of the code is written in S/390 Assembler. Didn't require CICS to communicate with the ATMs. Supported DB2 as its back-end database and was written to support multiple copies of the CONNEX 'tasks' running on seperate z/OS / CECs, therefore truely capable of running at or very near 24x365. I would have been very interested to see it run. Glenn Miller -- 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: ATMs (Was: High order bit in 31/24 bit address)
From what I saw, the CONNEX product really looked nice, very mainframe centric. It was/is. I was told that it started on Tandem and moved to the mainframe. But, it has issues due to timings -- it doesn't handle paging very well. I worked at one of the two banks, in Canada, that used it. We had two performance analysts dedicated to it. IBM even did LSPR measurements against it. Originally, they were a re-markettor of CONNEX. The original company name was ACME Software and they changed it to eFunds. There is a lot of customisation you can do with the product. It's a flag/semiphore passing application, with store-and-forward capabilities. - 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: ATMs (Was: High order bit in 31/24 bit address) (resend)
---MAJOR SNIPPAGE--- A few years ago BASE24 became available for z/OS, so you can guess the trend. (That and, I assume, the fact virtually all Western banks now keep z/OS and core transaction systems running 24x365. Tandem's raison d'¾tre, to keep the ATMs up and queuing limited transactions during nightly or weekly scheduled outage, no longer applies with modern 24 hour SLAs. Think CICS TS/CICSplex, DFSMStvs and others, DB2 data sharing, MQ shared queues, IMS HALDB/IMSplex, z/TPF, Sysplex, etc., etc.) Here's some technical information: http://www.redbooks.ibm.com/abstracts/sg247268.html http://www.redbooks.ibm.com/abstracts/redp4337.html And then there are Japanese ATMs, but that's a digression for another time. Timothy, Thanks for the last entry. In the late 80's (early 90's?) we picked up a Tandem at the insistence of management. It was put in the data center and *NEVER* powered up it sat there like all good boat anchors. I never heard who was responsible for the coming of the the machine. It must have been high up though or I would have heard. At the time were were CICS and had IDMS. A few years go by and CICS and DB2 are there and are still there. Why they needed it was anybodies guess. But I guess they had to spend money to show the brokerage houses we were on the spot. We had pretty good uptime, if there was an outage it was a TP issue. I think (I could be wrong) they only outage we had was an MVS crash and that was for 30 minutes. This was over 10 years, I worked it out and it was in the 99.9 range but I guess that wasn't good enough. There might have been IDMS problems that I never heard of so the numbers may have been different from the above. The IDMS DBA's were quite secretive, Ed -- 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: ATMs (Was: High order bit in 31/24 bit address)
Pat O'Keefe said; That sounds pretty much like the way it works at a bank I am somewhat famiiar with (i.e., my employer). Yep! And oh by the way, it also sounds exactly like the bank that was my employer twenty-mumble years ago. Tandems are extremely common as front-end switch systems in the financial sector. They are not so widely used to process the actual back-end trx and dbms work, but there are quite a few of those too. They did (and still do) a very decent job of 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: High order bit in 31/24 bit address
Phil Payne wrote: You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. Exactly. I could argue my cell phone is more accessible for blind -- or even just aging -- people because it has keys. -- 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
Free Cell Phone (was RE: High order bit in 31/24 bit address)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Phil Payne wrote: You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. Exactly. I could argue my cell phone is more accessible for blind -- or even just aging -- people because it has keys. Speaking of cell phones. There's one somewhere on the northwest face of Carter Mountain in northwest Wyoming. Apparently fell out of my backpack sometime last week. It's yours if you find it, but you'll need to get a new SIM for it... No, the elk got away unscathed... -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: High order bit in 31/24 bit address
Rick, Ummm, the same person who figured out it was cheaper to just build all the ATM's with the same keypad, whether they were a drive-up one or one in the wall at the mall? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, November 08, 2007 11:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: High order bit in 31/24 bit address snip--- You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. Exactly. I could argue my cell phone is more accessible for blind -- or even just aging -- people because it has keys. --unsnip-- And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU -- 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: High order bit in 31/24 bit address
On Thu, 8 Nov 2007 11:58:10 -0600 Rick Fochtman [EMAIL PROTECTED] wrote: :And what intellectual paralytic decided that drive-up ATM's had to have :Braille keys? DU Nothing wrong with that - if placed on the passenger side, not the driver side. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: High order bit in 31/24 bit address
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman snip--- You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. Exactly. I could argue my cell phone is more accessible for blind -- or even just aging -- people because it has keys. --unsnip-- And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU Some cars have back seats, with side windows that roll down. AFAIK, one does not need a license, or sight, to be a back-seat driver.. :-) -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: High order bit in 31/24 bit address
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen On Thu, 8 Nov 2007 11:58:10 -0600 Rick Fochtman wrote: :And what intellectual paralytic decided that drive-up ATM's had to have :Braille keys? DU Nothing wrong with that - if placed on the passenger side, not the driver side. Back seat, driver's side.. -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: High order bit in 31/24 bit address
snip--- You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. Exactly. I could argue my cell phone is more accessible for blind -- or even just aging -- people because it has keys. --unsnip-- And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU -- 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
ATMs (Was: High order bit in 31/24 bit address)
Pommier, Rex R. wrote: Ummm, the same person who figured out it was cheaper to just build all the ATM's with the same keypad, whether they were a drive-up one or one in the wall at the mall? A bunch of low-life attorneys made a ton of money on this. But, it turns out that the braille keypads didn't really help because blind people can't read ATM screens! So, the NFB sued to have voice recognition/response systems installed on all ATMs. [Sigh.] Lucky for them it's the 21st century... At least most ATMs are still connected to mainframes. Aren't they? -- 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: High order bit in 31/24 bit address
And a lot of the roads have those bumps between the lanes. Aren't they for Braille driving? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Binyamin Dissen Sent: Thursday, November 08, 2007 12:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: High order bit in 31/24 bit address On Thu, 8 Nov 2007 11:58:10 -0600 Rick Fochtman [EMAIL PROTECTED] wrote: :And what intellectual paralytic decided that drive-up ATM's had to have :Braille keys? DU Nothing wrong with that - if placed on the passenger side, not the driver side. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: High order bit in 31/24 bit address
On 8 Nov 2007 09:59:30 -0800, [EMAIL PROTECTED] (Rick Fochtman) wrote: And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU Who wants to pay for the companies to supply two sets of ATM keys, one which can be used anywhere, and the other can only be used in walk-up ATMs? I'm not that dumb. -- 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: High order bit in 31/24 bit address
In a message dated 11/8/2007 12:46:39 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Who wants to pay for the companies to supply two sets of ATM keys, one which can be used anywhere, and the other can only be used in walk-up ATMs? Which is also why we now have assembly and instruction booklets printed in anywhere from two to ten languages. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.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: High order bit in 31/24 bit address
Rick Fochtman wrote: And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU My bank has a prominent sign at the entry to the drive-in lane Caution - Watch for pedestrians using ATM. And I've used it both ways. Gerhard Postpischil Bradford, VT -- 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: High order bit in 31/24 bit address
In a message dated 11/8/2007 11:59:26 A.M. Central Standard Time, [EMAIL PROTECTED] writes: And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? Doncha think it was same one that said standards and interchangeability were cheaper than maintaining separate pools of ATMS for drive-ups and walk-ups? ** See what's new at http://www.aol.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: ATMs (Was: High order bit in 31/24 bit address)
Most I dealt with in the mid-1980s were Tandem NonStop. Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, 08 November, 2007 10:25 At least most ATMs are still connected to mainframes. Aren't they? -- 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: High order bit in 31/24 bit address
At 11:58 -0600 on 11/08/2007, Rick Fochtman wrote about Re: High order bit in 31/24 bit address: And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? DU The one who decided that if they were in a car, they'd be in the back left seat behind the chauffeur or cab driver. -- 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: High order bit in 31/24 bit address
On Nov 8, 2007, at 12:10 PM, Binyamin Dissen wrote: On Thu, 8 Nov 2007 11:58:10 -0600 Rick Fochtman [EMAIL PROTECTED] wrote: :And what intellectual paralytic decided that drive-up ATM's had to have :Braille keys? DU Nothing wrong with that - if placed on the passenger side, not the driver side. Or if the passenger in the back seat would like to use it. Ed -- 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: High order bit in 31/24 bit address
And what intellectual paralytic decided that drive-up ATM's had to have Braille keys? The one that decided it was cheaper to make one kind of key-pad, than to make specialty ones. Just plugplay. - 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
High order bit in 31/24 bit address
From a Hasselblad brochure: The Hasselblad 6 x 6 cm ( 2 1/4 x 2 1/4) square format uses size 120 film and the square format eliminates the need to turn the camera sideways for landscape or portrait. It's very nearly Friday now. I travel very frequently from Sheffield Midland Station with a HUGE toolbox on wheels. Around 150kg. So I use the lifts. Around a year ago I was in a real hurry. When I bought my ticket, there was a blind woman at the same counter aiming for the same train. The station staff (knowing I would have to use the lift system) asked if I would guide her to the train. Sheffield station is almost all glass and 200% CCTV covered - no issue. So I took her to the lift and up we went. Small talk - I said that all of the controls had Braille superscripts. She reached out, slid a finger along one, and burst into paroxisms of laughter that made it hard to get her to the train. She didn't say why. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: High order bit in 31/24 bit address
In a message dated 11/7/2007 10:26:55 A.M. Central Standard Time, [EMAIL PROTECTED] writes: ASCII is worse this way - but there always will be problems with sorting, because sorting words and names has never had a complete definition that we all agree upon. What I remember, is back then there were several ASCII's 7bit, 8bit and maybe a 9-bit depending on the vendor. One of the guys was sitting in his dark office going hmmmholding up hollerith cards. Hmmm what? Double bit parity. So. Fewer data checkscan we work on the matrix algorithms now??? ** See what's new at http://www.aol.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: High order bit in 31/24 bit address
On 6 Nov 2007 22:43:39 -0800, [EMAIL PROTECTED] (Timothy Sipples) wrote: Finally, there is the fact that software engineers -- or at least human factors engineers -- apparently never reviewed ASCII. As we all know, EBCDIC puts the letters in the correct numerical order, collating uppercase and lowercase: AaBbCc ASCII doesn't. It's ABCDEF...abcdef Thus decades of dumb ASCII software -- and there's a lot of dumb software in the world -- has frustrated users everywhere. ASCII is worse this way - but there always will be problems with sorting, because sorting words and names has never had a complete definition that we all agree upon. (iTunes recently decided to sort numeric song titles at the end instead of at the beginning the way they were a couple of months ago). How many Roman based alphabets have tildes and accents - that are part of names that need to be sorted consistently? -- 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: High order bit in 31/24 bit address
On Wed, 7 Nov 2007 15:42:54 +0900, Timothy Sipples wrote: snip Finally, there is the fact that software engineers -- or at least human factors engineers -- apparently never reviewed ASCII. As we all know, EBCDIC puts the letters in the correct numerical order, collating uppercase and lowercase: AaBbCc ASCII doesn't. It's ABCDEF...abcdef Thus decades of dumb ASCII software -- and there's a lot of dumb software in the world -- has frustrated users everywhere. I was listening to a radio program this year, and the program's host was complaining bitterly about the fact his studio database filing system thinks Jackie is different than jackie. (They couldn't find a prop in their inventory for months.) Quite possibly as a byproduct of ASCII's strange idea of sorting, UNIX and UNIX-derived operating systems made perhaps the biggest design mistake of all time: case sensitivity in commands, file names, and directories. I'd argue strongly that computing systems should be case retentive but not case sensitive. Gr I am not sure I understand what are you talking about. Both uppercase and lowercase sequences are not contiguous in EBCDIC, and sorting text containing hex numbers in EBCDIC is not a big help. Result of sort command in a member with CAPS OFF (in linux, I can use sort -f or sort --ignore-case to get what you have in your example): EBCDIC Member: --- 01 a 02 b 03 c 04 d 05 e 06 f 07 g 08 A 09 B 10 C 11 D 12 E 13 F 14 G --- Unix System Services example: --- cat x.test a b c d f e A B D C E M F cat x.test|sort A B C D E F M a b c d e f cat x.test | sort -f A a B b C c D d E e F f M --- -- Zaromil -- 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: High order bit in 31/24 bit address
On Wed, 2007-11-07 at 15:42 +0900, Timothy Sipples wrote: Quite possibly as a byproduct of ASCII's strange idea of sorting, UNIX and UNIX-derived operating systems made perhaps the biggest design mistake of all time: case sensitivity in commands, file names, and directories. Ain't that the truth. Mind-boggling inane. All my searches are by default case insensitive - sometimes involving unnatural convolutions. Hungarian notation ... bah, humbug !!! Have a look at what the (Linux) kernel devs stipulate as good/acceptable coding style. And yes, IMHO the same (still) applies to HLASM. 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: High order bit in 31/24 bit address
On Tue, 6 Nov 2007 17:29:10 -0800, Edward Jaffe wrote: I would also add that -- with 21st century hindsight and certainly not a design mistake per se -- it sure would have been lucky if they had standardized on ASCII instead of EBCDIC! I don't know how lucky it would have been, with the goofy USASCII-8 that was documented in the 360 POO. For example, space was defined as x'40', numbers as x'50' to x'59', upper case letters began with x'A1' and lower case letters began with x'E1'. Remember that ASCII was a very new standard when the 360 was introduced. EBCDIC wasn't a standard, but there were a lot of old peripherals that used it. -- Tom Marchant -- 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: High order bit in 31/24 bit address
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples [ snip ] As we all know, EBCDIC puts the letters in the correct numerical order, collating uppercase and lowercase: AaBbCc ASCII doesn't. It's ABCDEF...abcdef Huh??? EBCDIC: A = x'C1', a = x'81', B = x'C2', b = x'82', etc. ASCII: A = x'41', a = x'61', B = x'42', b = x'62', etc. Please elaborate. -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
High order bit in 31/24 bit address
I'm tempted to agree about the stack - for the last quarter-century my calculator of choice (and it's right here now) has been a HP41CV. Back then, though, IBM perceived the lack of a stack as a marketing _adantage_. The competition (Burroughs, CDC, ICL) was all stack-based. The previous generations of machine in the UK market that IBM was trying to address - e.g., the KDF9 - were also stack machines. You can turn any feature or the lack of a feature into a benefit with enough marketing. Look at the inanity surrounding the very ordinary iPhone. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: High order bit in 31/24 bit address
Sorry, brain lock re: EBCDIC and ASCII sort orders. I must have been thinking of alphas then numerics versus numerics then alphas, since they differ in that respect. - - - - - 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: High order bit in 31/24 bit address
Mohammad, I suggest you read the description of the Load Address instruction in the z/Architecture POPS, The hardware ignores the HO bit in 24-bit and 31-bit addressing modes, and loads it as is in 64-bit mode. As for 32-bit mode (TSS) I don't have a POPS for that architecture but I suspect the HO bit is treated as any other. TSS did not use the sign bit as a signal, just as an address bit. HTH, Steve Samson Mohammad Khan wrote: Mr. Samson, Would you please clarify another point in this regard for me. Is it the hardware that ignores the high order bit or the OS that plays some trick before the address is sent out to hardware ? Thanks in advance Mohammad On Mon, 5 Nov 2007 16:47:23 -0800, Steve Samson [EMAIL PROTECTED] wrote: A 24-bit program using fullword (24-bit) addresses in a variable length parameter list will have the high-order bit on in the last such address. This bit is ignored in addressing modes less than 64-bit. It is significant in 64-bit mode, placing the address in the dead zone. -- 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: High order bit in 31/24 bit address
The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well. [EMAIL PROTECTED] (Steve Samson) writes: As for 32-bit mode (TSS) I don't have a POPS for that architecture but I suspect the HO bit is treated as any other. TSS did not use the sign bit as a signal, just as an address bit. lots of 360 documents at bitsavers: http://bitsavers.org/pdf/ibm/360/ including various functional characteristics http://bitsavers.org/pdf/ibm/360/funcChar/ specifically 360/67 functional characteristics a27-2719-0 http://bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf and ga27-2719-2 http://bitsavers.org/pdf/ibm/360/funcChar/GA27-2719-2_360-67_funcChar.pdf which has a lot of the gory details. as somewhat referenced here ... 360/67 was originally intended for use by tss/360 ... but for a whole variety of reasons, most of them ran cp67 (or in straight 360/65 mode with mvt w/o using virtual memory hardware) http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' curtesy of science center http://www.garlic.com/~lynn/subtopic.html#545tech in any case, psw format, pg. 15 bit meaning 0-3 spare (must be 0) 4 24-32 bit address mode 5 translation control 6 i/o mask (summary) 7 external mask (summary) 8-11protection key 12 ascii-8 mode 13 machine check mask 14 wait state 15 problem state 16-17 instruction length code 18-19 condition code 20-23 program mask 24-31 spare 32-63 instruction address ... there were a quite a few of the machines used internally. one of the projects were adding 370 virtual machine option to cp67 simulation ... this was having cp67 simulate the new instructions added to 370 (prior to announcement of 370 virtual memory). one of the places that deployed numerous of these machines was in the field/data processing/sales division for a project called HONE http://www.garlic.com/~lynn/subtopic.html#hone for hands-on network environment ... the idea was that in the wake of 23jun69 unbundling announcement http://www.garlic.com/~lynn/subtopic.html#unbundle that SEs in the branch office could get operating system hands-on experience with (370) systems running in cp67 (370) virtual machines. however, the science center had also ported apl\360 to cms for cms\apl and done a lot of work enhancing it to operate in large virtual memory environment (most apl\360 was limited to 16k workspaces, hardly adequate for many real world problems). With cms\apl, there were lots of new (internal) apl-based applications developed (some number of them of the genre that today would be done with spreadsheets) ... including configurators ... which basically filled out mainframe system orders for the branch office personal. As the use of these applications grew on HONE ... eventually they eclipsed the virtual guest hands-on training and would consume all available resources. at some point in the 70s, it was not even possible to submit a mainframe order that hadn't been run thru HONE configurator. science center had also done quite a bit of work in the area of sophisticated system performance modeling ... including laying the groundwork for what would become capacity planning. some of this i've commented about with regard to calibrating and validating http://www.garlic.com/~lynn/subtopic.html#benchmark the release of my resource manager http://www.garlic.com/~lynn/subtopic.html#fairshare in addition, a flavor of the performance modeling work was also deployed on HONE as the (apl based) performance predictor. Branch office people could submit customer configuration and workload details/characteristics and then ask what-if questions of the performance predictor ... as to what would happen if there was configuration and/or workload changes. another project was doing the cp67 changes to support a full 370 virtual memory implementation. this had a version cp67 running either in a 360/67 virtual machine (under cp67) or stand-alone real 360/67 simulating virtual machine with full 370 virtual memory operation. Then there was a custom version of cp67 that believed it ran on 370 virtual memory hardware (rather than on 360/67 hardware). This was in regular production use a year before the first engineering 370 machine with virtual memory support was operational (and long before announcement). past posts in the related thread: http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#65 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#67 CSA 'above the bar' misc. past posts mentioning performance predictor http://www.garlic.com/~lynn/2001i.html#46 Withdrawal Announcement 901-218 - No More 'small machines' http://www.garlic.com/~lynn/2002b.html#64 ... the
Re: High order bit in 31/24 bit address
On Tue, 6 Nov 2007 19:56:07 -, Phil Payne wrote: I had a word with Gene Amdahl about it once - he said the word 'algebraic' in the BXLE/BXH definition was the biggest mistake in the /360 design ... ...which makes one wonder: What was the second biggest mistake in the /360 design? -- Tom Schmidt Madison, WI -- 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
High order bit in 31/24 bit address
It wasn't in the PoP - it was in the back of the Functional Characteristics manual for the 360/67. There was a note that addresses in the upper half of a 32-bit address space might appear negative because of the sign bit causing address comparisons to be reversed. In 32-bit mode, LA loaded 32 bits. I had a word with Gene Amdahl about it once - he said the word 'algebraic' in the BXLE/BXH definition was the biggest mistake in the /360 design and the ultimate reason XA was only 31-bit. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: High order bit in 31/24 bit address
At 06:05 PM 11/6/2007, you wrote: On Tue, 6 Nov 2007 19:56:07 -, Phil Payne wrote: I had a word with Gene Amdahl about it once - he said the word 'algebraic' in the BXLE/BXH definition was the biggest mistake in the /360 design ... ...which makes one wonder: What was the second biggest mistake in the /360 design? -- Tom Schmidt Madison, WI No stack. I believe Amdahl said it himself. (I don't take it personally.) Michael Stack Product Developer NEON Enterprise Software, Inc. -- 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: High order bit in 31/24 bit address
Michael Stack wrote: At 06:05 PM 11/6/2007, you wrote: On Tue, 6 Nov 2007 19:56:07 -, Phil Payne wrote: I had a word with Gene Amdahl about it once - he said the word 'algebraic' in the BXLE/BXH definition was the biggest mistake in the /360 design ... ...which makes one wonder: What was the second biggest mistake in the /360 design? -- Tom Schmidt Madison, WI No stack. I believe Amdahl said it himself. (I don't take it personally.) Perhaps my narrow focus as a software developer has dimmed my wits. But, I consider the lack of a hardware stack to be _many_ orders of magnitude more important than having used the word 'algebraic' in the BXLE/BXH definition. ;-) I would also add that -- with 21st century hindsight and certainly not a design mistake per se -- it sure would have been lucky if they had standardized on ASCII instead of EBCDIC! -- 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
System 360 EBCDIC vs. ASCII (was Re: High order bit in 31/24 bit address)
On Tue, 6 Nov 2007 17:29:10 -0800, Edward Jaffe wrote: I would also add that -- with 21st century hindsight and certainly not a design mistake per se -- it sure would have been lucky if they had standardized on ASCII instead of EBCDIC! I think that the 360 lineage would have been less likely to have survived to the 21st century if IBM would have standardized on ASCII back then. The predictions of the mainframe's demise by the early to mid 1990s might have come true if the corporate/legacy data had not been held prisoner by EBCDIC. EBCDIC bought IBM time to rethink the role of the mainframe. -- Tom Schmidt Madison, WI (Think of all the processing cycles that were sold by all competing camps performing the code page transformations.) -- 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: System 360 EBCDIC vs. ASCII (was Re: High order bit in 31/24 bit address)
Anyone remember the IBM mainframe (7090 series) in 8 bit octal mode? OK, I'm dating myself. George Fogg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Tuesday, November 06, 2007 8:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: System 360 EBCDIC vs. ASCII (was Re: High order bit in 31/24 bit address) On Tue, 6 Nov 2007 17:29:10 -0800, Edward Jaffe wrote: I would also add that -- with 21st century hindsight and certainly not a design mistake per se -- it sure would have been lucky if they had standardized on ASCII instead of EBCDIC! I think that the 360 lineage would have been less likely to have survived to the 21st century if IBM would have standardized on ASCII back then. The predictions of the mainframe's demise by the early to mid 1990s might have come true if the corporate/legacy data had not been held prisoner by EBCDIC. EBCDIC bought IBM time to rethink the role of the mainframe. -- Tom Schmidt Madison, WI (Think of all the processing cycles that were sold by all competing camps performing the code page transformations.) -- 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: High order bit in 31/24 bit address
I would also add that -- with 21st century hindsight and certainly not a design mistake per se -- it sure would have been lucky if they had standardized on ASCII instead of EBCDIC! My understanding of history here is that the design did call for ASCII. (I'm bracing myself for a shot of garlic URLs now. :-)) By the early 1960s IBM liked ASCII a lot. But production realities intervened, and ASCII peripherals weren't available in time to make the initial shipments. IBM had to fall back on the EBCDIC devices, and thus the software evolved to support them. (It was also somewhat easier to get EBCDIC software out the door, and the software was chronically late as it was.) The processor certainly didn't require EBCDIC -- how could it if the designers thought the peripherals would be ASCII? -- and nowadays there are whole operating systems (e.g. Linux on z) which don't use EBCDIC. Had IBM waited to finish the peripherals, it's hard to say what would have happened, but I bet it wouldn't have been good. The 360s would have shipped much later, IBM might have struggled to keep afloat after betting the company on that product line, and the idea of a series of general purpose (scientific and business) computers with upward (and usually downward) compatibility, abstracting architecture from machine, might have been deemed overly ambitious at the time. The fact the 360 design philosophy did actually become reality was a huge breakthrough from a software and business applications point of view. It directly contributed to the rise of the middleware and packaged applications industries, for example. Push the 1965 schedule out to, say, 1967 and you start to wonder about timelines for software (like IMS and CICS) and whether the 360/67 (and thus VM) would have seen the light of day. And one also wonders whether it would have been so easy for the large EBCDIC installed base to move forward if 360 didn't support EBCDIC peripherals, delaying adoption of the new architecture even further or blocking it altogether. And if IBM went ASCII (zig), would other vendors have gone somewhere else anyway (zag), just for competitive reasons? Would the first Apple computers have used NIVIC (Non-IBM Vendor Interchange Code) instead? :-) About 15 years ago this looked like a problem, the ASCII v. EBCDIC issue. But history has moved on. ASCII is now declining in popularity pretty quickly, more quickly than EBCDIC. Unicode, particularly UTF-16, is where the world has moved. So modern operating systems like z/OS and modern middleware support Unicode, along with the older ASCII character sets and EBCDIC. What won the ASCII v. EBCDIC war? Unicode did. :-) And then there's the fact the A stands for American. In Japan, for example, standard ASCII is only enough to cover romanji, yet there are three other alphabets. So there are workaround oddities like shift-based character sets, and those are really quite nasty (IMHO). In other words, ASCII never really became a global standard even in its biggest days. Finally, there is the fact that software engineers -- or at least human factors engineers -- apparently never reviewed ASCII. As we all know, EBCDIC puts the letters in the correct numerical order, collating uppercase and lowercase: AaBbCc ASCII doesn't. It's ABCDEF...abcdef Thus decades of dumb ASCII software -- and there's a lot of dumb software in the world -- has frustrated users everywhere. I was listening to a radio program this year, and the program's host was complaining bitterly about the fact his studio database filing system thinks Jackie is different than jackie. (They couldn't find a prop in their inventory for months.) Quite possibly as a byproduct of ASCII's strange idea of sorting, UNIX and UNIX-derived operating systems made perhaps the biggest design mistake of all time: case sensitivity in commands, file names, and directories. I'd argue strongly that computing systems should be case retentive but not case sensitive. Gr OK, enough rambling. :-) - - - - - 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
