This would lower the overhead for a remote access from z/Linux but we want a remote access to z/Linux.
It would be nice if we could define the z/Linux DB2 tables to be EBCDIC but I didn't find anything about this option. Regards, Herve -----Original Message----- From: Robert J Brenneman [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 4:17 PM To: [EMAIL PROTECTED] Subject: RE : Thoughts on DB2...on Linux/390 You can define your DB2 tables on z/OS to be ASCII based instead of EBCDIC if you want to lower the overhead for remote access. You have shifted that overhead to local access of course, but this may not be a bad thing. Try and see. Well - at least with version 7 you can do this. I cannot say for earlier versions. Jay Brenneman Herve Bonvin <[EMAIL PROTECTED] To: [EMAIL PROTECTED] sscom.com> cc: Sent by: Linux on Subject: RE : Thoughts on DB2...on Linux/390 390 Port <[EMAIL PROTECTED] IST.EDU> 01/06/2004 09:56 AM Please respond to Linux on 390 Port We are also trying to save some money by moving data from z/OS DB2 to z/Linux DB2. I did some tests and in some cases (when a lot of data are selected), z/OS uses more cpu for a remote access than for an access on z/OS DB2. We think this is because of the EBCDIC/ASCII conversion. Is it possible to improve this situation by tuning something ? Regards, Herve -----Original Message----- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Monday, December 22, 2003 8:31 PM To: [EMAIL PROTECTED] Subject: Re: Thoughts on DB2...on Linux/390 > Do you have any feel for any performance impacts(if any) we'd > pay going to > a 'remote' database environment. Granted, same box, > hipersockets, etc, > but it is remote non-the-less. I think it would depend a lot on how your application uses the database and how good your programmers are. We've observed about a 1-3 sec increase in time to complete a transaction from CICS with that customer's specific workload, but haven't really done any exhaustive measurements (their comment: "for $310K in savings, we'll just buy another IFL if we don't like the performance!"). The time-critical tables in this customer's app are still on z/OS; they chose to distribute the less time-sensitive stuff which only get hit a few times during a transactionto the UDB instances as a gradual committment to the environment. New apps are going direct to the UDB instances as they come online, and we haven't observed any problems yet. > > b) working within the technical restrictions > > I'm more curious on this item, and I believe it is on database > sizes, > but I'm not educated enough yet on this. Mostly. There are small differences in some of the management tools, too, but nothing earth-shattering. The biggest arguments I hear at the moment seems to be 31-bit vs 64-bit support, but in the environment you describe, I suspect this may not be a huge problem. Unless you've got some tables with bazillions of rows, it's a matter of who caches what, which can be solved by systematic tuning. > > c) overcoming your IBM rep's reluctance to losing z/OS MIPS and > >corresponding revenue. > We would actually stay stable, vs reduce, most likely not > growing. Which, to a sales guy, is almost equivalent to reducing -- the "what does not grow, dies" phrase comes to mind. Some IBMers get really upset about this; the ones that used to be customers themselves are a bit more flexible. > > You should also price HA > > software for L/390 and network HA hardware as part of the > mix as well. > > In our cost case we did include the cost of Linux support, > training(for > Linux, DB2, and VM), but what HA items are you talking about? For production use, you'll want to have multiple clustered instances serving the data to allow you to do concurrent maintenance on one or more of the instances. Something like Veritas Cluster Manager or LVS is probably something you're going to want to make sure that the production server is always there. I missed the bit about it being the same machine, so disregard the HA hardware comment, other than to think about having multiple paths between z/OS and the Linuxen (ie more than 1 HS between the LPARs). > We have a > standby 9672-R26 that would be capable of running VM, and linux in a > pinch, > it is our D/R box. I'm thinking shared DASD, and if the server is not > available in its' normal home, we can boot on the 9672-R26. > We were not > thinking of continuous availablility, as it may be overkill > for us, but I > would be curious what you are thinking. I figured that production = continuous availability, but if you can live without that, it's lots cheaper. If you have both boxes nearby and you can cable both boxes to the same devices, seriously think about setting up the Cross-System Extensions (CSE) function of CP. That would allow switching systems to be as simple as logging the Linux id on on the other system (assuming the network is sufficiently virtualized), but it does take some preparation to make CSE work. Caveat emptor: CSE is not very well documented. Practice on 2nd level systems first is highly recommended. > The FUD from the DBA's is that they've 'heard' that DB2 on > linux on the > mainframe will be a dog. That's curious. I wonder where? Most of the buzz I hear from DBAs about UDB *anywhere* is positive. I've seen some claims that it's within 10% of the z/OS DB/2 performance -- not sure I believe them, but it's nice to hear. > Your idea's of selling them on their importance is a good > one, and I guess > would have > thought it would have been obvious. I'll have to work on that. It *is* obvious, but if you say it, that's really what they want to hear, so you get less static on other more important issues. It's stupid politics, but it's very common that the root of their objections isn't technical, but is basic fear of needing new skills or that their place in the grand scheme of things will somehow be diminished. A little ego massage goes a long way in this kind of situation, and will buy you all kinds of stuff down the road. -- db
