[53847] in SAPr3-news
Re: SAP BASIS: Perspektiven
daemon@ATHENA.MIT.EDU (Manfred Albat)
Thu Mar 17 13:58:45 2005
To: sapr3-news@mit.edu
Date: Thu, 17 Mar 2005 19:58:28 +0100
From: Manfred Albat <alispost@nurfuerspam.de>
Message-ID: <39u2apF6044j7U1@individual.net>
Reply-To: m.albat@gmx.de
Moin zusammen, hallo Rainer,
am 15.03.2005 20:11:27
schreibt Rainer Huebenthal <usenet200412.20.finji@spamgourmet.com>:
> > Schnittstellen wohin? In andere SAP-Systeme oder in nonSAP-Systeme?
> > Was hinter Schnittstellen in einer nonSAP-Umgebung liegt, kann
> > nicht das Problem der SAP sein. Das ist ja genau der Punkt!
>
> Doch das ist der Punkt. Es sei denn du unterscheidest
> Signifikant zwischen "das kann nicht das Problem der SAP" sein
> oder "das kann nicht das Problem von SAP sein",
>
> Oder anders: natuerlich koennen eigentwntwicklungen in SAP ein
> Problem sein, das juckt aber die SAP herzlich wenig.
?? Verstehe jetzt nicht, was Du damit sagen willst.
Also, ich verstehe unter einer Schnittstelle den Übergang zu einem
anderen System. Aus der Sicht des SAP-Systems kann das ein
beliebiges sein, etwas individuell Entwickeltes, eine Standardsoftware
von einem Mitbewerber, was auch immer. U. U. auch ein anderes
SAP-System.
Nur: die Probleme, die ich mir mit so einer Anbindung an ein Fremd-
System schaffe, kann ich nur selber abschätzen. Und viel hängt auch
davon ab, wie sorgfältig die Modifikationsrichtlinien umgesetzt wurden.
Deshalb kann bzw. konnte es nicht Problem der SAP sein, was im
remoten System für Problematiken bedient werden müssen. Das
gilt schließlich für *jeden* Anbieter! Außer: das remote System ist
ebenfalls ein SAP-System. Aber dafür sind eigenentwickelte "Schnittstellen"
im klassischen Sinn auch nur selten notwendig. Sie entstehen - wenn
überhaupt - oft nur aus mangelndem Know-How.
Und dann gibt es übrigens geniale Sub-Systeme, die ihren Ursprung
im EDI-Umfeld haben. Dann sieht die "Schnittstelle" so aus:
- Nachrichtensteuerung einmal customizen
- IDoc geht via RFC oder tRFC (SAP-ALE) ans Subsystem
- Subsystem erkennt bedienerlos was zu tun ist
- mapped die Datenstrukturen X-Belieben um
- stellt die fertigen Daten dem Zielsystem auf einem praktisch
x-beliebigen Weg (TCP/IP, NFS, RFC oder Telekommunikation) zu
Wenn sich da im remoten System etwas tut, hast du im SAP nur
noch Aufwand, wenn die Daten nicht im IDoc sind und das ist
naturgemäß eher selten, wenn das System erst einmal steht.
> > Und möglicherweise macht IBM u. a. diese Standorte deshalb platt,
> > weil es diese Mainframes nicht mehr gibt, die da neulich noch betreut
> > wurden! Denn sie wurden abgelöst durch C/S-Systeme mit SAP R/3-
> > Applikationen, und, ja, neben der R/2->R/3-Migration wurde die gesamte
> > nonSAP-PL/1-COBOL-RPG-/370-Assembler-FORTRAN-CSP-Mainframe-
> > Landschaft gleich mit abgelöst.
>
> Nit gleich mit der Axt den ganzen Wald roden. Fortran hatte im
> mainframe Bereich nie eine Bedeutung, sondern eher im
> Grossrechnerbereich (sind das nun Mainframes oder nicht?)
Also hier sind Mainframes = Großrechner. Im konkreten Fall
2 oder 3 /390-Systeme mit etlichen CPUs, weiß nicht mehr genau.
Und ein wenig FORTRAN-Applikationen waren da wirklich noch,
nicht mehr viel, da hast Du ganz Recht. Und bei Stahlkochern sind
Rechenprozesse (Energieversorgungen, finite Elemente z. B. für
Legierungsstrukturen) nichts Exotisches. Hatte selber einst einmal
das (zweifelhafte) Vergnügen in die bis dato gefestigte PL/1-Landschaft
einen externen FORTRAN-Source (in Lochkarten!!!) zu implementieren,
weil ein Gasversorger an seinen Messstationen die Gas-Verhältnisse
nach AGA-NX19 interpolieren wollte...
Ich hätte auch noch etliche andere Akronyme bedienen können,
von VM über MVS und CMS und CICS und TSO und und...
Insgesamt haben wir ich weiß nicht wieviele tausend Jobs und eine
hohe vierstellige Zahl an Individual.Programmen und mehrere
R/2-Systeme durch R/3-Systeme erfolgreich abgelöst. Für einige
tausend Anwender. Keine Kleinigkeit imho. M. W. gabs dazu
auch Success-Stories..
> Cybers oder andere Vectorrechner. Die werden zwar auch nicht
> mehr weiterentwickelt, sondern die Richtung geht auch hier in
> Richtung Supercluster, aber da wo Fortran noch am werkeln ist
> sehe ich kein sterben, sondern eher ein Wachsen.
Ja, in Nischen wo extreme Rechengewalt (Datenmodelle, Simulationen)
bis zum Abwinken benötigt wird. In Handel und Wandel hat die Benutzer-
nähe Vorrang, sind erlösorientierte Ansätze wichtiger.
> Der
> marktanteil solcher Maschinen ist aber dermassen gering, das
> selbst ein 1000%iges Wachstum nichts an der Gerungfügigkeit
> ändert.
Das haben Nischen so an sich, deswegen muss man sie nicht geringer
achten. Im Gegenteil: das ist doch das Pfund, mit dem die kommenden
Generationen wuchern können! Rechner, Systeme, Systemlandschaften,
Serverfarmen und Applikationen für *jeden* Zweck. Der erste Schritt
dahin waren die ersten programmmieren Tischrechner, der zweite der
persönliche Computer. Hätte mir einer Anfang der 1970er gesagt,
ich hätte mal eine "Walkman" in der Hosentasche mit mehr Speicher-
kapazität als alle Rechenzentren in Nordddeutschland zusammen haben,
ich hätte die Jungs mir der praktischen weißen Jacke gerufen...
> So wie ich das sehe, sieht er ueber seinen
> Banken/Versicherungenteller nicht hinweg oder will mutwillig
> die Augen verschliessen, waht do i know. Aus seiner
> Perspektive hat er aber Recht, Mainframes sterben bei Banken
> und Versicherungen noch lange nicht aus.
;-)
Im Prinzip stimme ich damit überein, was Banken und Assekuranz
angeht. Nur: definiere "noch lange nicht". Haben wir bei uns auch mal
gesagt und dann gings auf einmal ratz-fatz. Wenn du erst mal 20 Jahre
im Job bist, gehen die nächsten 10 so fix um wies Katzenf*cken....
> Jedenfalls nicht,
> solange es sich fuer die IBM irgendwie doch noch lohnt, diese
> Kisten zu produzieren und zu warten,
Vorsichtig!
In erster Linie muss es sich für Banken und Versicherer lohnen.
Wenn die eine Chance sehen, die Buchhalternase in der Bilanz
ein Eckchen hochzusetzen, dann machen die das. Nicht nur
beim Personal...
Dann ist auch da smoke on the water, fire in the sky!
--
MfG
Manfred Albat m.albat@gmx.de
der computer rechnet, der mensch zaehlt!
