IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

A004 CATASTROPHIC ERROR IN MODULE - A140 0A 13BA


IBM Mainframe Forums -> ABENDS & Debugging
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
samrakesh

New User


Joined: 01 Sep 2006
Posts: 6
Location: Norwich, UK

PostPosted: Wed Aug 04, 2010 5:17 pm
Reply with quote

Hi,

I'm facing this error in one of my Easytrieve programs. The basic processing of the program is sorting into a Virtual file, and then summing up one value for all the records. A return code is set based on the summed up value. The version of Easytrieve used is Easytrieve Plus 6.4 on the Mainframe.

There is very little information available about this error on the web, and the only reason I can think of is not enough Virtual space available for Easytrieve. I have overridden my EZTVFM file as below, but it still fails with the same error.

//EZTVFM DD UNIT=SYSDA,
// SPACE=(CYL,(4369,6000),RLSE)

Any ideas how this error can be fixed? Any help will be much appreciated.

Thanks,
Sam
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Wed Aug 04, 2010 5:23 pm
Reply with quote

What do you mean by a "Virtual file". From the snippet posted I would hazard a guess at a TEMPORARY file rather than a VIO file.
Please use the correct terminology when posting an issue.

Also, the OUTPUT tells a whole lot more than the input or nothing. Please post the output and any associated error codes along with the messages issued.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Wed Aug 04, 2010 5:27 pm
Reply with quote

After 12 seconds on google, so I'm not sure on what you searched for.
Quote:
Q: I receive the message: A004 CATASTROPHIC ERROR IN MODULE A140 04 136E. What would cause this error?


A: This is an indication that the EZTVFM file is out of space. Increase the EZTVFM space in the JCL. VFM space can not span packs. If more space is needed you will need to use WORK files. Using report WORK files means that spooling is done to the respective WORK file, not to the EZTVFM. For more information about EZTVFM, see Chapter 3 of the CA-Easytrieve Plus Installation Guide, refer to topic "OS/390 Operating System". For information on how to setup WORK files, see Chapter 11 of the CA-Easytrieve Plus Reference Guide, refer to topic "Report Work Files."

As usual the "Moderators Librarian Service" delivers again icon_rolleyes.gif
Back to top
View user's profile Send private message
samrakesh

New User


Joined: 01 Sep 2006
Posts: 6
Location: Norwich, UK

PostPosted: Wed Aug 04, 2010 5:38 pm
Reply with quote

Thanks for the reply, Expat. I found the solution you posted before ages ago. As mentioned previously, my declaration for EZTVFM file is already pretty high (CYL,(4369,6000),RLSE). I have also tried with (CYL,(4369,16000),RLSE) which also failed.

The above solution mentions the use of WORK files, and says we need to refer to Chapter 11 of the Reference guide. I could not find anything in Chapter 11 of the Reference guide about adding WORK files. I tried adding additional sort work files (SORTWKnn files), which did not work.

Secondly, when I said Virtual file, I meant a FILE VIRT1 F(264) VIRTUAL in Easytrieve. I thought this was the correct terminology. Correct me if I am wrong.

Thirdly, there is no output file. As I mentioned previously, a return code of 1 or 2 is set based on the summed up value. The next step uses this return code for further processing. The error message displayed is exactly the one in the Subject of this post.

Again, any ideas will be appreciated.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Wed Aug 04, 2010 7:23 pm
Reply with quote

The EZTVFM dd statement is as far as i remember used for compiling (and go) Easytrev programs.

For using VIRTUAL in file definition statements, try giving LRECL and BLOCKSIZE parameters :

FILE WORKFILE FB(80 27920) VIRTUAL RETAIN

And that is using virtual storage, no dasd storage.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Aug 04, 2010 8:01 pm
Reply with quote

Hello,

Easytrieve Manual wrote:
Virtual (VFM) files and sort work files are written to the EZTVFM data set when required.


Sometimes these become quite huge. . .
Back to top
View user's profile Send private message
samrakesh

New User


Joined: 01 Sep 2006
Posts: 6
Location: Norwich, UK

PostPosted: Wed Aug 04, 2010 11:28 pm
Reply with quote

@ Dick
Thanks for that. In my case, that is exactly what is happening. The 'VIRTUAL' files and Sort Work datasets are being written to the EZTVFM file. As the explanation of the CATASTROPHIC error suggests, my EZTVFM file is going out of space. And even though I declare a high amount of space {CYL,(4369,16000)}, the problem does not get solved.

@Peter
All Virtual storage would eventually need to be converted to physical storage on DASD.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Aug 05, 2010 12:41 am
Reply with quote

Hello,

Virtual File Manager (VFM) files should not be confused with data that is allocataed to VIO - they are completely unrelated.

Suggest you determine how much space is needed by the process and up the allocation (if possible). Otherwise the process may have to be split.

Suggest you talk with the storage management people and see if more info on the DD statement would get you into a better storage class for your volume.

When the Easytrieve error is raised, is there also an x37 mentioned somewhere else in the sysout?
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Thu Aug 05, 2010 10:45 am
Reply with quote

If the total number of bytes of data to be maintained by VFM at any one time is known, the formula for cylinder allocation of space is:

bytes of data
-----------------------------
0.9 * track-length * trks/cyl

The EZTVFM file must not span volumes.
Back to top
View user's profile Send private message
samrakesh

New User


Joined: 01 Sep 2006
Posts: 6
Location: Norwich, UK

PostPosted: Thu Aug 05, 2010 6:51 pm
Reply with quote

Thanks for your help everyone. The problem is now solved, indirectly. The Easytrieve program was sorting an input file to a 'VIRTUAL' file, which was the main cause of the huge space needed. I've removed the Sorting process within Easytrieve and did the Sorting in an earlier step, using DFSORT. That done, Easytrieve was able to complete its calculations easily.

As I understand, and correct me if I am wrong, this means that there is a limitation on the amount of space that can be allocated to the EZTVFM file. Easytrieve is unable to handle the sorting of the high volume of data.

Point to note, while Easytrieve normally took more than 30 mins for this sorting, DFSORT finished it in less than 5 mins. Hail DFSORT!
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Aug 05, 2010 8:53 pm
Reply with quote

Hello,

Quote:
this means that there is a limitation on the amount of space that can be allocated to the EZTVFM file.
There is a limitation on the amount of space that can be allocated to any file. . . It you need to know the specifics for the EZTVFM, suggest you open an issue with CA Support and ask about your release of Easytrieve.

Sorting high volume data is almost always faster when an external sort is used (rather than an internal sort as your Easytrieve code or a COBOL internal sort).

Good to hear this is working - thank you for letting us know icon_smile.gif
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Thu Aug 05, 2010 9:49 pm
Reply with quote

PeterHolland wrote:
If the total number of bytes of data to be maintained by VFM at any one time is known, the formula for cylinder allocation of space is:

bytes of data
-----------------------------
0.9 * track-length * trks/cyl

The EZTVFM file must not span volumes.


I will be d'ed, the previous was not clear? In all my ezt experience i never
walked into space problems with ezt. And yes huge files were processed
with ezt sorting and so on.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> ABENDS & Debugging

 


Similar Topics
Topic Forum Replies
No new posts Error to read log with rexx CLIST & REXX 11
No new posts Error when install DB2 DB2 2
No new posts CLIST - Virtual storage allocation error CLIST & REXX 5
No new posts Error while running web tool kit REXX... CLIST & REXX 5
No new posts Getting Error while trying to establi... DB2 3
Search our Forums:

Back to Top