Initialisieren von Datenstrukturfeldern

[Fuerchau]

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.

[BUG]

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

[Fuerchau]

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.

[BUG]

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?

[BUG]

Kleine Ergänzung:

D dsOldMLSSDC E DS				 Qualified ExtName(MLSPFSDC)
D									 Based(pOldData)			
D dsNewMLSSDC E DS				 Qualified ExtName(MLSPFSDC)
D									 Based(pNewData)			
// Schlüsselstruktur der ersten Datei
D dsKey01		 DS				 Qualified				 
D LNGG							 Like(dsOldMLSSDC.LNGGDC) 
D FLDD							 Like(dsOldMLSSDC.FLDDDC) 
 
// Ähnlicher, aber eben doch nicht ganz der selbe Schlüssel in der zweiten Datei:
[...]																
D dsKey02		 DS				 Qualified				 
D FDLG							 Like(dsOldMLS0DC.FDLGDC) 
D FLDD							 Like(dsOldMLS0DC.FLDDDC) 
[...]

Jetzt soll ich eine Methode bauen, die die Informationen über die Schlüsselstrukturen für den Primary-Key der Logdatei aufbereitet. Die Aufbereitung ist natürlich banal, aber in diese Richtung soll es gehen:

*****************************************
*****   GetSArt ... Liefere Satzart	  
*****************************************
** Funktionsschnittstelle				
P GetSArt		 B					  
D GetSArt		 PI			10A	  
** Interne Variablen					 
**---------------------------------------
 /Free								   

// Das war meine Vorstellung bei meiner ursprünglichen Frage: 
// Es sind daten in den Feldern der DS -> diese Datei ist im Zugriff 
// und Schlüsselart 01 wird zurückgeliefert							   
										 
	 Select;							 
	   When dsKey01.LNGG <> '' and	   
		 dsKey01.FLDD <> '';			 
		 Return '01';					

// Einfacher wäre es natürlich so, aber das darf ich nicht.
										
	   When iBuffer.FleName = 'MLSPFSDC';
		 Return '02';					
										
 
	   // In dem Stil geht's noch n bisschen weiter
/End-Free																					 
**--------------------------------------------------------------------
P GetSArt		 E

[Fuerchau]

Das ist leider eine Aufgabenstellung die mit Trigger NICHT gelöst werden kann.
Die Art des Schlüssels für eine Änderung ist vollkommen irrelevant !!!

Denke dir nur einen SQL "update ... where ...". In der Where-Klausel kannst du unabhängig vom jeweiligen Schlüssel (Zugriffspfad) Sätze verändern.

Per DFU (z.B. UPDDTA) kannst du auch per Satz-Nr ändern usw. usw.

Wenn du 30 Dateien hast, benötigst du auch 30 Trigger-PGM'e. Schließlich musst du ja gezielt auf einzelne Felder zugreifen.

Da der Trigger auf der PF liegt, bekommst du gar nicht mit, ob eine Operation über eine LF erfolgt !!!

Jede Datei hat (oder auch nicht) einen Primär-Schlüssel.
Verwende genau diesen als einzigen Schlüssel der jeweiligen Datei, wobei ggf. darauf zu achten ist, dass auch Schlüsseländerungen möglich sind, will heißen, dass im Before- und After-Immage unterschiedliche Werte auch in Schlüsseln vorkommen können !!!!!

[BUG]

Guten Morgen,

na, da ist alles in allem doch eine Menge an Info die ich verwerten kann!
Herzlichen Dank, speziell an Fuerchau, für die Mithilfe!


Mein Betreuer wird sich schon irgendwas dabei gedacht haben als er mir diese
Aufgabenstellung hat zuteil werden lassen. Sobald ich weiss was das ist und wenn
es euch interessiert lass ich euch wissen was es war.

Schönen Tag, Björn

[BUG]

Hi,

also ich wollte 2 Schritte in einen packen. Es ging darum, den Dateinamen
vom Schlüssel zu entkoppeln. Dateiname -> Schlüsselart 'XY' -> Schlüsselinformation
anhand der Datenstruktur in Teil des Logschlüssels umsetzen.

Die von mir ursprünglich angedachte direkte Abfrage der Informationen zm Schlüssel durch eine Intialisierung war also Käse.

Nochmal herzlichen Dank für eure Zeit, Björn

[kuempi von stein]

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