QSAM Buffer

pts.
Tags:
390
IBM DB2
Mainframe
We are writing to a QSAM output file which we will require in case of an abend. The problem we are faced with is - what happens if the job abends prior to all the records in the QSAM buffer being physically written to the QSAM output file. Are there any JCL statements that can force the QSAM buffer to be written out prior to the abend taking place. Thanks....

Answer Wiki

Thanks. We'll let you know when a new response is added.

While there are several “half way” schemes which will work occasionally, there is no way to ensure that an abend handler routine will always be called. It is not too hard to intercept application abends such as an 0C7 but system abends such as x37 are another matter entirely.

The only reliable ways to accomplish your objective are:

1) send the records to an MQ Series queue that is defined to “not roll back” messages in the event of an abend. Then have another program read those messages and write them to a QSAM file.

2) write the records to a database and issue a syncpoint after each write. Then at most the last record will be lost if an abend occurs in the process of the database write. It is fairly common to use a DB2 table (defined in a segmented tablespace) which is defined without an index for this purpose. When the program starts, it issues an unqualified DELETE to empty the table followed by a COMMIT. This DELETE takes only a small fraction of a second.

You gain a further advantage from either of these solutions. Should the batch program be running too long, such that there is a need to run multiple copies of the program in parallel; multiple instances of the program can be inserting records into either the queue or the table without contention and with full integrity.

Bill

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Anettis
    You probably need to give more details of what you are trying to, what language you are using, what might be triggering the ABEND, etc. However I was under the impression that MVS termination and recovery processing included closing open QSAM files in which case QSAM buffers should be flushed. Now If you are talking about records that you have in an internal buffer area of your program that are waiting to be written that is another matter entirely. You can setup an ESPIE (to capture standard interrupts like SOC1, SOC4, SOC7, etc.) or an ESTAE to capture other types of system errors, however this involves dropping down into assembler and using macro system services.
    0 pointsBadges:
    report
  • TwoMetreBill
    "I was under the impression that MVS termination and recovery processing included closing open QSAM files" To be a little more accurate, it would be that MVS/zOS "attempts" to flush the buffers, there are no guarantees. The same applies to writing the system exits, those will usually work. If I remember correctly Stu Hoyt put some sample code on the web a few years back about how to do this. However these solutions are only useful if you have: 1) significant assembler and systems level programming skills on staff. 2) your company allows the development of complex routines like this which might be difficult to maintain. (You might not find anyone under 60 years old who even knows how to do it.) 3) they only have to work "most" of the time. That is, it is acceptable that records will occasionally be lost. If however, you must have absolute integrity OR your company won't accept the risks of writing complex assembler code, then the database solution is your simplest option. Bill
    0 pointsBadges:
    report
  • SRovo01
    I agree with Bill, but if close is good enough, then in your JCL you can override the number of buffers for the file to one. This may have the effect of slowing your job down to a crawl, because you'll serialize on each I/O to that file, but you will probably never lose more than one record. That assumes that the reason for the abend doesn't include any sort of disk hardware failure.
    0 pointsBadges:
    report
  • Anettis
    ?To be a little more accurate, it would be that MVS/zOS "attempts" to flush the buffers, there are no guarantees.? There may be no guarantees but if the programmer in question is simply looking to make sure that their QSAM (not internal program buffers) are flushed then I think the point is mute. If a problem (hardware or software) occurs that is so sever that zOS can?t successfully close a simple QSAM file (which implies flushing the associated buffers) then one has to wonder if even an ESPIE, ESTAE, or any programming trick would still work. If instead of QSAM something like DB2 (with a syncpoint after each insert) or MQSeries was employed that might make the process a little more fortified but I am not sure it is warranted. I would run a bunch of test scenarios carefully tracking QSAM writes and then forcing various types of ABEND?s. I could be wrong but my suspicion is that you will find that zOS flushes the buffers properly each time. If on the other hand the poster is worried about writes that must still occur from a program?s internal buffer ? then this process can be fortified by setting up and ESPIE/ESTEA. If one does not want to drop down into assembler I suspect there may be a way to have LE trap the ABEND and pass control to your own recovery subroutine (although I have never looked into this from an LE point of view).
    0 pointsBadges:
    report
  • TwoMetreBill
    Setting the number of buffers to 1 means that "one block of records" will be lost, not just one record. It is also necessary to ensure that there is only one record per block. However this will only work if there are no system exits that are overriding the JCL specification. With modern storage subsystems, your JCL specification of BUFNO=1 might be ignored. Of couse this solution assumes that you don't need to examine the last record in the event of a failure to help with problem determination. You can take it a step further and issue an OPEN immediately before and a CLOSE immediately after each write. However, this will take around 1/10th to 1 second per write, depending on activity on the system. My recent client did this for an error file and when there were a large number of errors, the job went from "minutes per day" to "days per day". Lastly the error doesn't have to be catastrophic for the OS to not flush the buffers. It simply has to be a system error such as a B37 instead of an application error like a 0C7. Of course, in this case a system exit can't flush them either because "out of space" means there is no place to write the data. Bill
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following