Cpyf und alternativer Tabellenname

[Joe]

Schau dir die Nachricht mit F1 mal genauer an. Es gibt da detailiertere Hinweise.

Das habe ich schon mehrfach getan, deshalb ja meine Anfrage hier im Forum.

F1-Fehlerbeseitigung:

2 - Den alternativen oder den Bibliotheksnamen im Befehl so ändern, dass der alternative Name keine Kopie des alternativen Namens einer anderen Datei ist.

Das interpretiere ich so, dass der Name ScannerRueckmeldung als alternativer Name bezeichnet wird. Dieser Name ist auch z.B. in der SYSTABLES vorhanden und kann nicht doppelt vorkommen.

Stehe ich etwa total auf dem Schlauch?

Gruß Joe

[BenderD]

Hallo,

bei SQL Langnamen werden vom System bei Bedarf Kurznamen generiert, nach dem Regelwerk Name = XXXXXyyyyy
wobei XXXXX die ersten 5 Buchstaben des Langnamens in upper Case sind und yyyyy eine fortlaufende Nummer, startend mit 00001
In deinem Fall sieht es so aus, dass es bereits eine Datei mit dem Namen SCANN00002 gibt, oder das OS wieder mal spinnt.
Fazit: SQL nehmen und Langnamen verwenden, oder CPYF und anderen Namen wählen.

mfg

Dieter Bender

Das habe ich schon mehrfach getan, deshalb ja meine Anfrage hier im Forum.

F1-Fehlerbeseitigung:

2 - Den alternativen oder den Bibliotheksnamen im Befehl so ändern, dass der alternative Name keine Kopie des alternativen Namens einer anderen Datei ist.

Das interpretiere ich so, dass der Name ScannerRueckmeldung als alternativer Name bezeichnet wird. Dieser Name ist auch z.B. in der SYSTABLES vorhanden und kann nicht doppelt vorkommen.

Stehe ich etwa total auf dem Schlauch?

Gruß Joe

[kuempi von stein]

...In deinem Fall sieht es so aus, dass es bereits eine Datei mit dem Namen SCANN00002 gibt, oder das OS wieder mal spinnt.

Hello,

wenn er denn nun wirklich den Ursachencode 2 hat.
2 - Der alternative Name ist ein doppelter alternativer Name für die
Datenbankdatei &5, die bereits in der Bibliothek &2 vorhanden ist.

Steht ja dann so im Joblog!?

k.

[Joe]

Hello,

wenn er denn nun wirklich den Ursachencode 2 hat.
2 - Der alternative Name ist ein doppelter alternativer Name für die
Datenbankdatei &5, die bereits in der Bibliothek &2 vorhanden ist.

Steht ja dann so im Joblog!?

k.

Hallo.
Danke für die rege (An)Teilnahme.


Der neue Name SCANN00002 existiert definitiv nicht im gesamten System.

Hier nochmal die Fehlermeldung:

Nachricht . . . : Alternativer Name für Datei SCANN00002 nicht zulässig. Ursache . . . . : Es wurde versucht, die Datenbankdatei SCANN00002 mit dem alternativen Namen SCANNERRUECKMELDUNG zu erstellen, zu ändern oder in die
Bibliothek xxx zu übertragen.


Ich werde das Kopieren der Tabelle mit SQL durchführen.

Gruß
Joe

[BenderD]

Hallo,

Wieso nochmal? ein typisches Beispiel dafür, dass eine klarere Problembeschreibung direkt zur Lösung geführt hätte.

mfg

Dieter Bender

@Baldur: Solange mir keiner dokumentiert zeigt, dass das ein Feature ist, ist das für mich ein Bug!!!

Hier nochmal die Fehlermeldung:

Nachricht . . . : Alternativer Name für Datei SCANN00002 nicht zulässig. Ursache . . . . : Es wurde versucht, die Datenbankdatei SCANN00002 mit dem alternativen Namen SCANNERRUECKMELDUNG zu erstellen, zu ändern oder in die
Bibliothek xxx zu übertragen.

[Fuerchau]

Da native OS-CMD's nur 10-stellige Objektnamen kennen, kann auch nur mit 10-stelligen Namen umgegangen werden.

Da der ALIAS der Datei länger als 10 ist, kann sich das OS keinen Namen "ausdenken", da der Benutzer ja die Namen vorgibt.
Wo soll also CPYF einen langen Namen generieren, wenn doch normalerweise die Kopie ein weitgehend identisches Objekt ergibt ?
Deshalb wird der CPYF abgelehnt und man muss dann halt den "Create as Select" verwenden.
Hier gilt wieder die SQL-Konvention, die aus dem langen Namen wieder einen 10-stelligen Objektnamen generiert.

Es ist ist halt schon ein Problem, mit verschieden Methoden das selbe Objekt zu bearbeiten.

Dies gilt übrigens auch für TABLE/VIEW/INDEX-Objekte, die ich anschließend mit RecordLevel-Access verarbeiten will, wo diese Arten doch für SQL vorgesehen sind.

"Es geht doch" ist für mich in diesem Fall kein Argument.

[BenderD]

Hallo,

jede PF hat einen 10 stelligen Namen und wenn ich einen CPYF mache gebe ich selbigen als Quelldatei an und als Zieldatei ebenfalls einen, der maximal 10 stellig ist, da gibt es keinerlei Grund einen Langnamen zu erfinden, nur weil die Quelldatei zufällig einen hatte!!!

mfg

Dieter Bender

Da native OS-CMD's nur 10-stellige Objektnamen kennen, kann auch nur mit 10-stelligen Namen umgegangen werden.

Da der ALIAS der Datei länger als 10 ist, kann sich das OS keinen Namen "ausdenken", da der Benutzer ja die Namen vorgibt.
Wo soll also CPYF einen langen Namen generieren, wenn doch normalerweise die Kopie ein weitgehend identisches Objekt ergibt ?
Deshalb wird der CPYF abgelehnt und man muss dann halt den "Create as Select" verwenden.
Hier gilt wieder die SQL-Konvention, die aus dem langen Namen wieder einen 10-stelligen Objektnamen generiert.

Es ist ist halt schon ein Problem, mit verschieden Methoden das selbe Objekt zu bearbeiten.

Dies gilt übrigens auch für TABLE/VIEW/INDEX-Objekte, die ich anschließend mit RecordLevel-Access verarbeiten will, wo diese Arten doch für SQL vorgesehen sind.

"Es geht doch" ist für mich in diesem Fall kein Argument.

[Fuerchau]

Dieter, da gehe nicht ganz mit dir überein.
Der lange Name ist nun Bestandteil des Dateiobjektes (sonst könnte Save/Restore) nicht funktionieren.
CRTDUPOBJ kann das im Übrigen auch nicht.

Die Erklärung liefert übrigens der CPYF gleich mit:

Datei erstellen (CRTFILE) - Hilfetext

Gibt an, wann dieser Befehl zum Kopieren von einer physischen oder
logischen Datei benutzt wird, und ob eine physische Datei erstellt wird,
um die Daten zu empfangen, wenn die angegebene Nach-Datei nicht
vorhanden ist. Ist die Nach-Datei eine DDM-Datei (Management für
verteilte Daten), die eine nicht vorhandene ferne Datei kennzeichnet,
wird die Nach-Datei auf dem Zielsystem erstellt.

*NO
Beim Starten des Befehls muss die Zieldatei bereits vorhanden sein.
Eine physische Datei zum Empfangen der Daten wird nicht erstellt.

*YES
Ist die Zieldatei nicht vorhanden, wird eine physische Datei mit dem
bei Parameter Zieldatei (TOFILE) angegebenen Namen erstellt. Ist die
Ausgangsdatei eine SQL-Tabelle, eine SQL-Sicht oder ein SQL-Index
mit einem Feld der Art benutzerdefiniert, DataLink oder LOB (Large
Object), wird eine physische Datei erstellt, die eine SQL-Tabelle
ist. In allen anderen Fällen wird als Zieldatei eine physische
Datenbankdatei erstellt, die keine SQL-Tabelle ist. Neben den
normalen Gültigkeitsprüfungen beim Kopieren müssen folgende
Sonderbedingungen beim Kopiervorgang zum Erstellen einer Zieldatei
erfüllt sein:

[BenderD]

also ich kann da nirgends eine Einschränkung entdecken, warum das nicht gehen soll und von Langnamen oder ähnlichem steht da ebenfalls nix...

Dieter, da gehe nicht ganz mit dir überein.
Der lange Name ist nun Bestandteil des Dateiobjektes (sonst könnte Save/Restore) nicht funktionieren.
CRTDUPOBJ kann das im Übrigen auch nicht.

Die Erklärung liefert übrigens der CPYF gleich mit:

Datei erstellen (CRTFILE) - Hilfetext

Gibt an, wann dieser Befehl zum Kopieren von einer physischen oder
logischen Datei benutzt wird, und ob eine physische Datei erstellt wird,
um die Daten zu empfangen, wenn die angegebene Nach-Datei nicht
vorhanden ist. Ist die Nach-Datei eine DDM-Datei (Management für
verteilte Daten), die eine nicht vorhandene ferne Datei kennzeichnet,
wird die Nach-Datei auf dem Zielsystem erstellt.

*NO
Beim Starten des Befehls muss die Zieldatei bereits vorhanden sein.
Eine physische Datei zum Empfangen der Daten wird nicht erstellt.

*YES
Ist die Zieldatei nicht vorhanden, wird eine physische Datei mit dem
bei Parameter Zieldatei (TOFILE) angegebenen Namen erstellt. Ist die
Ausgangsdatei eine SQL-Tabelle, eine SQL-Sicht oder ein SQL-Index
mit einem Feld der Art benutzerdefiniert, DataLink oder LOB (Large
Object), wird eine physische Datei erstellt, die eine SQL-Tabelle
ist. In allen anderen Fällen wird als Zieldatei eine physische
Datenbankdatei erstellt, die keine SQL-Tabelle ist. Neben den
normalen Gültigkeitsprüfungen beim Kopieren müssen folgende
Sonderbedingungen beim Kopiervorgang zum Erstellen einer Zieldatei
erfüllt sein:

[Fuerchau]

Naja, lange Rede kurzer Sinn (auch wenns nicht da explizit steht) werden sämtliche Aliase mit kopiert und beim Alias des Dateinamen scheitert das System.
Vorschrift ist hier halt: kopiere mit SQL.

Es gibt leider nur eine Regel, wie lange Namen in kurze übersetzt werden und nicht wie vorhandene lange Namen ggf. vom System umbenannt werden sollen.

[Joe]

Hallo,

Wieso nochmal? ein typisches Beispiel dafür, dass eine klarere Problembeschreibung direkt zur Lösung geführt hätte.

mfg

Dieter Bender

@Baldur: Solange mir keiner dokumentiert zeigt, dass das ein Feature ist, ist das für mich ein Bug!!!

Sorry, ich war der Meinung mein Problem ausführlich genug beschrieben zu haben.

Nochmal vielen Dank für die Problemlösung.

Gruß

Joe

[Fuerchau]

Dies ist kein BUG sondern leider so korrekt.
Der CPYF kommt mit langen Namen nicht zurecht, da diese immer wieder mitkopiert werden.
Z.B. das DDS-Keyword ALIAS erlaubt lange Feldnamen, die beim Erstellen auch kopiert werden. Auf Feldbebene ist das aber egal.
Auf Dateiebene hat man auch keinen Einfluss auf den langen Namen und deshalb wird der CPYF abgelehnt.

Lösung:
a) CPYF in eine andere Lib, wo der lange Name nicht existiert
b) per SQL kopieren

CREATE TABLE ScannerRueckmeldung2
as (select * from ScannerRueckmeldung)
with data