Cpyf und alternativer Tabellenname

[Joe]

Hallo Forum.

Ich möchte eine Tabelle mit neuem Namen in die gleiche Bibliothek kopieren. Die Tabelle wurde mit Create Table erstellt
und hat einen Namen > 10 Stellen.

Name: ScannerRueckmeldung
Von AS400 vergeben: SCANN00001


Beim CPYF muss ich mit dem von der AS400 erzeugten Namen (SCANN00001) arbeiten.
Wie ändere ich dabei gleichzeitig den Alternativen Tabellennamen (Originalname aus Craete Table) ?

Gruß Joe

[Fuerchau]

Die Frage verstehe ich so nicht ganz.
Die Tabelle/PF wird mit dem Namen erstellt, der beim CPYF angegeben wird.
Einen alternativen SQL-Namen gibt es dabei nicht.

Ggf. kannst du das ja auch per SQL erledigen:

create table as
select ....

[Joe]

Die Frage verstehe ich so nicht ganz.
Die Tabelle/PF wird mit dem Namen erstellt, der beim CPYF angegeben wird.
Einen alternativen SQL-Namen gibt es dabei nicht.

Ggf. kannst du das ja auch per SQL erledigen:

create table as
select ....

Hallo.

Danke für die schnelle Antwort.
Hier nochmal die Copy Parameter:

Datei kopieren (CPYF)



Ausgangsdatei . . . . . . . . . > SCANN00001
Bibliothek . . . . . . . . . . > test
Zieldatei . . . . . . . . . . . > SCANN00002
Bibliothek . . . . . . . . . . > test
Von Teildatei . . . . . . . . . *FIRST
Nach Teildatei oder Kennsatz . .*FIRST
Sätze ersetzen od. hinzufügen . > *ADD
Datei erstellen . . . . . . . . > *YES

Fehler: CPF327E Alternativer Name für Datei SCANN00002 nicht zulässig.

Als Ausgangs-u.Zieldatei muss ich den obigen Namen verwenden. Oder habe ich die Möglichkeit, hier den langen Originalnamen einzugeben?

Oder geht das mit einem anderen Befehl (ausser SQL)

Gruß
Joe

[Fuerchau]

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

[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

[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

[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.