*srvpgm

[BenderD]

Hallo,

solange man kein RCLACTGRP macht und die Objekte alle mit Replace (yes) erstellt und sich keine Signaturen geändert haben, läuft da schlicht die alte Version, wenn es vorher aktiviert war und die neue, wenn es später aktiviert wird. Was verstehst du denn unter "großem Unfug", der da bei euch passiert???

mfg

Dieter Bender

Bei uns haben die Programme benannte Aktivierungsgruppen oder *caller.

Aber wenn ich das jetzt richtig verstanden habe, heißt das, dass sich alle User neu anmelden müssen, damit keine Fehler passieren? Das schlimme ist ja, dass die Programm nicht einmal abbrechen, sonndern irgenwie weiterlaufen.

Programme, die aber noch laufen, arbeiten doch mit dem Objekt in der QRPLOBJ sprich mit der alten version oder?

Das heißst im Menü könnte man RCLACTGRP *ELIGIBLE einbauen um ein Neuanmelden zu umgehen?

[Fuerchau]

Tja Dieter, der Unfug ist eben, dass die alte Version aufgerufen wird und nicht die Neue

[Xanas]

Das ist ne gute Frage, wenn ich das wüsste, ich hatte z.B mal eine zusätzliche Procedure in ein Servicprogramm eingebaut und das Serviceprogramm neu erstellt. Das Programm was das Serviceprogramm verwendet, hatte dann bei einer Procedure (nicht die neue Procedure) lauter Schrott in den Parametern übergeben. Dann hab ich das Programm einfach noch mal kompiliert und alles war wieder in Ordnung. Das Problem ist mir aber schon öffters aufgefallen, war also kein Einzelfall, kann aber nicht nachvollzeihen, was die Ursache ist.

[BenderD]

Hallo,

wenn die zusätzliche Prozedur exportiert wird, dann ändert sich die Signatur des Service Programms und dann ist eine Neu kompilieren des Programmes der sinnvollste Weg das erforderliche zu veranlassen; alle Spielereien mit Binder Language und ähnlicher Unfug, haben genau die Probleme als Nebenwirkung, die du benennst. Lässt man diesen unnötigen Quatsch, dann stirbt das Programm sofort beim Aufruf, oder es tut genau das, was es soll (zumindest das, was in der Quelle programmiert wurde).

mfg

Dieter Bender

Das ist ne gute Frage, wenn ich das wüsste, ich hatte z.B mal eine zusätzliche Procedure in ein Servicprogramm eingebaut und das Serviceprogramm neu erstellt. Das Programm was das Serviceprogramm verwendet, hatte dann bei einer Procedure (nicht die neue Procedure) lauter Schrott in den Parametern übergeben. Dann hab ich das Programm einfach noch mal kompiliert und alles war wieder in Ordnung. Das Problem ist mir aber schon öffters aufgefallen, war also kein Einzelfall, kann aber nicht nachvollzeihen, was die Ursache ist.

[Xanas]

Also ist das keine gute Idee, ein Servieprogramm mit einer neuen Export Procedure mit der gleichen Signatur wie vorher zu erstellen?

Ich ändere die Signatur nur dann, wenn ich bei schon vorhandenen Export Procedures die Parameter verändere.

Der Grund dafür war/ist, dass sich die Signatur nicht immer wie erwartet ändert. Zum Beispiel hab ich zum Test mal ein Alpha Parameter in ein Numeric Parameter geändert, nach kompilieren, war aber immer noch die selbe Signatur, des halb ich mir ein Tool geschrieben, in dem ich entscheiden kann wann die Signatur geändert werden soll.

[B.Hauser]

Also ist das keine gute Idee, ein Servieprogramm mit einer neuen Export Procedure mit der gleichen Signatur wie vorher zu erstellen?

1. Wird eine Prozedur hinzugefügt einem Service-Programm hinzugefügt, oder aus derm Service-Programm entfernt, ändert sich die Signatur.

2. Die Signatur kann sich ebenfalls ändern, wenn die Reihenfolge der exportierten Prozeduren verändert wird. Deshalb sollten neue exportierte Prozeduren immer am Ende der vorhandenen Quelle(n) eingefügt werden. Werden mehrere Module zu einem Service-Programm zusammengefaßt, sollte auch die Reihenfolge in der die Module aufgelistet werden beibehalten werden.

Auch wenn man mit Binder-Sprache arbeitet und die Signatur nicht erstellen läßt, sondern vorgibt, scheint intern eine andere Signatur verwendet zu werden.

3. Die Signatur kann sich ebenfalls verändern, wenn Parameter hinzugefügt oder entfernt werden.

Der Grund dafür war/ist, dass sich die Signatur nicht immer wie erwartet ändert.

Wie bzw. wann erwartest Du denn, dass die Signatur sich ändert?

Zum Beispiel hab ich zum Test mal ein Alpha Parameter in ein Numeric Parameter geändert, nach kompilieren, war aber immer noch die selbe Signatur, des halb ich mir ein Tool geschrieben, in dem ich entscheiden kann wann die Signatur geändert werden soll.

Wie änderst Du denn die Signatur?

Die beste Lösung (wenn man mehrere exportierte Prozeduren in einem Service-Programm zusammenfassen will) und nicht die Anwendung neu compilieren will, ist schon die Binder-Sprache zu verwenden. (Auch wenn Dieter das nicht so sieht!)
Es funktioniert, wenn man es korrekt macht!

Also:
1. Der alte Stand, also die zuvor exportierten Prozeduren als Previous sichern. Alle alten Stände sollten beibehalten werden.

2. Die Reihenfolge der exportierten Prozeduren sollte nicht verändert werden. Neue Prozeduren immer am Ende der Liste einfügen.

3. Da intern anscheinend sowieso eine andere Signatur verwendet wird, am besten die Signatur über das System erstellen lassen.

4. Level Check niemals auf *NO setzen

5. Die Binder-Quelle nur dann verändern, wenn eine Prozedur hinzugefügt wird.

Im Gegensatz zu vielen anderen, würde ich in einem Service-Programm nur genau 1 Modul registrieren. Neue Prozeduren immer in dieses Modul am Ende hinzufügen. Und lieber ein zusätzliches Service-Programm (z.B. mit einer Erweiterung im Namen MySrvPgm1) generieren.

Birgitta

[Xanas]

In der Tat, die Procedure hatte ich nicht ans Ende gesetzt. Wollte ich für ein schickeren Quellcode so.

3. Die Signatur kann sich ebenfalls verändern, wenn Parameter hinzugefügt oder entfernt werden.

Was mich am meisten daran stört ist das "kann" des wegen, selbst in die Hand nehmen.

Wie bzw. wann erwartest Du denn, dass die Signatur sich ändert?

Erwartet hatte ich es so ähnlich wie bei einer Datei Änderung.

Wir haben auch nur ein Modul in einem Serviceprogramm und
meine Tool erstellt die Binderquelle aus der Modulquelle abhand der Export Procedures.
naja ich werde es dann noch erweitern, dass es Änderungen an der Reihenfolge des Procedures erkennt und die Signatur zwingend ändert.

Am liebsten würde ich zur laufzeit Binden, aber so weit hab ich die Kollegen noch nicht,
gegeargumnet ist nämlich immer die Referenz. Für mich blödsinn, aber ich Jungspund kenn das ja eben nicht anderest.

Naja auf jedenfall schon mal vielen vielen Dank für die Antworten, dann weiß ich ja jetzt schon mal grob worauf man achten muss. Aber ich bin natürlich für jeden weiteren Tip diesbezüglich dankbar.

Xanas

[Fuerchau]

Ein Modul mit mehreren Prozeduren ist genauso zu betrachten wie mehrere Module mit je 1 Prozedur.
In diesem Fall gilt eben genau das selbe wie von Birgitta beschrieben.
Die Reihenfolge der Prozeduren ist GENAU einzuhalten.
Bei Parameteränderungen einer Prozedur gibt es dann keine Signaturänderung, wenn nur Adressen übergeben werden und die Anzahl der Parameter bleibt.
Aus einem numerischen ein Zeichenfeld zu machen ändert nicht die Signatur, wenn der Parameter "by reference" übergeben wird.
Das fertige Modul kennt halt nur noch Adressen, Felder und Längen/Ausprägungen sind beim Binden nur noch Schall und Rauch (daher keine Signaturänderung).

Naja, und das Ändern im laufenden Betrieb sollte sowieso verhindert werden !

[BenderD]

Hallo,

Quelle allen Übels ist hier (wie meist) der überflüssige Quatsch mit der Binder Language. Warum denn so kompliziert:
- Immer mit export(*ALL) wandeln
- Bei den Porcedures mit EXPORT steuern, was exportiert werden soll.
- bei Änderung ohne Schnittstellenänderungen bei den Exporten wird nicht neu gebunden
- bei Änderung von exportierten Schnittstellen und dem Hinzufügen von Exporten alles, was verwendet neu binden
- zur Automatisierung change Management oder
-- Compile Befehle in Quelle
-- Precompiler (Freeware von mir oder selber schreiben) zum wandeln einsetzen
-- per Tool ermitteln was gebunden werden muss und neu binden

mfg

Dieter Bender

PS: dynamisch binden (gibts auch Freeware von mir) ist selbstredend am elegantesten.

In der Tat, die Procedure hatte ich nicht ans Ende gesetzt. Wollte ich für ein schickeren Quellcode so.


Was mich am meisten daran stört ist das "kann" des wegen, selbst in die Hand nehmen.


Erwartet hatte ich es so ähnlich wie bei einer Datei Änderung.

Wir haben auch nur ein Modul in einem Serviceprogramm und
meine Tool erstellt die Binderquelle aus der Modulquelle abhand der Export Procedures.
naja ich werde es dann noch erweitern, dass es Änderungen an der Reihenfolge des Procedures erkennt und die Signatur zwingend ändert.

Am liebsten würde ich zur laufzeit Binden, aber so weit hab ich die Kollegen noch nicht,
gegeargumnet ist nämlich immer die Referenz. Für mich blödsinn, aber ich Jungspund kenn das ja eben nicht anderest.

Naja auf jedenfall schon mal vielen vielen Dank für die Antworten, dann weiß ich ja jetzt schon mal grob worauf man achten muss. Aber ich bin natürlich für jeden weiteren Tip diesbezüglich dankbar.

Xanas

[Xanas]

Hallo,

Quelle allen Übels ist hier (wie meist) der überflüssige Quatsch mit der Binder Language. Warum denn so kompliziert:
- Immer mit export(*ALL) wandeln
- Bei den Porcedures mit EXPORT steuern, was exportiert werden soll.
- bei Änderung ohne Schnittstellenänderungen bei den Exporten wird nicht neu gebunden
- bei Änderung von exportierten Schnittstellen und dem Hinzufügen von Exporten alles, was verwendet neu binden
- zur Automatisierung change Management oder
-- Compile Befehle in Quelle
-- Precompiler (Freeware von mir oder selber schreiben) zum wandeln einsetzen
-- per Tool ermitteln was gebunden werden muss und neu binden

mfg

Dieter Bender

PS: dynamisch binden (gibts auch Freeware von mir) ist selbstredend am elegantesten.

Ich bin ganz Deiner Meinung, aber eins nach dem andern ich muss erst 4 andere Kollegen immer davon überzeugen. Aber ist ja auch manchmal gut so, kan ja nicht immer jeder tun und lassen was man will.

Ich hatte den Quatsch mit der Binder Language nur wegen der Signatur gemacht. Meine Logik sagte mir halt auch, dass eine neue Export Procedure keine neues kompilieren der Verwendenden Programme notwendig macht, aber ich bin eines besseren belehrt worden

Wie gesagt vielen Dank
Xanas