ASCII-EBCDIC convertion between z/Os and Linux

Question

Hi experts, we are migrating our landscape to z/Os (DB+ASCS) and Linux (PAS). We have our GLOBALHOST on z/Os but we are experimenting some problems when we try to install our application servers because the conversion between platforms.
In the planning guide we can see that there is a way to mount NFS file systems exported from z/Os, that make this convertion in an automatic way, but the commands mentioned on the guide are for UNIX and not for Linux.
Does any of you have this kind of installtion that could help us to set this parameters ok?
Or does any of you face this problems before?
Regards
gustavo

Answer 1

First, yes, we have z/OS systems programmers and DBAs with specific knowledge of DB2 z/OS. One of the reasons we initially went with the Z platform when we implemented SAP was that our legacy systems ran there for many years and our company had a lot of Z knowledge and experience. zSeries was one of our "core competencies".
I also need to give you a little more information about our Z setup. We actually had 2 z9 CECs in a sysplex, one in our primary data center and another close by in our DR site and connected by fiber. This allowed us to run SAP as HA on the Z platform. For highly used systems like production ERP we actually ran our DB2 instances active/active. This is one of the few advantages of the Z platform unavailable on other platforms (except Oracle RAC, which is also expensive but can at least be implemented on commodity hardware). Another advantage is that the SAP support personnel for DB2 z/OS are extremely knowledgeable and respond to issues very quickly.
We also chose the Z platform because of the touted "near-continuous availability" which sounded very good. Let me assure you, however, that although SAP has been making great strides with things like the enhancement pack installer, at present you will never have zero downtime running SAP on any platform. Specifically you will still have planned downtime for SAP kernel updates and support packs or enhancement packs, period. The "near-continuous availability" in this context refers to zero unplanned downtime. In my experience this is not the case either. We had several instances of unplanned downtime, the most recent had to do with issues when the CECs got to 100% CPU utilization for a brief period of time and could not free some asinine small memory area that caused the entire sysplex to pause all LPARs until it was dealt with(yes, this could be dealt with using system automation but our Z folks would prefer to deal with these manually since each situation can be different). We worked with IBM on a PMR for several months, but our eventual "workaround" was much better. We stopped running our DB2 instances as active/active and never had the problem again. We chose this "workaround" because we knew we were abandoning the platform and any of the test fixes from IBM required a rolling update of z/OS in all LPARs (10 total at the time), which is a major hassle, especially when you do it several times applying several different fixes until the problem is finally solved.
We also experienced some issues with DB2 z/OS itself. In one case, some data in a table in production got corrupted (yikes!!) SAP support helped us correct the data based on our QA system and IBM delivered a PTF (or maybe it was a ++APAR) to correct the problem. We also had several instances of strange poor performance in ERP or BI that were solved with a PTF or by using some special RUNSTATS output by some IBM DB2 tool our DBAs ran when we gave them the "bad" query. Every time we updated DB2 z/OS with an RSU felt like a craps shoot. Sometimes there were no issues revealed during testing, other times major issues were uncovered. This made us very hesitant when it came to patching DB2 and also made us stay well behind currently available maintenance so we could let other organizations identify problems.
Back to the topic of downtime related to DB2 z/OS itself, we know another company which runs SAP on Z that takes several hours of downtime each week (early Sunday morning I think) to REORG some large BLOB tables(if you're not in the monthly conference call for SAP on DB2 z/OS organizations, I suggest you join in). The need for RUNSTATS and REORGs to be dealt with explicitly (typically once a day for RUNSTATs and once a week for REORGs, at least for us) is a major negative of the platform, in my opinion. It is amazing what "proper" RUNSTATS can do to a previously poor performing query(hours reduced to seconds!). Also, due to the way REORGs are handled in DB2 z/OS, you'll need a lot of extra disk space for the image copies which get created. In our experience you need enough temp disk to hold the shadow copy of the largest table being REORGd and the image copies of the largest tables that are REORGd in the same time period. I recall that the image copies can be migrated to tape or virtual tape to free the image copy space back up using a periodic job, but it was a huge amount of trial and error to properly size this temp disk space, especially when the tables requiring a REORG are not the same week-to-week. We heard that with DB2 z/OS v10 that RUNSTATS and REORGs will be dealt with automatically by DB2, but I do not know if it has even been certified for SAP yet(based on recent posts in this forum it would appear not). Even when it is, I would not recommend going to it immediately(we made this mistake when DB2 z/OS v9 was certified and suffered for months getting bugs with SAP and DB2 interoperability fixed). Also, due to the way that REORGs work on BLOB tables, there will be a period of table unavailability. The caused us some issues/headaches. There are some extra REORG parameters you can set, but these issues are still always a possibility and I think that is why the company mentioned previously just took the weekly downtime to finish the REORGs on their large BLOB tables. They are very smart folks that are very experienced with zSeries and they engaged IBM experts for assistance to try and perform the REORGs online and yet they still take the downtime to perform the BLOB REORGs offline. In contrast, these periodic database tasks do not require our Basis team to do anything with SQLServer and do not cause our end-users grief when a table is unavailable.
Our reasons for moving platforms (which, let me assure you was a major undertaking and was considered long and hard) were based on 3 things:
1. Complexity
2. Performance
3. Cost
When I speak of complexity, let me give you some data... There was a time when ~50% of all of the OSS messages the Basis team opened with SAP were in the BC-DB-DB2 category. In contrast, I think we've opened 1 or 2 OSS messages in the BC-DB-MSS category ever. Many of the OSS messages for DB2 z/OS resulted in a fix from either SAP or from IBM. We've had seveal instances of applying a PTF, ++APAR, or RSU to z/OS and/or DB2 which fixed serious "unable to perform a job function" problems with SAP. We've yet to have to apply a single update to Windows or SQLServer to fix an issue with SAP.
To summarize... Comparing our previous and current SAP platforms, the performance was slower, the cost higher, and the complexity much higher. I have no doubt (especially with the newer Z10 and zEnterprise 196) that we could certainly have built a zSeries SAP solution which performed on par with what we have now, but.... I could not even fathom a guess as to the cost. I suspect this is why you don't see any data  for the standard SAP SD benchmark on zSeries.
I suspect you're already committed to the platform since deploying a Z machine, even in a lab/sandbox environment isn't as easy as going down to your local computer dealer and buying a $500 test server to install on, but... If you wanted to run SAP on DB2 I would suggest looking at DB2 LUW on either X86_64 Linux or on IBM's pSeries platform.
Brian