Funktionsfehler X'1720' in Maschineninstruktion.

[Fuerchau]

Wobei mir der Sinn dieser Abfrage vollkommen entgeht:

VO1034 = ' ' oder '1' ... '9'
oder
VO1034 <> ' ' und <> '1' ... '9'

Und da fragt man sich anschließend, wo die Performance belibt .

Ich weiß, mit dem Fehler hat das nichts zu tun.

[Robi]

Ne, nicht mt dem Fehler, aber mit dem Generator.

Das ist der 'akzeptable' Nachteil wenn hochflexieble Standard Software aus einem Generator fällt.

Hier:
Der User kann in einem Satzauswahl-Fenster bestimmen welchen Status er sehen will

'Status ' ' anzeigen J/N'
'Status '0' anzeigen J/N'
...

Ob eine Statusfrage da ist oder nicht ist abh. vom Pgm

Fehlt jetzt, warum auch immer, eine Frage zu einem existierenden Status, so soll dieser Satz auf jeden Fall angezeigt werden, damit der Satz nicht unter geht.
Daher diese generierte Selektion.

Performance ist übrigens ok

Gruß
Robi

[Robi]

IBM hat mir grade mitgeteilt, das sie ohne Softwarevertrag keine Fehlermeldungen annehmen.

Das sie mir nur kostenpflichtig helfen, wenn ich zu blöd bin, wuste ich. Das Sie ihre eigenen Fehler nur aufnehmen/beseitigen wenn ich dafür zahle wuste ich nicht.

Das wars also mit diesem Fehler.
Ich hoffe das jemend mit SW-Vertrag bald dieses Problem hat.
Ptf's bekomm ich ja.

Ob ich das wohl nicht begreife ?

Robi

[Fuerchau]

Blöde Frage, aber kannst du den Optimze mal weglassen ?

Wenn du das Statement preparest, killst du das auch ggf. vorher mit "Drop Statement" ?
Bist du sicher dass der Cursor auch tatsächlich geschlossen ist (nicht der ODP) ?

Kannst du die wechselnden OrderBy's mal mittels STRSQL testen ?

Dynamische SQL's sind meist dann problematisch, wenn mit den Ressourcen etwas schludrig umgegangen wird.

[Robi]

Habe den optimize mit debug entfernt
Gleiche Fehler
drop ist nicht drin, aber close cursor

Wenn ich den Index wechsel geht es.
Wenn ich zurück auf den defekten index wechsel, geht es dann auch.
Speicher ich den 2. Index, so geht dieser nicht. der wechsel auf den 1. geht dann aber.
Sch...


ach so,
interaktiv (STRSQL) geht alles
Danke
Robi

[Fuerchau]

Ich lese "defekter Index", was ist damit gemeint bzw. kann man den nicht entfernen bzw. neu aufbauen ?

[Robi]

nein nicht SO defekt
Damit mein ich den order by, der hier grade eingestellt ist und der dann nicht geht (beim 1. Versuch) wie gesagt, Wechsel ich auf einen anderen Index und dann zurück ist alles OK

[Robi]

Just for Info..
hab das Fix Central grade nach fehlenden PTF's suchen lassen und diese installiert. (der Fehler nervte langsam)

uns siehe da ... Fehler beseitigt !!


Gruß
Robi

[holgerscherer]

Ob ich das wohl nicht begreife ?

Robi

Ruf mal bei Microsoft an ohne Software-Support-Vertrag ;-) Konnte mich bisher nicht beklagen. MIT SoftwareMaintenance hilft die IBM sogar bei den blödesten Fragen...

-h

[Robi]

Sch...
mein letzter Post war leider eine Falschmeldung.

In der Ursprünglich betroffenen Anzeige ist der Fehler weg,
es gib aber andere Anzeigen die diesen Fehler erzeugen.

Da wir als SW Haus nur 1 Subfile haben, das sich die anzuzeigenden Daten von den Leseprogramme geben lässt und da die Leseprogramme (seit Jahren fehlerfrei) aus einem Generator fallen habe ich nun eine "Black Box". Wenn ich Glück habe tritt der Fehler nicht auf, wenn nicht bekomme ich (zunächst) keine Daten.

Es scheint mit den Daten und der gerade eingestellten Selektion zu tun zu haben. Auch ist es bisher immer ein 'erste Aufruf' Problem. Wechsel ich die Anzeige (Sort oder Selektion) und kehre anschl. auf den Ursprung zurück ist alles ok.
Da werde ich wohl weiter auf PTF's hoffen müssen.

Gruß
Robi

[dholtmann]

Hallo Zusammen,
auch wenn 5 Jahre später, ich bekomme einen ähnlichen Fehler.
Funktionsfehler X'1720' in Maschineninstruktion.

Vor dem Fehler findet sich im Joblog aber zusätzlich:
Nachricht . . . : Genauigkeit des Zwischenergebnisses liegt unter der des
abgeleiteten Felds DF0014.
Ursache . . . . : Die Ableitung aus Operator X'07', Operand *N und Operand
100 weist weniger Dezimalstellen für das Zwischenergebnis als für die
Felddefinition für das Endergebnis auf. Das Endergebnis ist nicht so genau,
wie die Dezimalstellen andeuten. Die Ableitung geht aus Eintragsnummer 4 für
das abgeleitete Feld DF0014 in Abfrageformat ZZ20802 hervor. Ist ein
Operand *N, wurde dieser entweder aus früheren Operationen abgeleitet, oder
der Operator erfordert keine zwei Operanden.

Ist es möglich herzuleiten welches Feld mit DF0014 gemeint ist?

[BenderD]

grundsätzlich
ja