Sunday, September 23, 2012

Friday, June 02, 2006

News on iSeries and SAP New!!!!!

SAP on the iSeries: No Longer the "Best Kept Secret"?

Published: May 30, 2006

by Alex Woodie

If one were to draw up a list of the iSeries platform's most successful ERP systems, chances are good that list would not include R/3 or SAP's While the world's biggest business software maker has supported IBM's bullet-proof server platform since 1996, and has racked up more than 1,100 satisfied iSeries customers, news of the success of SAP on the iSeries never seemed to get farther than Armonk or Walldorf. Now, the pair say they're working to change that.

Michael Koerner, the SAP global business development manager for IBM systems, acknowledged that few people were aware of SAP's prowess on the OS/400 platform, even though SAP on the iSeries constituted a "very large, loyal install base."

"iSeries for SAP was one of the best kept secrets before," Koerner says. "I think we had some deficiency communicating all the good things we have for our customers. That's why we sat together with SAP and had some very good discussions on how to get SAP applications on iSeries back on track."

Those discussions resulted in some joint road shows and customer events held all around the world, Koerner says. The momentum has also carried over into an informal SAP on the iSeries user group that meets every year before the annual SAP TechEd event. The group is planning to meet before TechEd in Las Vegas this September, although those plans haven not yet been finalized.

The discussions also resulted in the delivery of a special i5 550 server pre-loaded and pre-configured for SAP's software. Koerner says the SAP Solution Edition, which is available in two-way and four-way configurations, has been a success. "It was probably one of the most successful programs that I initiated since I've been in the position. We overachieved our business case by 47 percent," he says.

The SAP Solution Edition also broke some misconceptions users hold about the iSeries and SAP. "The iSeries has a reputation as being expensive, as SAP does, and being difficult to set up," Koerner says. "When customers saw the solution edition, they got interested. It opened up the door to the customer." In actuality, the Solution Edition's role was as teaser, as many of these customers bypassed the Solution Edition and went on to buy bigger eight-, 12-, and 16-way systems.

SAP also brought OS/400 support up to parity with the other operating systems. "It used to take four or five weeks, or up to two months, before the new release available on Sys i, but we have fixed this," Koerner says. "Now the GA of a new release means the GA on the iSeries as well. SAP and IBM are putting a lot of effort for doing the porting activity in parallel." This means that the new mySAP ERP 2005, which SAP unveiled two weeks ago, is available for the iSeries now.

IBM has also worked on SAP for the iSeries marketing and benchmarking figures. Last fall, IBM put together a slick four-page brochure touting the System i5 as the "easy way to SAP." Earlier in the year, an i5 claimed the top spot on SAP's BW benchmark.

IBM also commissioned a study of 61 iSeries SAP users to see why they picked the OS/400 server over Hewlett-Packard and Sun Microsystems Unix machines, and what they liked about the iSeries. The report, titled "IBM iSeries Initiatives for SAP Deployment," was conducted by Los Angeles-based International Technology Group, and released in December.

ITG's study, which is not available online, found that, over the course of three years, the IT costs for running SAP on the iSeries averaged 45.5 percent less than running it on Sun Fire machines, and 42 percent less than running it on HP's Itanium-based Integrity machines. In almost each case, the hardware, maintenance, software, and personnel costs were lower for SAP users running on the iSeries than for SAP users running on other platforms. When the effect of planned an unplanned downtime, or what ITG called "business costs," were factored in, the iSeries users saved even more.

In regard to the aspects of the iSeries they liked most, the responses from these companies--which were mostly manufacturers with a smattering of retail, wholesale, and healthcare operations, ranging in annual revenue from less than $500 million to more $12 billion --pointed toward the iSeries reliability, its low management overhead, its integrated backup and recovery facilities, its dynamic LPAR capabilities, and the capability of the companies to leverage their existing iSeries skills. In short, they mirrored the attitudes of the iSeries shops as a whole.

ITG concluded the strengths of the iSeries are a very good match for SAP applications. "The key strengths of the iSeries all contribute to reduced complexity and risk. They thus map directly to the core challenges facing organizations seeking to realize the value of latest-generation SAP solutions," the group wrote in its report.

Koerner says the success companies like these are having is starting to break the misconception than SAP doesn't run--or doesn't run well--on the iSeries. From the beginning of 2005, the installed base of SAP on the iSeries has grown by about 100 to 1,100, and the total number of sites where SAP is running on the iSeries has increased from 2000 in May 2005 to more than 2,500 today.

While SAP on the iSeries numbers are trending up, they still trail the pSeries installs by a fairly significant margin, according to Koerner, who's also in charge of the SAP relationship as it pertains to the AIX server. And while Unix used to be the favored platform for all SAP implementations, Unix installs now pale in comparison to SAP's business on Windows, which make up by far the majority of SAP implementations. HP, for example, recently boasted of more than 50,000 SAP installations, most of which it obtained in its acquisition of Compaq's Windows-based server business.

There is also the fact that practically all SAP implementations are going to require at least one Microsoft Windows Server running SQL Server, as some modules only run on Windows and SQL Server. "There are some SAP modules that are not supported on OS/400 native. But that's the same for Unix based," Koerner says. "Some of the SAP modules required the SQL database running on Windows Intel only. It's no problem for the iSeries customer because we support the Windows application by either using the IXS or attaching the System x server to a system i box."

Despite these hurdles, the prognosis of SAP on the iSeries is good, Koerner says. "Yes, it is more difficult. But I think SAP has done a lot of work over the last one-and-a-half to two years to improve their reputation," he says. Hopefully, the work will dispel the reputation of SAP on the iSeries as the best kept secret in business software.

Monday, November 15, 2004

Journey to Coolness... Part 2: Birth Of A Solution

In Part 1 of this jovial journey the method of ordering all the needed supplies was found. After two successful installs (one on our test box and the last on our dev system) I'm happy to report the birth of a solution.

Let's talk about the install process for a bit, shall we? In one word - GREEAATT! (Think Tony the Tiger). Even with the CRM references it was an easy-to-follow guide. The installation gui was fairly user friendly and walked you thru the whole process. It didn't "hand hold" by any means but it didn't give me any "blank stares" either =) and the interface with the iSeries was flawless. Map a drive, copy your cds, and your are ready to start - green screens need not apply.

We did have minor confusion on whether to install a database instance or a central instance first. The central instance was our goal so we tried it first. We had hopes that a db instance would "come standard" with a central instance install. No such luck. With no data library, the install bombed on the system startup phase. We did recover by installing the db instance next. Very pleasing and a bit surprising to have the db instance install go perfectly after the minor failure of the central instance install. The upside is everything worked even after the drawkcab install.

New babies are always fun. They are so full of wonder with their new transactions and screens. Every compile is a joy... Ok, I'm over doing it a bit but what do you expect from a new parent? We did notice that Junior was a bit slow (an S30 test box doesn't make for an agile youngster) but we loved him anyway. After hiring a tutor (the one and only SAP Tutor!), we got him talking with our Enterprise test systems. He played well but we soon found we needed a better environment for our budding Solution Manager. It was time for a move.

Fire up the instgui, point it toward our development box and... sit down, lean back, shut up and ENJOY the ride!

As experienced parents, this birth was easier than the first. We put on the database instance first (no errors) and then installed the central instance (again no errors). SID, the second, has a nice new place to grow up and will get opportunities that SID, the first, never got.


In the last installment of the Journey to Coolness we'll find our what adventures await our young Solution Manager and see if the happiness and joy continue all the way until the end.

Tuesday, October 12, 2004

Journey to Coolness... Part 1: Beginning

High off my exposure to the Solution Manager at TechEd I, of course, want to have it for my very own... cuddle and hold and take care of... hmm, nevermind :)

I begin this morning by digging into the details of installation. First, I must choose a flavor. We have a "complimentary" xSeries server so perhaps we'll do a Windows/SAPDB or SQL install. Perhaps not, but I'll snag the install guides anyway.
< 15 minutes later and a couple "oh boy, SSM is slow" comments >
Downloads successful.
Hey, there's an iSeries guide too.
< 5 minutes later and a "Hey, I think the speed is improving" >
Download successful.
Might as well start with something familar so I crack open the iSeries guide.

CRM... interesting.

Downloadable?... nope.

Software catalog... negative.

Ah a note!

Talk about a dead-on hit, 628901 (You want to order the SAP Solution Manager 3.1). Call me silly or uninformed but shouldn't this note be mentioned in said guide? It's a small annoyance but it would have been nice to have the order form attached in a document format instead of having to fax the entire note.

Until I actually get an install kit in hand, I'll be curling up with the install guide. More to come in Part 2.

Sunday, October 10, 2004

SAP's Shadow

One of my last lectures at TechEd was efficient upgrade management. The lecture was a fairly straight forward guide that covered many of the points we had already came across thru test upgrading. The course also went over the Shadow Instance and why it was introduced. The shadow instance has always puzzled me but this presentation "shed some light on it", so to speak =)

The main reason for the shadow instance was to reduce down time, plain and simple. When going to 4.7 and making the downtime-minimized selection you can nearly save 50% of the downtime over the resource-minimized strategy. For those shops that live and die by production uptime this was a huge boon. My puzzlement came from going with the resource-minimized selection.

For us, we have to do a hop to 4.6C along with a skip, namely a ASCII conversion, before we can jump to 4.7. Luckily we have a week to work with (July 4th or Christmas), so downtime minimization doesn't buy us anything. Do we still have to use the shadow instance?

WHAT... You may ask yourself, why WOULDN'T we want to use such a great and marvelous invention!

Allow me to explain.

We've had problems in the past with the shadow instance starting. The first 4.7 upgrade we tried it took us a week of working with support to finally get it running. The second time wasn't as bad but it still gave us problems starting. Our solution, in both cases, was to patch nearly everything in the 6.20 kernel. Ok, NOT everything but still quite a bit and at certain times during the upgrade.

After this lecture, I now know the reason behind the shadow instance regardless of the strategy chosen. Within the 6.20 kernel, there are tools needed for the upgrade that just aren't in a 4.6C and lower system. The shadow instance, which is running on the 6.20 kernel, allows the upgrade to use these needed tools. Whether we need to reduced downtime or not, the shadow instance is an intergal part of SAP's 4.7 upgrade procedure.

Thursday, October 07, 2004

My Two Best Lectures at TechEd So Far...

First I have to say that San Diego is GORGEOUS! Perfect weather and amazing landscapes all in a big city that doesn't feel TOO big. Now on the geeks stuff...

SAP Solution Manager: New Features

Drop the Notes Transport Database and walk away slowly. SM 3.2 gives you all of that and more. Very slick interrogation of the whole transport management/development process and the actually propagation of the transports. After my other hands on class experience with SM and upgrade/implementation project management, I'm looking forward to getting SM going.

Higher Performance with Archiving

A good discussion of how table growth and size can affect performance and why. Examples of chronological data (sales orders and invoices) vs non chronological data (material master) were given. In chronological data, storage size really won't impact performance since newer items are always searched first. The material master doesn't have the a dating luxury so the larger it is the worse performance is when the transaction relies on tables like MSEG.

The point is that focusing your archiving efforts on large tables will not automatically give you a performance boost. You are definitely getting disk space with those tables but to gain performance you'll have to dig into your tables without dating info and find a way to determine what should be swept away. More difficult since there is really no retention period time frame to go by.

Another great point of the class focused on indexes. As your database grows so do your indexes. In many cases, the indexes tied to a large table can surpass the actually data size of the table. Without archiving you have a huge problem of indexes multiplying your actually data growth.

One last final point was access and process time of retrieving archived data. Your intuition probably makes you think that archived data retrieval is always slower than online data lookup. This is definitely not the case. If your archive still resides on your file system then getting to it is much faster for the end user than if it was still in your database. Since it's archived, you'll have a reference of exactly where that record is in the archive. The data online still has to be retrieved by the normal multiple table scans. So even if you leave the archive data on your file system and don't reap the rewards of reduced disk usage you still win with increased performance and a smaller R/3 database. Performance gains are seen from less dialog steps being spent gathering those requests for archived data. A smaller R/3 database wins from reduced daily backup times.

And the winner is----

The cool archiving class. I'm sure you could have guessed by the write size disparity, hmmm. =)

Friday, October 01, 2004

5-1-2 Maintenance and Extended Maintenance?

What does the one year at 2% and the two years at 4% get you? If you don't apply support packs or LCPs, do you need to pay to extend your maintenance or opt to go right into Customer Specific Support? Do you need it? Will you be stopped from downloading kernel patches? I can understand, if you run into a problem and SAP reccommends the latest support package. But, if you are in customer specific support, are they not going to allow you to get it?

Thursday, September 30, 2004

Massive DASD

With the upcoming ASCII conversion, one has to start thinking about how to handle the growth of the database. Firstly, there must be enough disk space to accommodate the growth. Next, backup windows don't magically get larger just because the database does. Lastly, there also needs to be disks aplenty to handle the copies of the database. This last consideration is the juggernaut.

What does one do?

There are 3rd party software solutions for copies. These products either make copies smaller or create smaller copies. Both work well enough depending on a companies needs. However, cost may be a stopping point.

How can one justify a software purchase to offset disk costs when buying the disk is cheaper than the software itself?

As technology advances and gazillion byte hard drives come to market will it really matter if a database is several gazillion bytes? But what about backups!?!?! There's been no lag of tape drive technology. It's fast, large and always getting faster.

The kicker comes in when you get to math. More disk space can be acquired each year for less and less dollars. The maintenance on the software remains constant (and can even go up). Looking at some bids one can calculate that for maintenance of the 3rd party solution 7 years worth of database growth can be purchased in hard drive space. Have fun taking that to management =)

R/3 Kernel and IBM Infoapar 520

We just downloaded the latest 3.1I_EXT 64bit kernel #748 from the ever so fast SAP Service Marketplace - that's a whole other topic on its own, but we'll get to that later. We extracted the infoapar.520 stream file from this kernel and noted the apar was last updated 8/13/2004. But, the apar on the IBM site was updated on 9/27/2004 and it has a new cumulative package(4244), New hipers, new Java pack, new DBfix Pack. What I'm in the dark about is since I donwloaded the LATEST! Kernel from SAP and it includes an old infoapar.520 which the CHKR3PTF program uses when you apply the kernel - when are all these new PTFs tested with the SAP Kernel. Should't the latest kernel have the latest apar?