RSE-Editor

[malzusrex]

Hmmm,

also ich bin auch noch nur mit dem PDM unterwegs.
Sollte ich mich da wohl mal langsam umorientieren ?
Gibt es irgendwo eine Preisliste, was die Lizenzen pro Arbeitsplatz kosten?

Gruß
Ronald

[nico1964]

Hmmm,

also ich bin auch noch nur mit dem PDM unterwegs.
Sollte ich mich da wohl mal langsam umorientieren ?
Gibt es irgendwo eine Preisliste, was die Lizenzen pro Arbeitsplatz kosten?

Gruß
Ronald

Also ich finde den RDp mittlerweile schon sehr praktisch und brauche den Green Screen fast nur mehr für Systemarbeiten.
Wegen Preisen am besten mit einem offiziellen Vertriebspartner in Verbindung setzen. Ich weiß, dass bei uns einiges an Nachlass herausgeschaut hat.
Gruß
Andreas

[andreaspr@aon.at]

Gibt es irgendwo eine Preisliste, was die Lizenzen pro Arbeitsplatz kosten?

Wie gesagt, eine Lizenz sollte jeder haben, jede weitere kostet ca. um die € 700 wenn ich das noch richtig in Erinnerung habe.

[dschroeder]

Wir haben RDP seit ca. 2 Jahren im Einsatz. Ich möchte das nicht mehr missen. Bestimmte Sachen, Sourcen kopieren und durchsuchen machen wir allerdings oft noch per PDM. weil das schneller geht.

Wir haben damals einen 2 tägigen Einführungskurs gemacht. Das hat sich echt gelohnt. Es mussten einige Einstellungen vorgenommen werden, da wir spezielle Compile-Programme haben. Das ging zusammen mit dem Kursleiter erheblich schneller. Wir hatten vorher ein paar Mal versucht, das ganze im Selbststudium zu erlernen. Aber das hat nie geklappt. Es war uns alles immer zu langsam. Jetzt wo alles richtig eingestellt ist und rund läuft, ist das Ding super. Allerdings hat es noch kleinere Bugs.

Dieter

[andreaspr@aon.at]

Bestimmte Sachen, Sourcen kopieren und durchsuchen machen wir allerdings oft noch per PDM. weil das schneller geht.

Wir arbeiten hier mit den Sourcen nicht direkt auf der AS/400 sondern über Projekte in einer Versionsverwaltung.
Dadurch ist zum einen das Arbeiten (Suchen, Kopieren usw.) um einiges schneller als wenn direkt auf dem System gearbeitet werden würde.
Und zum anderen alle Vorteile die eine Versionsverwaltung mit sich bringt. (Erstellen von Versionen, Historie, was wurde wann von wem geändert usw.)

lg Andreas

[dschroeder]

Wir haben auch darüber nachgedacht, die Sourcen in einem Versionskontrollsystem abzulegen. Aber wir sehen da das Problem, die automatische Kompilierung von Sourcen durchzuführen. Mit PDM bzw. mit OS/400-Commands können wir ja alle Sourcefiles durchsuchen und gleich eine Kompilierung starten. Z.B. weil sich eine Datei geändert hat und alle betroffenen Programme gewandelt werden müssen.

Deshalb haben wir zur Zeit nur eine einfache selbstgebaute Versionierung. Nach jeder Kompilation prüft user Compile-Programm, ob der Source eine Abweichung zur Vorgängerversion hat und legt ggf. eine neue Sicherung des Sources in einer Datei an.

Unsere Java Kollegen arbeiten natürlich alle mit einer professionellen Sourceverwaltung. Wenn wir das mit dem "alle Sourcen durchsuchen und eine Aktion auslösen" hinkriegen würden, wäre das für uns eventuell auch ein Weg.

Dieter

[andreaspr@aon.at]

Das eine hat mit dem anderen eigentlich nur wenig zu tun.
Wir haben auch ein eigenes Programm zum Erstellen der Programme.
Und auch wir verwenden im PDM Option 25 --> Suchen und erstellen.
Die Sourcen sind ja auch weiterhin auf dem System vorhanden.
Arbeiten tun wir halt zunächst mit der Versionsverwaltung (auch mit den Java-Jungs gemeinsam) und im 2ten Schritt werden die Änderungen auf dem System synchronisiert und erstellt.

[nico1964]

@Andreas und Dieter
Wir verwenden mittlerweile seit 2010 das gesamte Rational Paket auf der i-Series.
1. Versionisierung ist damit auch gegeben, da im TeamConcert auch Sourcecodemanagement enthalten ist
2. Compile's:
Auch wir verwenden selbstgeschriebene Scripts zum Compile, da wir nicht überall die Standardwerte vom Betriebssystem verwenden(historisch gewachsen) Diese Befehle sind im TeamConcert als BuildScripts hinterlegt.

Damit vereinen wir einerseits die Vorteile von TeamConcert(SourceCodeManagement) mit dem flexiblen Builden auf der i-Series.

Was ich mir leider noch nicht anschauen konnte ist die aktuellste Version, da in dieser Punkto Releasemanagement angeblich riesige Fortschritte von den Rational Entwicklern eingebaut wurden.
LG
Andreas

[andreaspr@aon.at]

Was die Versionsverwaltung betrifft würde ich für den ersten (oder auch alle anderen) Schritt(e) auf SVN oder GIT setzen.
Diese sind einfach, "plattform unabhängig", bieten viele Möglichkeiten und vor allem Kostenfrei!

Bei der kompletten Rational-Familie wird es viele Abschrecken. Und ein "ich probier es mal aus" ist nicht so einfach.

lg Andreas

[nico1964]

Bei der kompletten Rational-Familie wird es viele Abschrecken. Und ein "ich probier es mal aus" ist nicht so einfach.

lg Andreas

Wir haben ja auch "nur" Rational Team Concert und Rational Developer im Einsatz und auch nur diese lizensiert. Der Vorteil der sich uns daraus ergibt resultiert vor allem in Versionierung und Releasemanagement, wobei wie schon erwähnt der 2. Punkt mit der aktuellsten Version um einiges weiter entwickelt wurde.
Ich weiß schon wir fahren hier mit dem Ferrari und hätten es vermutlich auch billiger haben können.
lg
Andreas

[nico1964]

Und ein "ich probier es mal aus" ist nicht so einfach.

lg Andreas

Ach ja habe ich vergessen. Wir waren damals (Ende 2009) Pilotkunde bei IBM für Österreich und Deutschland und hatten dadurch natürlich einen Startvorteil. Im Nachhinein gesehen würde ich es aber wieder machen, wobei ich mir von IBM den Weg nicht vorhüpfen lassen würde, sondern versuchen meinen eigenen Weg(den jetzigen) zu gehen.
lg
Andreas

[Frank Hildebrandt]

@Dieter

die von Dir beschriebene Variante der Rekompilierung abhängiger Programme bei Änderung einer Datei ist natürlich auch keine exakte Wissenschaft. Wenn z.B. nach Änderung einer physischen Datei irgendwelche abhängigen logischen Dateien völlig andere Namen haben als die physischen Datei, dann kann einem dieses schnell durchgehen.

Für solche Dinge sind unter IBM i Change Management Systeme zuständig. Da gibt es dann ein zentrales Repository, welches die Abhängigkeiten zwischen den Objekten enthält wie z.B. PF-->LF-->-->PGM. Solch ein System weiß dann immer, welche Objekte bei der Änderung einer Datei in welcher Reihenfolge rekompiliert werden müssen. Versionsmanagement alla CVS und Git ist bei Change Management Systemen nur ein Feature von vielen. Und jedes vernünftige Change Mangement System bietet natürlich auch ein entsprechendes Plugin für den RDP (In der aktuellen Version 9.0 heißt das Ding wieder RDi und ist ab sofort bei IBM verfügbar), mit dem die Funktionen des CMS direkt im RDP nutzbar sind, so dass man nicht mehr in der grünen Welt arbeiten muss.

Wir sind Hersteller des Change Management Systems CMOne und übermorgen auf der IT-Power 2013 in Stuttgart als Aussteller vertreten. Falls Zeit und Interesse besteht, so können wir dort jedem Interessierten CMOne live und in Farbe präsentieren. Auf unserer Homepage kann man sich im Downloadbereich eine Einladung herunterladen, die einen kostenlosen Besuch der Messe ermöglicht. Für diejenigen, bei denen das zeitlich nicht passt, die jedoch trotzdem Interesse an einem Change Management System haben, können wir einen kostenlosen und unverbindlichen Termin für eine Präsentation via TeamViewer vereinbaren.