Cobol View und Index (V5R4)

[KingofKning]

Hallo,
ich verarbeite in meinem Cobol Programm eine View. Jedesmal wenn die View geöffnet wird, sagt er mir das ein Zugriffspfad aufgebaut wird.
Im Joblog macht er auch den Hinweis wie ein Index aussehen soll. Ich habe mit create index nach Angaben des Joblogs den Index erstellt.
Trotzdem bekomme ich immer noch den Hinweis das der Zugriffspfad erstellt wird.

Da die Datei naturgemäß sequentiell ist kann ich ja nur durch ein Close und Open wieder auf den Anfang setzen.

Was für Möglichkeiten habe ich das die Kiste den Index benutzt?

GG

[B.Hauser]

1. Wenn die Reihenfolge egal ist und Du außerdem native I/O verwendest, können Dir die Indices egal sein. Indices werden von SQL verwendet um möglichst rasch auf die gewünschten Daten zugreifen zu können. Bei einem Mix aus SQL und Native I/O insbesondere noch unter Release V5R4 können schon mal Indices vorgeschlagen werden, die dann nicht oder vielleicht auch nur von dem Statistics Manager verwendet werden. Vermutlich wird zu dem noch die alte CQE (Classic Query Engine) verwendet.
2. Da eine View nie einen Schlüssel hat, muss natürlich zur Laufzeit ein Zugriffspfad aufgebaut werden. Die Reihenfolge der View ist nicht zwangsläufig sequentiell, sondern in der Reihenfolge des/der verwendeten Zugriffspfade.
3. Weißt Du eigentlich, dass man SQL Indices zwar nicht direkt mit SQL ansprechen, wohl aber mit native I/O wie ganz normale geschlüsselte logische Dateien verwenden kann. Ggf. genügt in Deinem Fall ein Index.
4. Mir ist absolut schleierhaft, warum Du mit Gewalt versuchst eine View mit native I/O zu verarbeiten anstatt embedded SQL zu verwenden.

Ohne die View bzw. das SELECT-Statement, das sich hinter der View verbirgt zu kennen, kann man an dieser Stelle jedoch keine weiteren Aussagen machen oder Empfehlungen aussprechen.

Birgitta

[KingofKning]

Du weißt doch, Was der Bauer nicht kennt....
Aber Spaß beiseite, da ich ein wenig unter Zeitdruck stehe, wollte ich jetzt nicht noch Stunden in die Einarbeitung von SQL in Kombination mit Cobol verschwenden.
Selbst die diese dämliche Dec nach Hex Konvertierung hat mich ja ne Menge Zeit gekostet, nur weil ich nicht wußte das die Variable als S9 und nicht nur als 9 definiert werden mußte.

Aber ich kann mir vorstellen das wenn das mal läuft ne Schicke Sache ist.

GG

[KingofKning]

Hier mal die View:
create view rptrade/dat008 as select soid1, soid2, sodnbi,
soid4, soeipr, sosa16, soeip2
from xxx01pf
where sofa = 1
and sosts = 0
and soabkz = 0
and sojhvo = 1
and soeipr > 0
and (sodnbi >= YEAR(CURRENT DATE)*10000 +
MONTH(CURRENT DATE)*100 +
DAY(CURRENT DATE))
group by soid1, soid2, sodnbi, soid4, soeipr, sosa16, soeip2

Und hier der Index:
create index xxxkey on xxx01pf
(SOFA, SOSTS, SOABKZ, SOJHVO, SOEIPR)

Wenn ich die Sätze durchlese, bekomme ich sie ja schon sortiert

GG

[Fuerchau]

Alternativ: lege noch mal einen Index über die Group-By Felder an.
SQL geht immer davon aus, dass auch mit SQL gearbeitet wird.
Beim Open mit Native-IO werden da Mechanismen übergangen, welche da schweigt sich SQL aus.

Gibt es einen Grund für "Group by"?
Immerhin verwendest du keine Aggregate wie SUM/AVG...

Hier hilft ggf. ein "select distinct ..." ohne "Group By".

[B.Hauser]

Besser als ein zusätzlicher Index wäre den vorhanden Index um die Group By-Felder in der angegebenen Reihenfolge zu erweitern. SQL hat zwar Methoden um für die gleiche Tabelle in der gleichen Abfrage mehrere Indices zu verwenden (Index-ANDing/Index-ORing), ob diese Methoden allerdings bei Verwendung mit native I/O ziehen ist fraglich.

SELECT DISTINCT und GROUP BY Ohne Aggregat-Funktionen werden von SQL gleich behandelt.

Birgitta

[KingofKning]

Das schöne ist, ich habe bei der Durchsicht alter Sourcen festgestellt das ich 2002 schon SQL in Cobol verwendet hatte.

Wußte gar nicht das Alzheimer schon bei 50jährigen einsetzt.

Gerade bei Software die offensichtlich historisch gewachsen ist und wo Felder für beliebige Inhalte benutzt werden ist SQL flexibler.

Ich wünsche mir die Zeiten zurück als noch wirklich sauber gearbeitet wurde.

GG