View Full Version : Initialisieren von Datenstrukturfeldern
Hallo,
ist möglich, DS-Felder mit anderen als konstanten Werten zu Initialisieren?
Konkret ist mein Problem folgendes:
Ich baue einen Trigger der Änderungen in Sätzen mehrerer Dateien protokolliert. Dazu habe ich Datenstrukturen definiert, die sich mit der Defnition an
den Schlüsselfeldern der zu überwachenden Dateien orientieren. Nun möchte ich beim Programmaufruf die Werte in den Schlüsselfeldern in der Datei
die den Trigger gefeuert hat ins Programm bekommen. Ich habe überlegt, das über einen Pointer zu machen, aber das wäre ziemlich umständlich.
Gibt es in der Richtung eine andere Möglichkeit? Derzeit sieht mein Versuch so aus:
D dsKey01 DS Qualified
D LNGG Like(dsOldMLSSDC.LNGGDC)
D Inz(dsOldMLSSDC.LNGGDC)
D FLDD Like(dsOldMLSSDC.FLDDDC)
D Inz(dsOldMLSSDC.FLDGDC)
Für die Inz-Zeilen bekomme ich zwei Compile-Fehler:
*RNF0622 20 a 002300 Ein qualifizierter Name ist in diesem Kontext nicht
zulässig.
*RNF3432 20 b 002300 Der Anfangswert DSOLDML... für Feld LNGG ist keine
Konstante; der Anfangswert wird ignoriert.
Hat da jemand eine Idee, wie ich dem Ganzen beikommen könnte?
Für Vorschläge schon im Vorfeld dankbar,
Björn
Hi Bjärn,
Wenn eine Datenstruktur wie eine andere initialisiert werden soll, muss inz(*LikeDS) angegeben werden.
Ansonsten ist mir nicht ganz klar, was Du erreichen willst.
Du hast doch den alten und den neuen Satz in einem Trigger-Programm im Zugriff.
Ein einfaches Beispiel für Trigger-Programme ist unter folgendem Link zu finden:
Are you trigger happy? (http://www.eservercomputing.com/iseries/articles/index.asp?id=169)
Birgitta
INZ läßt nur Konstanten zu !
Um eine Referenzierung der getriggerten Datei per Pointer wirst du nicht herumkommen, da das die einzige Möglichkeit ist, Releaseunabhängige Trigger zu bekommen.
Initialisierungen musst du halt mit EVAL durchführen.
Ausserdem wirken Init's nur beim allerersten Aufruf !!!
Da Trigger (aus Performancegründen) nie mit *INLR=*ON verlassen werden sollten, hilft dir der INZ sowieso nicht weiter.
Ab V5R1 ist es günstiger und auch erheblich einfacher, die Trigger per SQL (SQL-Body) zu definieren.
Hallo Björni,
so umständlich ist das mit den Pointern nicht. Ein komplettes Beispiel findest du auch auf meiner open Source Seite.
mfg
Dieter Bender
@Baldur: was mir mit den SQL Triggern nicht gefällt, ist zumindest das Deployment und je nachdem, was da an funktionaler Logik rein soll, hat da SQL auch seine Grenzen.
Hallo,
ist möglich, DS-Felder mit anderen als konstanten Werten zu Initialisieren?
Konkret ist mein Problem folgendes:
Ich baue einen Trigger der Änderungen in Sätzen mehrerer Dateien protokolliert. Dazu habe ich Datenstrukturen definiert, die sich mit der Defnition an
den Schlüsselfeldern der zu überwachenden Dateien orientieren. Nun möchte ich beim Programmaufruf die Werte in den Schlüsselfeldern in der Datei
die den Trigger gefeuert hat ins Programm bekommen. Ich habe überlegt, das über einen Pointer zu machen, aber das wäre ziemlich umständlich.
Gibt es in der Richtung eine andere Möglichkeit? Derzeit sieht mein Versuch so aus:
D dsKey01 DS Qualified
D LNGG Like(dsOldMLSSDC.LNGGDC)
D Inz(dsOldMLSSDC.LNGGDC)
D FLDD Like(dsOldMLSSDC.FLDDDC)
D Inz(dsOldMLSSDC.FLDGDC)
Für die Inz-Zeilen bekomme ich zwei Compile-Fehler:
*RNF0622 20 a 002300 Ein qualifizierter Name ist in diesem Kontext nicht
zulässig.
*RNF3432 20 b 002300 Der Anfangswert DSOLDML... für Feld LNGG ist keine
Konstante; der Anfangswert wird ignoriert.
Hat da jemand eine Idee, wie ich dem Ganzen beikommen könnte?
Für Vorschläge schon im Vorfeld dankbar,
Björn
@Birgitta,
wenn ich über *LikeDS gehen würde, müsste es doch die Vorlage für die Struktur mit den gleichen Feldern bestehen, oder? Leider gibt es diese Strukturen nicht in jedem Fall. Die Dateien haben noch jede Menge mehr Felder als die nur die mit den Schlüsselinformationen... und Strukturen nur für die Schlüssel haben wir hier soweit ich weiss nicht (keine Ahnung ob das normal wäre).
;) Was ich damit erreichen will, ist mir selber auch nicht so hunderprozentig klar...
Die Idee ist, die Struktur des Zugriffs auf die in Arbeit befindliche Datei in der Satzart zu verschlüsseln. Will sagen, ich soll rausbekommen, über welche Schlüsselstruktur zugegriffen wird und daraus dann einen Wert machen der wiederum in den Schlüssel der Logdatei aufgenommen wird.
Ich hatte ursprünglich den Plan, diese Satzart einfach über den Dateinamen zu vergeben, aber dadurch würde dann nicht der Zugriff geschlüsselt sondern eben nur die Datei und das soll so nicht.
Jetzt habe ich aber schon das eine oder andere mal darüber mit meinem Betreuer gesprochen und inzwischen ist es mir inzwischen ein bisschen unangenehm... Daher will ich wenigstens eine Lösung parat haben bevor ich das nächste mal darauf zu sprechen komme. Diese Lösung soll darauf rauslaufen zu prüfen, welche der Schlüsselfelder leer sind. Sind sie nicht leer, dachte ich mir, sie würden beim Aufruf des Triggers belegt worden sein und zwar nur die Felder der Datei die den Trigger feuert.
Nicht das Gelbe vom Ei, das ist mir nur zu bewusst, aber ich möchte halt nicht wieder mit ganz leeren Händen dastehen...
@Fuerchau
Die Information über *INLR hatte ich noch nicht... gut zu wissen!
Der gesamte Trigger wird über Pointer Referenziert, ich habe Zugriff auf alle Daten die ich für die sonstige Verarbeitung brauche, aber die Satzart bereitet mir massives Kopfzerbrechen. Und sonst habe ich eben leider keine Idee wie sich das Problem in den Griff bekommen ließe...
D pOldData S * Inz(*Null)
D pNewData S * Inz(*Null)
** Übernehme Datenstrukturen der zu prüfenden Dateien für Datenabgleich
D dsOldMLSSDC E DS Qualified ExtName(MLSPFSDC)
D Based(pOldData)
D dsNewMLSSDC E DS Qualified ExtName(MLSPFSDC)
D Based(pNewData)
D dsKey01 DS Qualified
D LNGG Like(dsOldMLSSDC.LNGGDC)
D FLDD Like(dsOldMLSSDC.FLDDDC)
Die hier einebaute Datei hat z.B. 11 Felder aber nur zwei davon machen den Schlüssel.
Und gewünscht wird halt eine Methode die die Satzart zurückliefert. Ich könnte da z.B. die Datenstruktur als Parameter mitgeben und dann daraus die Satzart ableiten, aber wie bekomm ich ohne den Dateinamen denn raus, welche Struktur ich überhaupt mit übergeben müsste?
Ihr seht also, mir ist die eigentlich Idee dahinter noch nicht so recht klar.
Herzlichen Dank für eure Zeit,
Björn
Ich lese da immer was von Satzart ?!?
Eine PF (per DDS bzw. SQL erstellt) hat keine Satzart !!!
Für jede PF musst du (solltest du!!) einen eigenen Trigger erstellen (ist sowieso leichter wartbar) und die benötigten Trigger-Definitionen per COPY reinziehen.
Welche Operation (Insert, Update, Delete) läuft, erfährst du über die Trigger-Struktur.
Schlüsselfelder kannst du dann direkt per KLIST (wie bisher) oder per DS definieren.
Ab V5R2 kannst du die Felder im Frreform auch per %KDS() direkt angeben.
Den Dateinamen erfährst du auch über die Trigger-Info, so dass du deine Protokollsätze erzeugen kannst.
Hallo Fuerchau,
Die Dateien sind alle per DDS erzeugt, sowohl zu protokollierende als auch Prokolldatei.
Allerdings sagt dazu der ILE Programmers Guide:
You can use DDS to describe files to the OS/400 system. Each record type in the
file is identified by a unique record-format name.
[...]
The information in this external description includes:
[...]
- Record-format description, which includes the record format name and field
descriptions (names, locations, and attributes).
Scheinbar habe ich mit der Thematik noch reichlich Verständnisprobleme. Das Satzformat legt doch die Dateistruktur, also Feldarten, -Längen und -Namen fest?! Und wenn ich den zitierten Absatz richtig übersetze, ist die Satzart per Satzformat festgelegt. Das wird über die DDS gemacht... Wo liegt denn mein Fehler in der Übersetzung, wenn du sagst, dass eine PF keine Satzart hat?
Die Dateinamen etc. habe ich ja, das ist alles gar nicht mein Problem. Vielleicht ist an dieser Stelle auch der Terminus "Satzart" missverständlich weil es eigentlich nur um die Art des Zugriffs auf die jeweilige Datei geht, quasi also mehr die Schlüsselart. Und dafür soll ich den Dateinahmen gerade nicht verwenden.
Ich verspreche, möglichst bald irgendeinen Kurs zu besuchen, wo ich lerne derartige Probleme verständlicher darzustellen. Du wärst nicht der erste der mir in dieser Richtung nicht ganz folgen kann...
Herzlichen Dank für deine Geduld,
Björn
Per DDS musst du ein Satzformat (=Satzart) definieren.
Eine PF kann aber genau nur 1 Satzformat enthalten !!!
Per DDS werden auch Display, Printer, LF's oder auch ICF's definiert. In diesen Dateitypen können mehrere Satzformate (Satzarten) definiert werden, schließlich möchte ich verschiedene Daten ausgeben können.
Bei LF's gibts noch den Sonderfall mit mehreren Satzformaten, jedoch eher selten.
Eine PF ist wie bei SQL als Tabelle zu sehen und kann daher keine unterschiedlichen Informationen aufnehmen (auch hier gibt es natürlich noch Ausnahmen, wenn ich ein Zeichenfeld intern nochmal strukturiere).
Trigger sind halt nur auf einer PF (Tabelle) möglich und brauchen sich daher nicht um Satzarten kümmern.
kuempi von stein
12-10-04, 13:41
Vielleicht ist an dieser Stelle auch der Terminus "Satzart" missverständlich weil es eigentlich nur um die Art des Zugriffs auf die jeweilige Datei geht, quasi also mehr die Schlüsselart. Und dafür soll ich den Dateinahmen gerade nicht verwenden.
ah ja...
wie Fuerchau bereits gesagt hat ...
man legt nen trigger(pgm) auf eine Datei ...
und bekommt dann AUTOMATISCH
den Zustand VORHER/NACHHER für jedes einzelne Feld und man bekommt auch die "ART?" des Zugriffes (UPDATE/INSERT/DELETE) ....
Weil ich da vor ner Weile auch mal rumgemacht habe mit der Triggerei werd ich da immer hellhörig wenn sowas im Forum dazu läuft...
Aber so ganz ist mir nicht klar wo das Problem liegt..
kuempi
Ahh, ok, ich glaube so langsam fällt bei mir der Groschen...
Lass mich den Begriff "Satzart" durch "Schlüsselart" ersetzen. Die ist für den Trigger selber vollkommen irrelevant! Ich soll aber Protokollieren, wie der Zugriff auf die einzelnen Dateien gelöst ist.
Ich habe ca. 30 Dateien an denen dieser Trigger später hängen soll. Die meisten haben einen geschlüsselten Zugriff nur über eine logische, andere auch über Schlüssel in der physischen Datei. Aber geschlüsselt sind sie alle.
Protokolliert werden die Bibliothek, Datei, Member, ändernder Nutzer, Änderungsart (*ins/*upd/*del) und noch einiges mehr. Zu dieser Menge an "mehr" gehört eben auch die Schlüsselart. Und die Schlüsselart ist eben das einzige was mir hierbei noch fehlt.
Als kleinen Hinweis hier der Aufbau von zwei Schlüsseln unterschiedlicher Dateien:
dsKey27 DS Qualified
TRKI Like(dsOldXCTCIZ.TRKIIZ)
und
dsKey26 DS Qualified
TRKI Like(dsOldXCTCIW.TRKIIW)
SPTT Like(dsOldXCTCIW.SPTTIW)
IPRC Like(dsOldXCTCIW.IPRCIW)
ORTY Like(dsOldXCTCIW.ORTYIW)
VLFL Like(dsOldXCTCIW.VLFLIW)
PRCI Like(dsOldXCTCIW.PRCIIW)
CRFL Like(dsOldXCTCIW.CRFLIW)
OPIT Like(dsOldXCTCIW.OPITIW)
GDRC Like(dsOldXCTCIW.GDRCIW)
Und über den Aufbau diese Strukturen, also Anzahl und größe der Felder soll ich einen Teil des Primärschlüssels der Protokolldatei aus einer Prozedur zurückliefern.
Ein bisschen klarer was mein Problem ist?