Hallo zusammen
Ich soll eine Migration von UNIX nach windows 2000 durchführen
Was ist alles zu beachten ??
Frank
Migration UNIX -> Windows 2000 / Schnittstellen
6 posts
• Page 1 of 1
Migration UNIX -> Windows 2000 / Schnittstellen
by Ralph1236 » Thu Jul 24, 2003 10:42 am
- Ralph1236
- .
- Posts: 9
- Joined: Thu Jul 24, 2003 10:42 am
by Ralph1236 » Fri Jul 25, 2003 8:11 am
Wir haben den Support von SAP.
Die Frage ist nur welche Eigenentwicklungen zB. oder SAP
File downloads auf Unix,
Betriebssystemaufrufe,
RFC-Destionations (SM59),
SAP Connect Schnittstellen.
Was ist noch zu beachten.
Die Frage ist nur welche Eigenentwicklungen zB. oder SAP
File downloads auf Unix,
Betriebssystemaufrufe,
RFC-Destionations (SM59),
SAP Connect Schnittstellen.
Was ist noch zu beachten.
- Ralph1236
- .
- Posts: 9
- Joined: Thu Jul 24, 2003 10:42 am
by Jonna699 » Fri Jul 25, 2003 10:49 am
Servus Frank,
das ist leider viel zu kompliziert um mal eben hier im Forum abzuhandeln. Grundsätzlich ist es so, dass Du von SAP quasi 'an die Hand' genommen wirst. Die sagen Dir genau, wo es Schwierigkeiten geben kann und ob ggf. Anpassungen notwendig sind. Das hängt eben auch sehr stark und indivduell vom System ab. Wenn Ihr z.B. ziemlich viele eigene Kundenentwicklungen habt, die bspw. sehr spezifisch auf ein Unix-Umfeld ausgelegt sind, dann müssen diese Dinge i.d.R. schon angepasst werden.
Was die Dinge, die Du oben angesprochen hast anbelangt, so wird das i.d.R. von den Beratern mit denen Ihr zusammenarbeitet durchgeführt.
Auf dem Service-Marktplatz von SAP unter dem Alias /instguides müßtest Du noch detailliertere Informationen finden, in Form von Migrationsguides.
http://service.sap.com
C3PO
das ist leider viel zu kompliziert um mal eben hier im Forum abzuhandeln. Grundsätzlich ist es so, dass Du von SAP quasi 'an die Hand' genommen wirst. Die sagen Dir genau, wo es Schwierigkeiten geben kann und ob ggf. Anpassungen notwendig sind. Das hängt eben auch sehr stark und indivduell vom System ab. Wenn Ihr z.B. ziemlich viele eigene Kundenentwicklungen habt, die bspw. sehr spezifisch auf ein Unix-Umfeld ausgelegt sind, dann müssen diese Dinge i.d.R. schon angepasst werden.
Was die Dinge, die Du oben angesprochen hast anbelangt, so wird das i.d.R. von den Beratern mit denen Ihr zusammenarbeitet durchgeführt.
Auf dem Service-Marktplatz von SAP unter dem Alias /instguides müßtest Du noch detailliertere Informationen finden, in Form von Migrationsguides.
http://service.sap.com
C3PO
- Jonna699
- .
- Posts: 3
- Joined: Sat Apr 26, 2003 2:21 pm
by Jessy5246 » Sat Aug 09, 2003 4:38 pm
Dear all:
I don't see what the problem is. SAP has platform independence built in and allows for the OS in logical file name, external commands and other areas where the OS matters. In most other respects the OS does not matter, therefore should not make a difference.
That is why a good programming style is important. E.g., I noticed that a UNIX and an NT installation stored integers differently internally, but it should not affect you if the coding is right. And in UNIX you can do OPEN DATASET on a directory, in NT you cannot (may vary with system).
The most common mistakes are excessive CALL SYSTEM commands with very specific UNIX scripts, hardcoded file names or paths bypassing the logical file names, using an OPEN DATASET with FILTER. Whenever you code for a specific platform, you introduce problems with the next upgrade. The big strength of SAP is, that you can switch DBs and OSs with little effort and some additional configuration, IF you follow the guidelines.
Of course, every installation has cases where the consultant or employee either took a short-cut or did not know better. Some companies even make you put a hard file name as a parameter, so the variant can contain it. It is a little bit more work to do it right, and unfortunately it pays off after the contractors left. Some folks appear to enjoy job security by ongoing maintenance of what they wrote in the first place.
I wish you luck and success with the migration. Focus on the Y* and Z* programs, they are most likely to fail during such an exercise.
Regards,
Wolfgang
I don't see what the problem is. SAP has platform independence built in and allows for the OS in logical file name, external commands and other areas where the OS matters. In most other respects the OS does not matter, therefore should not make a difference.
That is why a good programming style is important. E.g., I noticed that a UNIX and an NT installation stored integers differently internally, but it should not affect you if the coding is right. And in UNIX you can do OPEN DATASET on a directory, in NT you cannot (may vary with system).
The most common mistakes are excessive CALL SYSTEM commands with very specific UNIX scripts, hardcoded file names or paths bypassing the logical file names, using an OPEN DATASET with FILTER. Whenever you code for a specific platform, you introduce problems with the next upgrade. The big strength of SAP is, that you can switch DBs and OSs with little effort and some additional configuration, IF you follow the guidelines.
Of course, every installation has cases where the consultant or employee either took a short-cut or did not know better. Some companies even make you put a hard file name as a parameter, so the variant can contain it. It is a little bit more work to do it right, and unfortunately it pays off after the contractors left. Some folks appear to enjoy job security by ongoing maintenance of what they wrote in the first place.
I wish you luck and success with the migration. Focus on the Y* and Z* programs, they are most likely to fail during such an exercise.
Regards,
Wolfgang
- Jessy5246
- ..
- Posts: 23
- Joined: Tue Dec 03, 2002 8:20 pm
6 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 12 guests
-
- Latest Topics