Commit im CL

[mk]

Hallo zusammen,

ein Kopierjob soll unter Transaktion laufen.

Der Ablauf im CL Programm sieht so aus:

1. CPYF
2. Update mit RUNSQL

wenn der SQL fehlschlägt soll ein ROLLBACK durchgeführt werden.

Mein Programm sieht so aus

STRCMTCTL  LCKLVL(*CHG)                                   
                                                          
CPYF       FROMFILE(&FROMLIB/&FROMFILE) TOFILE(&TOFILE) + 
             MBROPT(*ADD) PRINT(*ERROR) FMTOPT(*MAP +     
             *DROP) ERRLVL(*NOMAX)                        
/* update kopiert Daten  */                               
CHGVAR     VAR(&ASQL) VALUE('update ' *BCAT &TOFILE +     
             *BCAT ' SET ...... ')     
RUNSQL     SQL(&ASQL)                                     
MONMSG     MSGID(SQL9010) EXEC(DO)                        
ROLLBACK                                                  
enddo 

Das Problem ist:
Ich schaffe es nicht das der Rollback auch die kopierten Daten zurückrollt.

Hat jemand eine Idee ?

Gruß
Michael

[Fuerchau]

Nun ja, wenn du dich an Native-IO (wie CPYF) erinnerst so musst du doch bei jeder F-Bestimmung angeben, ob du diese Datei unter Commit stellst.
Statt CPYF solltest du ebenso einen "insert into Myfile select * from Myfile2" als RUNSQL ausführen.
Der *MAP *DROP weist allerdings darauf hin, dass die Felder nicht alle namentlich passen, so musst du den Insert halt auscodieren "insert into myfile (f1, f2, ...) values(select f1, f2, ... from myfile2)".

[BenderD]

... nimm eine ordentliche Programmiersprache, wenn es schon Huddelprogrammierung sein soll, mach alles mit SQL, oder nach Altvätersitte mit Sicherungskopie.

D*B

[mk]

okay,

ich habe es befürchtet. Allerdings sind es hier ca.1300 Copies ( in unterschiedlichen Bibliotheken)
von denen der Satzaufbau zwar identisch sein sollte, aber es nicht ist.
Gruß
Michael

[BenderD]

... ich leiste zwar ungern Beihilfe zum Huddel, aber RMVJRNCHG gibt es auch noch.

D*B

[Fuerchau]

Nun, Fluch der bösen Tat, wenn man nachträglich versucht Journalisierung aufzubauen.
Dies ist halt mit etwas Aufwand verbunden...

Und RMVJRNCHG macht die Sache ja auch nicht einfacher.
Immerhin benötigt man dazu 2 RTVJRNE's um Start/Ende des CPYF festzustellen.

[BenderD]

Und RMVJRNCHG macht die Sache ja auch nicht einfacher.
Immerhin benötigt man dazu 2 RTVJRNE's um Start/Ende des CPYF festzustellen.

... keineswegs, JRN FILE und TOJOBO sollten reichen.

D*B

[Fuerchau]

Ob da für einen CPYF tatsächlich immer ein eigener Job initiiert wird?
Ich kenn da Altanwendungen, die machen das innerhalb eines Jobs durchaus mehrfach und bei 1300 dieser CPYF ist das auch durchaus wahrscheinlich.

Um es mit deinen Wort zu sagen: Das beste Konzept scheitert immer am Huddel.

Vielleicht sollte da etwas mehr Gehirnschmalz in das Bearbeiten der Quellen gesteckt werden. Schließlich könnte man qualifiziert nach den CPYF's suchen und diese durch einen generierten RUNSQL ersetzen.
Man ersetze also Huddel durch Knuddel!

[mk]

das Thema ist das der Huddel wegkommt.
Ich habe Daten pro Firma getrennt in versch.Bibliotheken und das ab 1994
für jedes jahr eine Lib z.b firma1994/datei das bis heute.
Zusätzlich natürlich alte Join Files. Davon jede Menge.
Jetzt ( 2017 ) wird das alles konsolidiert damit der Huddel eben nicht mehr vorkommt.
Da fragt man sich was die Entwickler einer Software in den Jahren so gemacht haben.
Aber wie immer:
Altlasten , Historisch gewachsen :-)
Gruß
Michael

[BenderD]

Ich kenn da Altanwendungen, die machen das innerhalb eines Jobs durchaus mehrfach und bei 1300 dieser CPYF ist das auch durchaus wahrscheinlich.

... das müsste doch "kannte" heißen : ))) , solch Programm-technisches Unkraut gehört konsequent ausgejätet!

D*B

[BenderD]

Altlasten , Historisch gewachsen :-)
Gruß
Michael

... das muss - ehrlicherweise - historisch geschrumpft heißen.

D*B