Anonym.
Filehandling for written files during Commit.
When you do a commit in a DB2 PGM, data written to a sequential file in the same PGM may still be in the buffer (and not written to file yet).
If you ABEND in this situation, these records may be missing in the file, when you try to do a restart and read the data form the file!
To make sure buffers are written to file, it is required to close file when doing a commit (this forces buffer data to file).
Then file must be reopenden to write next records after commit.
Please let me know your understanding of the risk/possiblity of loosing file-data in this kind of situation when not doing file closing and reopening after commit.
P.S. We have no checkpoint/restart tool or product installed.
All programming required is contained in application PGM!
Hi Klaus,
I remember the early days as an application programmer. At that time IMS was the leading database system and DB2 just came up and presented itself at the "second" database.
At that time it was quite usual to implement restartable DB2 batch solutions under IMS as an BMP: Files were created as a pseudo-GSAM database and – in case of a crash – are backouted and then restarted.
At that time this method was actually state of the art. Nowadays you rarely find IMS environments and IMS skills. But as I know its still IBM’s recommended way how to implement restartable DB2 batch applications – see DB2 10 for z/OS Applications Programmers Guide.
Otherwise you should consider 3rd party tools like BMC APPLICATION RESTART CONTROL for DB2 (AR / CTL for DB2) or Softbase’s Checkpoint Facility BHC321.
Regards
Gernot
Hi Gernot,
I would love to buy 3rd party product, but I think I will not find a sponsor.
I read this discussion:
Conclusion from my understanding: If you have one record per block (may be achieved in JCL Definition of file), there should be no records in buffer that are commited by DB2.
So I will try to solve this issue by JCL definition.
regards
Klaus
Hi Klaus,
you probably will not solve the problem just by altering DCB attributes of your output files.
I would like to make following suggestion:
Create one or more DB2 tables dedicated to output processing. For example one table for each DD-name. Or one table for each unique DCB-type (e.g. OUT_FB80, OUT_VB137). Add a sequence or running number SEQNR to each table as a key field. And add a RECORD field (CHAR(80), or VARCHAR(137) ) to your table(s).
Then you should redesign your application: First do your business work and write output to that DB2 output table(s) dedicated to output processing.
Once the batch application program finaly finished work, or or finished restart processing, then it’s time to process your output tables: Develop an application program which only processes DB2 output tables. For example, to write reports or to create interface files to other IT processes.
After all your output and files have been sucessfully created, you may TRUNCATE that DB2 output tables.
This design should solve your restart/recovery problems using sequential output datasets!
Regards
Gernot
You must be logged in to reply to this topic.
