Error: Attempt to modify outside transaction 2

[jamcan2]

I have created a program using MIMS Cobol subroutines. The program compiles successfully and executes through to EXEC REMOVE-REQUEST END-EXEC, which is meant to update MSF080, at this point the program fails with the display "Attempt to modify outside transaction" and an Abend code of 4095.

The program also executes a browse of MSF180 & MSF170 that don't return any results. When I run the same queries in SQL
I do get results.

I feel I may be missing something basic in the program set up.

Do you have any suggestions?

 

[jamcan2]

The error is due to EXEC ENDTRN END-EXEC before EXEC REMOVE-REQUEST END-EXEC.

Problems with BROWSE using the DB-IO Macro resulted from the WHERE, SELECTIF & REJECTIF statements not being coded correctly.

I have an old MOMS COBOL Manual, but its explanations and examples are very limitted.

Can anyone suggest a good reference guide / support site for MIMS COBOL?

 

[AddOns1]

jamcan2,

I don't know of any 'good' reference guide out there, and I've been supporting it for 14+ years now.

Jeff

 

[Glen]

jamcan2,

If you work back into the problem from what a transaction is, how it is delimited, and how Mincom programs work you may see the solution here.

First, a transaction is a logical unit of work that can be either committed or rolled back if errors are encountered.

Updates are only allowed within a transaction.

Before any update can happen, the program needs to have issued a START-TRAN.

If an END-TRAN has been executed, another START_TRAN needs to be executed before you can make an update.

These rules apply to updating any of the MIMS tables, including the MSF080 table with the request information. So then, when a MIMS program runs, the first thing is does is update its own MSF080 record to change the process status. This requires a START-TRAN, UPDATE MSF080, and then - to make the change 'stick' the update of the 080 record is comitted by executing an END-TRAN. This is managed by the Mincom macros and may not be visible to the Cobol programmer.

Now, we are ready for the program to do its work. However, MIMS is generally smart enough to not tie up the system with 'intent to update' until it decides to do an update. If nothing if found to change, no transaction is started. If changes are to be made, a START-TRAN is executed and the updates are allowed.

Once the program is complete, the MSF080 record for the run needs to be deleted. This needs to be within a transaction. If the program has not found any records to update, a START-TRAN may not have been executed, so your delete attempt is 'outside of a transaction.'

You need to check to see if you are in a transaction, and if not, execute a START-TRAN before calling REMOVE-REQUEST. Look in other MIMS programs for examples of doing this.

The other problem that you mention about MIMS not returning rows.... The MIMS Macros are not SQL. You must access the data elements in the exact order that is specified in the MIMS macro with all key elements provided in the DB-IO call.

There is a Mincom publication that outlines the use of the MIMS Macros. We used to have a copy for new programmers to reference, but I can't find it in our current Infopac. You may want to see if some other client has a current copy.

Glen

Glen Colbert
gcolbert@rag-american.com