View Full Version : zu doof zum Dateien kopieren!
FichtenElch
02-11-17, 16:22
Ich versuche zu verstehen:
Oberste Ebene: Bibliothek
Ebene darunter: Teildatei, oder "Unterordner"
Letzte Ebene: Dateien
Bibliotheken und Teildateien sind Objekte (*LIB, *PF), aber Dateien innerhalb von Teildateien sind keine Objekte?
... die original AS400 und ihr Vorgänger System /38 hatten keine Streamfiles, alle Daten waren in ISAM (Vorläufer von SQL Tabellen) Dateien untergebracht, die ihrerseits in Bibliotheken waren. Da das für Programmquellen und Texte (da gab es auch noch Office/400) in einer lediglich 2 stufigen Hierarchie unpraktisch ist, hat man dafür (analog zu partitioned Datasets (PDS) der Mainframes) die Ebene Member als Unterteilung von Dateien implementiert. Da Du nicht der Einzige bist, des das nicht verstanden hat, haben viele, wenn nicht die meisten, das auch für Datenbankdateien zerwendet und hiermit großen Unfug angerichtet.
D*B
FichtenElch
02-11-17, 16:52
Gibt es denn irgendwo eine gute Erklärung dazu? Ich würde das ja gern richtig verstehen.
Das sind eher Dokumentationen aus den 80ern, ob es diese heute noch gibt?
Außerdem ist die AS/400 schon immer ein objektorientiertes System gewesen und kennt eben auch viele Objekttypen mit diversen Methoden und Eigenschaften.
Handbücher, hauptsächlich Englisch, findest du hier:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/pdftable/pdftable.htm
Welches da nun das Richtige ist kann ich dir auch nicht sagen.
Bibliothek/Datei/Teildatei kannst du dir in etwa so vorstellen wie Oberordner/Unterordner/Datei auf anderen Systemen oder im IFS, wobei alle Teildateien innerhalb einer Datei denselben Aufbau besitzen.
RobertMack
03-11-17, 08:57
Für's Kopfkino:
Ein Topf (eine Datei) hat eine Beschreibung (DDS).
Neun andere Töpfe haben die gleiche Beschreibung.
Also verzichtet man auf neun weitere Beschreibungen und stellt die Töpfe einfach übereinander (Teildateien)
Mit OVRDBF schaut man in den gewünschten Topf im Stapel...
Eine Datei hat keine DDS (Data Definition Source)!
Die DDS ist nur eine Quelle (wie SQL-DDL, Data Definition Language) zur Erstellung derselben.
Anschließend sind weder DDS noch DDL erforderlich, da die Beschreibung (DSPFFD) alles mitbringt.
Beim Erstellen einer Datei/Tabelle werden dann die fertigen Definitionen entnommen und in das Systemrepository (QAO...) übernommen.
Die SQL-Tabellen (Syscolumns, ...) verweisen nur auf dieses Systemrepository.
Und wenn man mit SQL arbeitet so sollte man tunlichst Teildateien (Member) vermeiden, denn gerade bei OVRDBF im Zusammenhang mit offenen Pfaden (ODP's) und Cursorn hat man schnell noch die falsche Teildatei im Zugriff.
Hier bietet sich allenfalls noch ein Create Alias an, der auf eine Teildatei verweist.
Auch das Konzept LF mit allen Teildateien geht häufig schief, da dies zum Erstellzeitpunkt zieht. Kommt eine neue Teildatei hinzu, fehlt diese, Teildateien entfernen geht nicht, da diese ja verwendet wird.
Und zu allerletzt:
SQL-Tables können keine Teildateien haben.
RobertMack
03-11-17, 09:27
Natürlich, Baldur ;- )
Mir ging es nur um's Verständnis für das ehemalige Konzept dahinter...
<Haarspaltermode>
DDS := data description specifications
</Haarspaltermode>
wer's nicht kennt, sollte es dabei belassen, das sind - was PF und LF angeht - Altlasten, die man im Interesse der Entkoppelung von Datenbank und Anwendung möglichst schnell überwinden sollte.
D*B
holgerscherer
03-11-17, 10:17
wer's nicht kennt, sollte es dabei belassen, das sind - was PF und LF angeht - Altlasten, die man im Interesse der Entkoppelung von Datenbank und Anwendung möglichst schnell überwinden sollte.
Dieter, ich würde das auch nicht mehr so hart mit den Altlasten formulieren, seit dem man in der PC-Welt Key/Value als "ganz neue, moderne" Alternative zu SQL entdeckt hat ;-)
-h