Moving from Solaris to Linux - points to consider

[Former Member]

Hi guys,

we are looking into a possibility to move SAP-systems from Solaris to Linux.

Has anyone done it? What we should keep in mind when doing it?

For example, I came up with

1. OS-dependant scripts for interfaces

2. Installation number change (note 1016348)

3. printers configuration for different OS (drivers?)

4. Software availiability limitations

.....

what else?

Any help will be appreciated!

Best regards, Elena

[markus_doehr2 · Accepted solution]

> we are looking into a possibility to move SAP-systems from Solaris to Linux.

> Has anyone done it? What we should keep in mind when doing it?

Check

http://service.sap.com/osdbmigration

You will need to have a certified migration consultant on-site who will do (or assist) in the migration - this is mandatory. Also check the FAQ on that page.

> For example, I came up with

> 1. OS-dependant scripts for interfaces

It depends what shell you use. Solaris' default shell is ksh, Linux uses bash, most things are compatible but the devil is in the details - as always. It's difficult to give an advise here because I don't know how you run your interfaces.

> 2. Installation number change (note 1016348)

Yes - but that shouldn't impact the usage of the software, you will have to change/maintain the system data though and you will need to apply a new license.

> 3. printers configuration for different OS (drivers?)

We run both (Solaris + Linux) and I never needed to install operating system drivers, we print everything as raw data to the printer. Don't know if you needed to install printer drivers on Solaris for some special printer types. You have various choices of which print system you use (BSD-lp, lpNG, CUPS) - take the one that suits you most.

> 4. Software availiability limitations

Again - it depends what you run. Linux supports systems down to 4.6c (I remember there was also 4.5B available long ago). Newer SAP software versions are equally available. Also check with your backup software vendor if he has interfaces (backint/whatever-else) for the backup software. Usually this isn't a big problem.

Be aware that you need to use the IBM JDK instead of the SUN JDK if you want to run Java applications (see note 861215).

We run Linux for our main ERP instance now for > 7 years and we wouldn't use something else

Markus

[Former Member · Accepted solution]

Hi Markus,

thanks a lot for the very detailed answer.

About installation number change - I thought about SECURESTORE changes.

Anything else you can think of? Tips & tricks?

Thanks in advance!

Best regards, Elena

[markus_doehr2 · Accepted solution]

The best way of finding out what works and what doesn´t it to create a test copy and evaluate what is running and in which areas you need to take action.

I would approach like this:

- upgrade the R3load, R3ldct, R3ta (+ R3ta_hints.txt) and dboraslib.so on the source system to the latest available patches (dboraslib.so needs a restart of the instance!)

- if you´re on ERP (means, SAP_BW as component included - see system - status) execute SMIGR_CREATE _DDL before the actual export (see note 885441 - Common Migration Errors)

- export the database using sapinst, do not use the "stop for migration" button - for a test run the system can be kept running

- use migration monitor to drive the actual export. I would give number of R3load processes = number of processes (to not put a too high load on the system if it´s your production). I would also check the button to export the biggest 50 or 100 tables seperately (depending on the size of your source system)

- prepare the target (Linux) system with all OS patches and configuration according to note 171356 - SAP software on Linux: Essential information

- start sapinst (Custom mode!), proceed until you are requested to install Oracle, do so and install the latest patchset 10.2.0.2 and all available interim patches (may be 40+ - check note 871096 - Oracle Database 10g: Patch sets/patches for 10.2.0)

- before continuing with sapinst upgrade the kernel of the target system and use the same R3load and dboraslib.so as on the source system (or newer ones if available)

- also use migration monitor to import the database. If you have installed the latest Oracle patches (which is HIGHLY advised), you can enter "-loadprocedure fast" as .TSK load option.

- during the import run, rename the startsap script (to e. g. startsap.old)

- when the import finishes, sapinst stops with error due to the missing startsap script

- step to the profile directory and set "rdisp/wp_no_btc to 0" so that on system start no batch processes will run automatically and thus "confusing" your production landscape

- rename startsap.old to startsap

- repeat the system start with sapinst

- after it finished logon to the system (may dump with START_CALL_SICK due to missing batch processes) and execute program BTCTRNS1. This will suspend all jobs without deleting them.

- import the profiles using RZ10 and add batch processes

- adapt parameters (roughly) (languages, login client etc.)

- restart the instance

- run SGEN for all objects

- restart again

- invalidate all RFCs if they point to other production systems

After that you have a copy of your source system on the target platform. All jobs are suspended (means, they are planned but they won´t actually run) and you can check step-by-step all interfaces and things you run externally relying on operating system shells and programs.

Linux also has a ksh (pdksh) - if your shells scripts are not working using bash you can install that one and check if that will help getting your scripts to run without adaptions.

If you exchange binary files, be aware of the fact, that Solaris (on SPARC) is a big endian platform whereas Linux is little endian. This may also come into place if your system is Unicode and you have ABAP programs doing "open dataset...." statements.

Another (maybe good) option for the migration may be to not use Linux but using Solaris x64 (which will run on the same hardware as Linux) - just as a thought

Markus

[Former Member · Accepted solution]

Thanks a lot, Markus,

could you please provide details about "... This may also come into place if your system is Unicode and you have ABAP programs doing "open dataset...." statements. "

Where can I read about this? In my opinion, it can be a big issue.

Thanks in advance,

Best regards, Elena

[markus_doehr2 · Accepted solution]

> could you please provide details about "... This may also come into place if your system is Unicode and you have ABAP programs doing "open dataset...." statements. "

>

> Where can I read about this? In my opinion, it can be a big issue.

- start SE38

- press on the "i" button

- enter "open dataset"

- doubleclick "open dataset"

- click on "mode" in syntax

The reason for that is, if you use the normal "open dataset...codepage default" it will use the application servers codepage to store the file. In Solaris/SPARC/Unicode case this is 4102. On Linux this would be 4103. If a target system doesn't "know" that it is dealing with a little endian Unicode file, it may not be able to read the file (or interpret it wrong).

If you use plain textfiles and using legacy mode this isn't an issue.

Markus

[Former Member · Accepted solution]

Didn't understand what you've meant

Thanks a lot again, If something else will come to mind - please share

Best regards, Elena

[markus_doehr2 · Accepted solution]

> Didn't understand what you've meant

did not understand what?

Markus

[Former Member · Accepted solution]

I meant previously at first place I didn't understand what you meant "... This may also come into place if your system is Unicode and you have ABAP programs doing "open dataset...." statements. "

After the second explanation it became clear

Thanks!

[markus_doehr2 · Accepted solution]

> I meant previously at first place I didn't understand what you meant "... This may also come into place if your system is Unicode and you have ABAP programs doing "open dataset...." statements. "

> After the second explanation it became clear

Oh - ok )

Markus