Programmstatistik "Zuletzt benutzt am" kann nicht stimmen

[dschroeder]

Hallo liebe Kolleginnen und Kollegen,

ich habe hier ein seltsames Phänomen: Ein Serviceprogramm, das genau eine Procedure exportiert, zeigt dauernd an, dass es benutzt wurde, obwohl es nicht aufgerufen worden sein kann.

Bisher haben wir uns immer auf die Objektstatistiken verlassen. Man kann ja mit DSPOBJD die Attribute eines Programmobjektes auslesen und erkennen, wann das Objekt zuletzt benutzt wurde. (Wir gehen davon aus, dass die Benutzung bei einem Programm bedeutet, dass es aufgerufen wurde.)

Änderungs-/Anwendungsinformation:                               Datum/Uhrzeit der Änderung . . . . . :   19.07.21  17:07:10 
  Nutzungsdaten erfasst  . . . . . . . :   J                  
  Zuletzt benutzt am . . . . . . . . . :   20.07.21           
  Anzahl der verwendeten Tage  . . . . :   2                  
    Rücksetzungsdatum  . . . . . . . . :

Bei dem Serviceprogramm ist es so, dass wir das Programm kompilieren können. Danach zeigt die letzte Benutzung auch nichts an. Keine Datum / Keine Anzahl der verwendeten Tage.
Aber nach ein paar Minuten steht plötzlich ein Wert drin. Das Programm kann aber definitiv nicht aufgerufen worden sein!

Interpretieren wir die Werte falsch oder gibt es außer dem Aufrufen einer Procedure noch andere Aktionen, die die Benutzungsdaten aktualisieren?
In der IBM Doku habe ich so etwas gefunden wie "Die Benutzungsdaten eines Serviceprogramms werden aktualisiert, wenn das Programm aktiviert wird".
Was immer mit aktiviert gemeint sein mag ...

Dieter

[BenderD]

... aktiviert meint, dass es geladen wurde. Das kann bereits dann erfolgen, wenn ein anderes PGM oder SRVPGM aufgerufen wird, das dieses SRVPGM gebunden hat.

D*B

[dschroeder]

Vielen Dank für die Antwort.

Das würde das Verhalten erklären. Ist aber sehr unschön. Eigentlich interessiert mich ja nicht, dass irgendein Programm den Prototype des Serviceprogramms eingebunden hat. Ich will ja wissen, ob es tatsächlich benutzt wurde, also ob irgendeine Procedure des Serviceprogramms aufgerufen wurde.

[Robi]

Nicht böse sein, aber bei uns läuft das unter Designfehler!
Warum sollte ich ein Servicepgm in einen Ablauf binden, wenn es nicht gebraucht wird?
Nach dem motto

"viele wenig ergeben ein viel"

läd die Kiste lauter 'Exotische' Funktionen, die sie nicht braucht.

[BenderD]

Nicht böse sein, aber bei uns läuft das unter Designfehler!
Warum sollte ich ein Servicepgm in einen Ablauf binden, wenn es nicht gebraucht wird?
Nach dem motto

"viele wenig ergeben ein viel"

läd die Kiste lauter 'Exotische' Funktionen, die sie nicht braucht.

... es werden prinzipiell nur Module und SRVPGMs gebunden, die auch benutzt werden könnten. Bei der Aktivierung ist der default, dass beim Aufruf eines Programms alles geladen wird, was auch benutzt werden könnte, was auch meistens Sinn macht. Beim CRTPGM lässt sich beim Parameter BNDSRVPGM einstellen, dass spät aktiviert wird (*DEFER), d.h. unmittelbar bei der ersten Referenzierung. Geht wohl auch im BNDDIR, was ich seit Jahrzehnten nicht mehr verwende. Noch flexibler ist man, wenn man selber per API aktiviert, dann wird nix gebunden und nix automatisch aktiviert, d.h., dass man zur LAufzeit entscheidet, was gebunden werden soll.

D*B

[dschroeder]

Hallo Robi

Ich bin nicht böse, glaube aber nicht, dass es ein Designfehler ist. Es geht im konkreten Fall um ein Serviceprogramm, das Daten löscht. In dem aufrufenden Programm hat man die Möglichkeit, Daten anzuzeigen oder zu löschen. Nur wenn ich tatsächlich löschen auswähle, wird das Serviceprogramm aufgerufen. Aber da ich natürlich jederzeit löschen auswählen könnte, muss das Programm (der Prototype) eingebunden sein.

[dschroeder]

Beim CRTPGM lässt sich beim Parameter BNDSRVPGM einstellen, dass spät aktiviert wird (*DEFER), d.h. unmittelbar bei der ersten Referenzierung. Geht wohl auch im BNDDIR, was ich seit Jahrzehnten nicht mehr verwende. Noch flexibler ist man, wenn man selber per API aktiviert, dann wird nix gebunden und nix automatisch aktiviert, d.h., dass man zur LAufzeit entscheidet, was gebunden werden soll.

D*B

Da muss ich mal ein bisschen nachlesen...

[Fuerchau]

Sobald ein (automatischer) Prozedurpointer gesetzt wird, erfolgt die Zuweisung der Benutzungsinfo.
Das ist wie beim impliziten Datei-Open. Lesen muss ich die ja dann nicht.

[BenderD]

... man beachte den Bundes Nachrichten Dienst: Seht euch mal den addbnddire an, der hat eine Einstellung für jedes Objekt, ob sofort oder erst bei tatsächlicher Verwendung aktiviert wird. CRTPGM beim Parameter BNDSRVPGM ebenso.

D*B

[dschroeder]

Vielen Dank an alle, insbesondere an Dieter Bender.

Den Parameter für *DEFER heben wir gefunden. Wir überlegen noch, ob das irgendwelche Nachteile haben kann, wenn wir die Aktivierung "verzögern". Laut IBM Hilfetext soll das ja sogar positive Auswirkungen auf die Performance haben.
Nachteile fallen mir da nicht ein. Deshalb wundert es mich, dass *DEFER nicht der Standardwert ist.

[B.Hauser]

*DEFER ist deshalb nicht Standard, weil er erst mit Release 6.1 eingeführt wurde.
Zuvor wurde immer alles mit *IMMED aktiviert.
Ansonsten gibt es keine Nachteile, im Gegenteil, anstatt alles beim ersten Aufruf zu aktivieren, wird ein Service-Programm erst dann gesucht und aktiviert, wenn der erste Aufruf einer Prozedur aus dem Service-Programm erfolgt. Damit kann man u.U. Zeit und Speicher sparen.
Die Zeitunterschiede (auch bei vielen Service-Programmen) liegen allerdings im Nano-Sekundenbereich.

[Robi]

unsere 'design vorgaben' stammen aus frühen 5.4 Zeiten

da wurde das 'löschen (in deinem Fall) gecalled wenn das Programm i.d.R zum ansehen und bearbeiten ist.
Ging bei uns immer um Speicherplatz, nie um die letzte nano Sekunde. In dialog Pgmmen ist ja eh der Anwender das langsamste ...