Contention when locking an on-line VSAM file using ENQ/DEQ. All users are being locked out of entire file.

We are running IBM's Check Processing Control System (CPCS) which is written in Cobol & Assembler. CPCS calls Control Machine (CTMC) which is a Conix product also written in Cobol & Assembler.  CPCS captures check data and CTMC posts, balances, etc.  These programs run as tasks in an on-line region where many users can correct captured check MIRC data and post/balance the entries.  The main module of CTMC is a COBOL program DKNCTMC which we have source code for and have added user code.  I have made changes to this module to total item counts per entry on the Interface Master file and write them to a VSAM file for use in redisplaying on the screen and reporting at end of day.  I am using ENQ/DEQ to lock my VSAM file record during reads, writes and rewrites. The ENQ/DEQ processing is not retuning any non-zero return codes and when one (1) user is in CTMC my code changes are working great.  We have even expedited the code and all appears to function correctly.  However, when multiple users are in CTMC there appears to be contention issues even though I should have the record locked for 1 user.  For example, if one user scrolls the list of enties he will see the item count totals display, if at the same time another user scrolls the list of entries, he will see zeroes.  Also, when writting or rewritting to the VSAM file which happens at posting time, if multiple users are trying to post at the same time we are getting VSAM errors even thou they are posting different entries (records).  These errors cause the data not to be written to the VSAM file.  In my sysout I see the message:  ITEMCNT WRITE/REWRITE ERROR 93;  ITEMCNT is my VSAM file DDNAME used in my display message and 93 is the VSAM file status.  Based on the VASM messages a 93 is a resource unavailable.  We took out the ENQ/DEQ code and got the same results.  So obviously the ENQ/DEQ is not doing its job. The VSAM file is defined as KSDS with a key of 17, share options (2,3) reuse (No).  Since only 1 person can expedite at a time, we can not recreate the contention where we can view the exact sequence of events.  We have used the ENQ/DEQ in other programs successfully, why it is not working in DKNCTMC is unknown.

Please advise - Is there a better way to test or a better method to lock the records.  What we want is for users to be able to read/display information to the screen with no contention - if one record is locked for update, skip over it and display the rest and keep going without abending.  And for users to be able to lock different records for update at the same time.  If the record is locked and a user displays a list, again skip the locked record and get the rest without abending. If a user tries to lock a record already locked - send them a record in use message.


Software/Hardware used:
IBM Mainframe

Answer Wiki

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

I would look at the File-Control “of the INPUT-OUTPUT” Section of the COBOL program, looking for how record locking is handled.

Discuss This Question: 1  Reply

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.
  • Meandyou
    You say "on-line region" - does this mean CICS? If yes, then why wouldn't you let CICS handle the locking instead of coding ENQ/DEQ. You are checking the VSAM file-status - so this is not CICS? Have you checked the DISP on your DD cards? Is it DISP=SHR? The second user sees zeroes. This sounds as if you are not checking that the READ was successful and the program is displaying the program default. This is an IBM product? I would open an ETR with them. Not much help I'm afraid.
    5,220 pointsBadges:

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.

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


Share this item with your network: