ALCOBJ und DDM File

[Robi]

Hi, all

Ich muß eine Datei von einer AS auf eine 2. copieren. Vorher verhindern daß sie in diser kurzen Zeitspanne benutzt wird, anschließend clearen.
also : crtddmf
alcobj DDMF *excl
cpyf DDMF --> PF
clrpfm DDMF
dlcobj DDMF
dltf DDMF

Der clrpfm bricht ab, da die Datei von einem anderen Job benutzt wird.
Laut wrkobjlck ist das im SBS QSYSWRK der Job QRMTSVR von QUSER.
Dieser Job ist zeitgleich mit dem CPYF gestartet.
Ich finde ihn n i c h t mit Wrkactjob !!
Die Datei ist erst wieder benutzbar, wenn ich den Job abgebrochen habe.
Lass ich den ALCOBJ weg, geht alles.
- was mach ich falsch ?
- was ist das für ein Job

Danke Robi

[Dieser Beitrag wurde von Robi am 19. Mai 2003 editiert.]

[RobertMack]

Hallo Robi,

versuche mal den DLCOBJ vor dem CLRPFM.

Viel Erfolg,

Robert

[Dieser Beitrag wurde von RobertMack am 19. Mai 2003 editiert.]

[horschma]

Hallo,
ich kenne ein ähnliches Problem von den QZDASOINIT Jobs. Wie auch der QRWTSVR sind das Prestarted Jobs die je nach Konfiguration recycled und wiederverwendet werden. Leider hat die IBM vergessen die offenen Cursor dieser Prestarted-Jobs zu schließen und damit bleiben dann die Dateien gesperrt.
Abhilfe bringt hier nur mit CHGPJE den Wert MAXUSE auf 1 zu setzen. Damit werden die Jobs nach jeder Verwendung beendet.

hth
Thomas

[Robi]

Hallo Robert,
der DCL vor dem CLR geht dabei entsteht aber leider ein kurzes Time-Lag. das ist nicht so schön.

Hallo Horschma,
ich kann mit 'vorgestarteten Jobs' nicht viel anfangen. Was ist das, wofür brauche ich/kann ich das verwenden ?
Wenn ich CHGPJE eingebe muß ich ein Programm benennen. Ist das der letzte Eintrag des DSPJOBSTK ?

Danke Robi

[Dieser Beitrag wurde von Robi am 20. Mai 2003 editiert.]

[horschma]

Hallo,
ich hab den Ablauf mal nachvollzogen, es liegt nicht an der Verwendung der Prestarted-Jobs.
Allerdings funktioniert der Ablauf bei mir einwandfrei, auch mit dem DLCOBJ nach dem CLRPFM. ( Anmrk. ich verwende DDM über *IP )
Setzt du die Befehle nacheinander von der gleichen Sitzung oder in einem CL ab?

Thomas

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von Robi:
Hallo Robert,
der DCL vor dem CLR geht dabei entsteht aber leider ein kurzes Time-Lag. das ist nicht so schön.

Hallo Horschma,
ich kann mit 'vorgestarteten Jobs' nicht viel anfangen. Was ist das, wofür brauche ich/kann ich das verwenden ?
Wenn ich CHGPJE eingebe muß ich ein Programm benennen. Ist das der letzte Eintrag des DSPJOBSTK ?

Danke Robi

[Dieser Beitrag wurde von Robi am 20. Mai 2003 editiert.][/quote]

[Robi]

Hallo Horschma,
Ich verwende V5r1, DDM über IP, aufruf in einem CL, vielleicht noch interessant : Die Datei die ich 'hole ' wird Remote auf eine Backup-as400 journalisiert(also insgesammt 3 AS beteiligt)
noch ne Idee ?
Danke Robi

[horschma]

Hallo Robbi,

wenn du den QRWTSRVR Job auf dem Zielsystem mit WRKACTJOB nicht siehst, er aber trotzdem Sperren hält, heißt das, das der PJ recycled wurde aber nicht alle Objekte freigegeben sind.

Du siehst den Job über WRKSBSJOB QSYSWRK, da hier auch alle 'nicht aktiven' PJs angezeigt werden.

Lösung 1:
wie schon angedeutet den Wert MAXUSE für den PJ auf 1 setzen
CHGPJE SBSD(QSYSWRK) PGM(QSYS/QRWTSRVR) MAXUSE(1)
die Änderung wird erst nach einem Neustart der PJs wirksam
ENDPJ SBS(QSYSWRK) PGM(QSYS/QRWTSRVR)
und
STRPJ SBS(QSYSWRK) PGM(QSYS/QRWTSRVR)
Ob du das im laufenden Berieb machen kannst kann ich so nicht sagen.

Versuch:
vor dem CLRPFM ein zusätzliches
ALCOBJ OBJ(DDMF *FILE *EXCL) CONFLICT(*RQSRLS)
absetzen. Durch den optionalen Parameter CONFLICT(*RQSRLS) werden alle Sperren durch sogenannte 'PSEUDO_OPEN' Cursor aufgelöst.
Natürlich nachher den zusätzlichen DLCOBJ nicht vergessen.

hth
Thomas

[Robi]

Hi,
leider weiß ich zuwenig über diese Vorgestarteten Jobs. Ich weiß auch nicht was für Auswirkungen ein chg, end und str im laufenden Betrieb hätte. (auf einer Kunden-AS). Der Test bei uns war ausserdem nicht erfolgreich.
Der zusätzliche ALC mit Conflict war genauso erfolglos wie gleich der erste ALC mit Conflict.
Schade
Ich werde also das Time-Lag hinnehmen
Danke nochmal
Tschau, Robi

[Dieser Beitrag wurde von Robi am 20. Mai 2003 editiert.]

[Sven Schneider]

Versuch mal nach dem CPY den Befehl RCLDDMCNV.
Oder ganz am Anfang CHGJOB DDMCNV(*DROP).

Standardmäßig bleiben bei DDM die Verbindung und die Dateien offen.

Hinweis :
Mit deinem ALCOBJ erreichst übrigens nur, das das lokale DDM-Objekt gesperrt wird, nicht jedoch die remote PF.
Also wenn jemand die PF auf dem Zielsystem öffnet, funktioniert der CLRPFM auf die DDMF auch nicht - trotz ALCOBJ.

Am sichersten fährst du, wenn du die Kopieroperation auf dem Zielsystem ausführst und dabei deine Daten in eine temp. Tabelle kopierst. Diese kannst du dann per DDMF abholen.
Damit du das ganze synchron zu deinem Quellsystem ausführen kannst solltest du mal den CMD REXEC bzw. RUNRMTCMD probieren und damit die Prozedur auf dem Zielsystem anstossen. (vorher STRTCPSVR *REXEC auf beiden Systemen)

Sven

[Dieser Beitrag wurde von Sven Schneider am 20. Mai 2003 editiert.]

[Dieser Beitrag wurde von Sven Schneider am 20. Mai 2003 editiert.]

[Robi]

Hi Sven,
ich werde es versuchen.
Zu dem Alc
Wenn ich den ALC auf das ddm-file mache (mit *excl) bekomme ich bei einem SQL- insert eine fehlermeldung, in dfu komme ich gar nicht erst rein. Selbst ein DSPPFM geht nicht. Warum soll es nicht ausreichen den ddm file zu sperren ?
Robi


[Dieser Beitrag wurde von Robi am 21. Mai 2003 editiert.]

[Sven Schneider]

Hallo Robi,
ich nehme (fast) alles zurück.

Selbstverständlich wird beim ALC einer DDMF auch das remote Objekt zugeordnet.

Ich habe deine Prozedur ausprobiert. (mit *IP und *SNA) und konnte keine Probleme feststellen.
(OS/400 V5R1; Cum PTF TC03007; DB GRP PTF SF99501-11)

Allerdings hatte ich kein Journal auf dem PF des Zielssystems laufen. Vieleicht ist das ein Ansatz.

Sven