Caveat: I get the daily digest so am always behind the curve in message traffic.
Charles (& others): this is not an SMF problem but a basic Dataset issue. I have encountered it here and the conflict is DISP=MOD vs RLSE [1] with multiple runs. This can easily give rise to 16 extents after 16 runs since [almost] each new run causes a new extent. It's even more aggravated when SPACE=TRK instead of CYL since there's less empty space at the end for appended data. A [bad] way to alleviate the problem is Vol=(,,,255) or through DynVolCount in SMS DataClas. This only means you get 16 * 255 (or the SMS value) kicks at the can before failure. [3] So, (MOD and RLSE) -> probable failure. [4] [1] watch out for PartialRelease in MgmtClas. You can get RLSE actions without specifying it in JCL. [2] [2] as part of my incremental, SMS implementation, I started using COND_IMMED and immediately had problems with a production job that used Disp=Mod. [4] [3] for DsOrg=PS, max extents / volume = 16. Other DsOrg's have higher limits ie. 123 for PSE. [4] my occurrence of [2] took a while to rear its ugly head because the volume was being compakt'd which amalgamated all the dataset extents. After 4-5 weeks, the job was run ~16 times before the next compakt occurred. --------> signature = 6 lines follows <-------- Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee "How *do* you plan for something like that?" Guardian Bob, Reboot "For every action, there is an equal and opposite criticism." "Systems Programming: Guilty, until proven innocent" John Norgauer 2004 -----Original Message----- From: Charles Mills [mailto:charl...@mcn.org] Sent: December 11, 2013 20:17 Subject: Re: SMF DUMP SB37 - what am I doing wrong? Sorry. Not sure of the timing of the various changes and tests. JCL may have been changed to 100,100 before the dump below. SB37 was due to 16 extents I think. Thanks for your input. The problem seems to be possibly solved. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Wednesday, December 11, 2013 4:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF DUMP SB37 - what am I doing wrong? Your DSCB is inconsistent with the job you provided. The first extent is for 93 tracks. The second is for 31 and the third is for 30. The secondary quantity in the DSCB is 100 tracks. This was not created by JCL specifying TRK,(10,10). Who/what really built the dataset? Are there 100 contiguous tracks available on pack VPMVSC? If so, you should not be experiencing B37 abends. What is the return code in the accompanying IEC030I message? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
