B37-04 abend woes [2 Attachments]

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

B37-04 abend woes [2 Attachments]

Hercules390 - Mvs mailing list
After determining the likely cause of my original B37-04 abend was likely due to being out of space on my output volume, I reviewed the VTOC and sure enough, it ran out of extents.  This was my fault.  Earlier, I had re-created my input tape containing my test data with 3 times the amount of original data, and forgot to adjust the "SPACE=" parameter in my JCL accordingly.  My bad.

Sooo... After having increased my SPACE= parameter in my JCL (and after having manually deleted my output dataset in preparation for another run of course), the "new" results are....


...(drumroll please) ...


... abend B37-04.  (SIGH!)   :(


NOW, what's really confusing me about this is WHY am I still getting B37-04?  My "SPACE=" was *plenty* large enough and this is a completely empty 3390-9 volume.

Here's the VTOC display (IEHLIST also attached):

                                 Data Set Information
    Command ===>

    Data Set Name . . . . : IBMUSER.FISH.TESTFILE.#001

    General Data                           Current Allocation
     Management class . . : **None**        Allocated cylinders : 4,350
     Storage class  . . . : **None**        Allocated extents . : 1
      Volume serial . . . : FISH01
      Device type . . . . : 3390
     Data class . . . . . : **None**       Current Utilization
      Organization  . . . : PS              Used cylinders  . . : 4,350
      Record format . . . : FB              Used extents  . . . : 1
      Record length . . . : 1024
      Block size  . . . . : 30720
      1st extent cylinders: 4350
      Secondary cylinders : 150
      Data set name type  :                 SMS Compressible  :   NO

      Creation date . . . : 2017/01/25      Referenced date . . : 2017/01/25
      Expiration date . . : ***None***


As you can see, only ONE extent (the primary extent) was allocated.  That *proves* that it did NOT run out of space!  Yes?

So where is the B37-04 abend on SYSUT2 coming from?

What's going on?

I'm confused!

Help!  :(

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: B37-04 abend woes

Hercules390 - Mvs mailing list
---In [hidden email], <david.b.trout@...> wrote :

> Used extents . . . : 1

> As you can see, only ONE extent (the
> primary extent) was allocated. That
> *proves* that it did NOT run out of
> space! Yes?

I believe it proves that MVS needed more
space and it couldn't obtain more space.
Probably for the reason Laddie gave.

You might like to get rid of the secondary
space allocation, to make it "primary or
bust", and you should start seeing a D37
instead, because you're still exceeding
the limit.

Can you do a hetget and a "dir" on the
extracted file on the PC so that we can
see how big the input file is?

A 3390 has:

http://web.archive.org/web/20100209024308/http://www.sdisw.com/vm/dasd_capacity.html

849,960 bytes/cyl

Which comes to 4350 * 849,960 = 3.4 GiB.

You may be hitting some MVS limit of
2 GiB.

Perhaps try loading a file smaller than
2 GiB and make sure that works.

Actually, make it less than 1 GiB to
ensure that works, because of your
current inefficient block size.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: B37-04 abend woes

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
 - - - In [hidden email], <david.b.trout@...> wrote:
> After determining the likely cause of my original B37-04 abend was
>likely due to being out of space on my output volume, I reviewed the
>VTOC and sure enough, it ran out of extents. This was my fault.
>Earlier, I had re-created my input tape containing my test data with
>3 times the amount of original data, and forgot to adjust the
>"SPACE=" parameter in my JCL accordingly. My bad.

With such a poor output BLKSIZE=30720 instead of
BLKSIZE=27648 it should be running out of disk space.

If you use SMS COMPACT, then it would fit anyway.
 
> Sooo... After having increased my SPACE= parameter
>in my JCL (and after having manually deleted my output
>dataset in preparation for another run of course), the
>"new" results are....

Old MVS type of data sets are limited to 65535 tracks
per data set per disk.  Your SPACE allocation is
close but could be improved.
SPACE=(CYL,(4369,4369),RLSE
or
SPACE=(TRK,1,RLSE,ALX)

> ...(drumroll please) ...
> ... abend B37-04. (SIGH!) :(

Many posts warned about your poor output BLKSIZE .
Please change SYSUT2 from BLKSIZE=30720 to
BLKSIZE=27648

> NOW, what's really confusing me about this is WHY
>am I still getting B37-04? My "SPACE=" was *plenty*
>large enough and this is a completely empty 3390-9
>volume.

Old MVS data sets can only use 65535 tracks on each
disk volume.  3390-3 or 3390-54 it's the same.

> Here's the VTOC display (IEHLIST also attached):
> Data Set Information
> Command ===>
> Data Set Name . . . . : IBMUSER.FISH.TESTFILE.#001
> General Data Current Allocation
> Management class . . : **None**
>Allocated cylinders : 4,350

Why not go to the maximum of 4369 ?

> Storage class . . . : **None**
> Allocated extents . : 1

And can never go to two extents because the primary
extent is real close to the limit for an old MVS data
set on a disk volume.

> Volume serial . . . : FISH01
> Device type . . . . : 3390
> Data class . . . . . : **None**
> Current Utilization
> Organization . . . : PS
>Used cylinders . . : 4,350

The poor BLKSIZE filled it up.

> Record format . . . : FB
> Used extents . . . : 1

Can never get a second extent.

> Record length . . . : 1024
> Block size . . . . : 30720

What?????????????
Only using 30720 bytes on each 56664 byte tracks?
Nasty statement.  Nasty statement.  Nasty statement.

> 1st extent cylinders: 4350

4369 would be larger and better.

> Secondary cylinders : 150

Can never be used because the primary allocation is
19 cylinders from the limit.

> Data set name type : SMS
> Compressible : NO

For text files, I've seen 20 to 1 compression.

But the last I saw, SMS disk volumes required
you to catalog data sets so SMS compression
might not be available for you?

> Creation date . . . : 2017/01/25
> Referenced date . . : 2017/01/25
> Expiration date . . : ***None***
> As you can see, only ONE extent (the primary extent) was
>allocated. That *proves* that it did NOT run out of space! Yes?

The one primary did not mean that you did not do
what you did in running out of space.
The primary extent was what prevented any secondary
extents that are more than the 19 cylinders you allowed
the data set to expand.

> So where is the B37-04 abend on SYSUT2 coming from?

Bad JCL.

What is the uncompressed size of the tape?
From that, someone could calculate the number of
1024 byte records you have and how many of
3390 disk cylinders or tracks needed at
BLKSIZE=27648 or on zOS, BLKSIZE=0 would
calculate BLKSIZE=27648 for you.
System-Determined-BLKSIZE

> What's going on?
> I'm confused!
> Help! :(
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com http://www.softdevlabs.com
> mail: fish@... mailto:fish@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: B37-04 abend woes

Hercules390 - Mvs mailing list
[hidden email] wrote:
> Fish wrote:

[...]
> > Storage class . . . : **None**
> > Allocated extents . : 1
>
> And can never go to two extents because the primary
> extent is real close to the limit for an old MVS data
> set on a disk volume.

(Doh!)  Okay, I think I can see what you're getting at now.  Check me on this:

The actual number of cylinders that my test data WOULD consume (if "MVS" didn't have the 65535 track limit you mentioned) is quite likely much GREATER than 4369 cylinders (the 65535 track limit).  For illustrative purposes it might actually be 5,000 cylinders.  Or even 10,000!

But since I specified a primary allocation of 4350 cylinders and a SECONDARY allocation of 150 cylinders, the two together (4350 + 150 = 4500) *exceeds* the 4369 cylinder (65535 tracks) limit imposed my "MVS"!

So the reason it's abending with B37-04 is it actually *IS* running out of space!  Yes?  I.e. It first consumed the entire 4350 primary allocation, thus triggering a subsequent secondary allocation (because it still had more data to load and needed more space), but the specified secondary allocation size (150 cylinders) pushed it beyond the operating system imposed limit of 4369 cylinders! (65535 tracks)

Do I have that right?  Am I understanding the problem correctly now?

Thanks, [hidden email].  I see now that Laddie and possibly others were trying to tell me the same thing but I just wasn't getting it.  It wasn't sinking in.

But I think the penny has since dropped. :)

So all I need to do is keep reducing the size (amount) of my test data by a "little bit" each time and keep trying again and again, until I can manage to consume as close as possible to 4369 cylinders (say, 4350 cylinders for example).

Which I guess means I should probably change my SPACE parameter to something like "SPACE=(CYL,(4350))", yes?  (i.e. no secondary allocations at all, i.e. if the primary allocation runs out of room, just abend rather than try allocating a secondary extent).

Yes?

Thanks to everyone how has replied and helped me thus far.  I *really* appreciate it!

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: B37-04 abend woes

Hercules390 - Mvs mailing list
Hi Fish.

I believe your understand below is 100%
correct, but you haven't addressed the
block size issue.

There is a big difference in the amount
of data you can store in 4350 cylinders
depending on whether you use an
optimal block size like 27648 instead
of a wasteful block size of 30720.

Is there any reason you can't use an
optimal block size for a 3390 instead
of an optimal block size for a tape?

Your tape can stay at block size 30720
and let IEBGENER reblock that to
block size 27648.

As an aside, it seems you are running
some utility on the PC to generate test
data. Any reason why you don't directly
generate that on MVS, assuming you
are using C?

Also any reason why you aren't cataloging
the output disk dataset? It is normal on
MVS for all disk datasets to be cataloged.

BFN. Paul.




---In [hidden email], <david.b.trout@...> wrote :

 somitcw@... mailto:somitcw@... wrote:
 > Fish wrote:
 
 [...]
 > > Storage class . . . : **None**
 > > Allocated extents . : 1
 >
 > And can never go to two extents because the primary
 > extent is real close to the limit for an old MVS data
 > set on a disk volume.
 
 (Doh!) Okay, I think I can see what you're getting at now. Check me on this:
 
 The actual number of cylinders that my test data WOULD consume (if "MVS" didn't have the 65535 track limit you mentioned) is quite likely much GREATER than 4369 cylinders (the 65535 track limit). For illustrative purposes it might actually be 5,000 cylinders. Or even 10,000!
 
 But since I specified a primary allocation of 4350 cylinders and a SECONDARY allocation of 150 cylinders, the two together (4350 + 150 = 4500) *exceeds* the 4369 cylinder (65535 tracks) limit imposed my "MVS"!
 
 So the reason it's abending with B37-04 is it actually *IS* running out of space! Yes? I.e. It first consumed the entire 4350 primary allocation, thus triggering a subsequent secondary allocation (because it still had more data to load and needed more space), but the specified secondary allocation size (150 cylinders) pushed it beyond the operating system imposed limit of 4369 cylinders! (65535 tracks)
 
 Do I have that right? Am I understanding the problem correctly now?
 
 Thanks, somitcw@... mailto:somitcw@.... I see now that Laddie and possibly others were trying to tell me the same thing but I just wasn't getting it. It wasn't sinking in.
 
 But I think the penny has since dropped. :)
 
 So all I need to do is keep reducing the size (amount) of my test data by a "little bit" each time and keep trying again and again, until I can manage to consume as close as possible to 4369 cylinders (say, 4350 cylinders for example).
 
 Which I guess means I should probably change my SPACE parameter to something like "SPACE=(CYL,(4350))", yes? (i.e. no secondary allocations at all, i.e. if the primary allocation runs out of room, just abend rather than try allocating a secondary extent).
 
 Yes?
 
 Thanks to everyone how has replied and helped me thus far. I *really* appreciate it!
 
 --
 "Fish" (David B. Trout)
 Software Development Laboratories
 http://www.softdevlabs.com http://www.softdevlabs.com
 mail: fish@... mailto:fish@...
Loading...