I am implementing a script like JCL to run on mainframe. Now I need to support 'PASS' in this script.
My JCL(Like JCL) includes below DD which is a output dataset.
To support this PASS, what I did is after this DD has been written with data in one step, I need read out the data and free this DD, then recreate another DD with same attributes and different DDname (a temparary name) and write back that data into this new DD. To do this is to resolve the same DD name with PASS can not be used in next step.
So now I am not sure where did the below abend happen, on old DD or new DD?
I supposed their space should be same. And increasing the space seems not useful.
Without my PASS support code, the same script (JCL like) can work well.
Could anyone help to see it? Thanks a lot.
Error:
The system got B37-04 error and S0C4 abend. When I changed SPACE=(CYL,(10,5)), it gave the same error.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
To be honest, you have given us not one item of useful information to try and help you.
You talk about a script. What - REXX / CLIST / .................... and many more
We have no idea of what you are trying to achieve.
Have you fixed the B37 abend yet, and if so does the 0C4 still occur.
I am not sure what information are useful for you to help analyze this problem. So if my below description did not answer you, please help point them out. Thank you.
I am not using internal sort.
The B37 error has not been resolved which is my problem indeed. I think that 0C4 error is due to the B37 error. If B37 is resolved, 0C4 should disappear. So now I am trying to ask why this B37 happened.
As to the script, I am referring to a kind of language which is similar to JCL. It has simliar syntax and functions with JCL, but not a full set of JCL.
For example,
//STEP4 EXEC PGM=SR01001P,
// COND=(4,LT,STEP1),
// COND=(0,NE,STEP2),
// COND=(4,LT,STEP3)
//STEPLIB DD DSN=&LSYSUSR,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ENTRADA DD DSN=&&TRNOUT,DISP=SHR
//SALIDA DD DSN=&&SYSCIN,UNIT=&WUNIT,DISP=(MOD,PASS),
// DCB=(BLKSIZE=400),SPACE=(CYL,(2,1))
In above JCL, DD SALIDA will be passed to next step in JES system.
Our script is same with above JCL, and it will not executed by JES, but by our application. Our application will parse the script and allocate those DD file and call pgm to execute. So now I need implement the PASS feature by myself in our application running on MVS, not by JES.
Then I happened to the B37 error with DD SALIDA. It is saying
IEC030I
B37-04,IFG0554A,DF8DE056,RUNPGM,SALIDA,3E08,WRKE08,SYS10272.T092000.RA000.DF8DE055.SYSCIN.H02
It seems the temp dataset &&SYSCIN is full. But when SPACE=(CYL,(10,5)) is defined for that DD, the same error comes out. If we are sure that the DD data is not as large as that, what possible reasons can cause this B37 error?
since we know nothing about Your application it is really difficult to explain why a space abend occurs!
You and Your support are the only ones who can carry on the problem determination an subsequent resolution
we only can point You at the manual strongly inviting You to follow the manual' s suggestion
Also, 400 is an inefficient BLKSIZE, but without knowing anything else about the file being created or the program creating it, I can not say if it is required or not. Try your job without. If you know the attributes then code only the attributes rather than just the BLKSIZE
Hello,expat
Our script does not support allocating dataset acrossing multiple volumns.
Are you doubting the dataset space is small?
One thing is when our application does not include my new code changes for PASS, SPACE=(CYL,(2,1)) did work. So the file size that program created should not very large. My code changes are using C/C++ runtime API on MVS (such as dyalloc()) to allocate dataset using the attributes defined in that DD.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Dan Zheng: from the Messages and Codes manual:
Quote:
04
During end-of-volume processing, one of the following occurred:
1. For an output data set, all space was used on the current volume and no more volumes were specified.
2. The system had to demount a volume in order to mount the next volume of the data set. It was unable to demount the volume for one of the following reasons:
1. The volume was permanently resident
2. The volume was reserved
3. Another job had data sets allocated on the volume
4. There were open data sets on the volume for the failing task.
For an output data set on a direct access device, the system might have needed to demount the volume for one of the following reasons:
* No more space was available on the volume.
* The data set already had 16 extents, but required more space.
* More space was required, but the volume table of contents (VTOC) was full. If additional space were allocated, another data set control block (DSCB) might have been needed, but could not have been written.
For an output data set on magnetic tape, a volume needed to be demounted because the reflective spot was encountered and more records were to be written.
For an input data set on more than one volume, one of the volumes needed to be demounted so that the next one could be mounted, but the system was unable to demount the volume.
You may not think the data set ran out of space, but the computer thinks it did. You may believe the computer and work on the space issue, or you may not believe the computer and pursue your own guesses about the problem. If the pack had 3 free cylinders and your data set required a fourth cylinder then you'd get the SB37-04 abend -- guaranteed. Run the job again, and if SMS allocates to a different volume, it might not get a SB37-04 abend again.
