Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
The suggested solutions presented here wasn't appropriate to solve the problem. (Unless an extreme overallocation can be seen as a solution.) Nothing seems like a solution to those who don't listen. There were many suggestions supplied. NOT were over allocations. Since nobody supplied a one size-fits-all, magic bullet, I guess your needs weren't met. After all, all of the suggestions required some work on your part. Don't ever expect any suggestions from me anymore. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On 05/23/2013 09:44 AM, Thomas Berg wrote: To clarify. I wrote: What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) With that I meant: 1. That there is many cases where an unspecified/undeterminable amount of space is needed for an allocation. 2. That because of the undeterminable status (which can be because it's exactly undeterminable or not possible to spend the amount of time to make it determinable) you can't make any rule of how much space it will request at run time. 3. That any ACS rules or other techniques (other than products that catches a x37 at run time) therefore is of limited help. 4. That if IBM have a function that catches an out of space condition and extend the allocated space to the current need it would save an enormous amount of time spend at correcting the error and rerun the jobs. 5. That *limiting* the use of space should not depend on what is written in the SPACE parm. Rather that it's something that any sort of quotas (ACS maybe) connected to the userid and datasetname should handle. 6. This is - more or less - how it works in e g the Unix world. And they are maybe not insane ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) The problem is in the definition of appropriate resource constraints. It needs to be something more complex than just putting a total space constraint on an individual user, as even individual users engage in actions of different priority and different degrees of certainty. To me it would be inappropriate if a typical debugging run caught in a loop could exhaust a users space allotment and then cause that user's TSO session or his batch jobs doing standard compiles to fail. I would also find it inappropriate if the defaults did not provide a reasonable way to communicate to a user that he has greatly exceeded usual DASD space usage patterns, because more often than not this is an indicatioh of a bug or some error in judgement that needs to be addressed rather than throwing more resources at the job. There needs to be some kind of multi-tiered approach where the type of job step and/or user specified categorization of data sets enters into the limit determination for individual data sets, and while allowing mechanisms for unusally large data sets perhaps also at some point require manual intervention of some kind to allow a process to allocate more space and continue, when the size of such data sets is seen as a potential threat to future allocation by either that user or other users. Users should not have to worry about how many volumes are required, or about limitations on number of extents per volume, or about volume fragmentation; but data set allocation limits must still protect users and jobs from each other and not needlessly waste resources in over allocation. In a z/OS environment that may service many different groups of loved ones, overall availability of the system is more important than just the convenience of an individual user. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
In a90e503c23f97441b05ee302853b0e628f2b31b...@fspas01ev010.fspa.myntet.se, on 05/23/2013 at 11:53 AM, Thomas Berg thomas.b...@swedbank.se said: There is a problem that is solved by a simple solution, the one that I proposed IBM should do. To every question there is an answer that is obvious, simple and wrong. The suggested blames and solutions presented here wasn't appropriate to solve the problem. Au contraire, blindly guessing at fixes before you understand the problem guaranties more problems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, May 23, 2013 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets In a90e503c23f97441b05ee302853b0e628f2b31b...@fspas01ev010.fspa.myntet.se , on 05/23/2013 at 11:53 AM, Thomas Berg thomas.b...@swedbank.se said: There is a problem that is solved by a simple solution, the one that I proposed IBM should do. To every question there is an answer that is obvious, simple and wrong. In this case because... ? The suggested blames and solutions presented here wasn't appropriate to solve the problem. Au contraire, blindly guessing at fixes before you understand the problem guaranties more problems. How do you know I don't understand the problem ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. I don't remember that in any JCL doc I've ever seen. Where is this documented? Or, am I misreading this post and it only applies to DB2's allocations? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Blaicher, Christopher Y. cblaic...@syncsort.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 23 May 2013 12:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
I think it was a pie in the sky suggestion. = = Date: Thu, 23 May 2013 20:07:25 + From: eamacn...@yahoo.ca Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets To: IBM-MAIN@LISTSERV.UA.EDU That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. I don't remember that in any JCL doc I've ever seen. Where is this documented? Or, am I misreading this post and it only applies to DB2's allocations? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Blaicher, Christopher Y. cblaic...@syncsort.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 23 May 2013 12:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
OK, I had never heard of this either, so I bit... 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD I did find the error message interesting, as it kind of implies that there is a CORRECT way to use a plus sign in a SPACE parm, but a quick glance thru the (1.10 level) doc mentions no use of a plus sign. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Thursday, May 23, 2013 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I think it was a pie in the sky suggestion. = = Date: Thu, 23 May 2013 20:07:25 + From: eamacn...@yahoo.ca Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets To: IBM-MAIN@LISTSERV.UA.EDU That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. I don't remember that in any JCL doc I've ever seen. Where is this documented? Or, am I misreading this post and it only applies to DB2's allocations? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Blaicher, Christopher Y. cblaic...@syncsort.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 23 May 2013 12:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Thu, May 23, 2013 at 3:54 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: OK, I had never heard of this either, so I bit... 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD I did find the error message interesting, as it kind of implies that there is a CORRECT way to use a plus sign in a SPACE parm, but a quick glance thru the (1.10 level) doc mentions no use of a plus sign. Rex SPACE=(CYL,(2,1+1)) Primary extent is 2, First secondary extent is 1, Additional secondary extents increase by 1? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Thu, May 23, 2013 at 10:33 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: deleted For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. deleted -- Tom Marchant Take the maximum allocation amount on a volume (64K tracks, 4GB, etc). Divide by 15, put the remainder in the Primary. Allow multiple volumes. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Yes, pie in the sky suggestion. Notice it said, If you changed the SPACE parameter to accept. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Thursday, May 23, 2013 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I think it was a pie in the sky suggestion. = = Date: Thu, 23 May 2013 20:07:25 + From: eamacn...@yahoo.ca Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets To: IBM-MAIN@LISTSERV.UA.EDU That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. I don't remember that in any JCL doc I've ever seen. Where is this documented? Or, am I misreading this post and it only applies to DB2's allocations? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Blaicher, Christopher Y. cblaic...@syncsort.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 23 May 2013 12:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Nope. Nothing in the JCL reference manual mentions anything like this either. 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,1+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, May 23, 2013 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, May 23, 2013 at 3:54 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: OK, I had never heard of this either, so I bit... 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD I did find the error message interesting, as it kind of implies that there is a CORRECT way to use a plus sign in a SPACE parm, but a quick glance thru the (1.10 level) doc mentions no use of a plus sign. Rex SPACE=(CYL,(2,1+1)) Primary extent is 2, First secondary extent is 1, Additional secondary extents increase by 1? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
They are working with production. Not the development side which I work with. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Tuesday, May 21, 2013 12:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets At least space management is Space Management's job. Production support is Production Support's job. Or else, what are they doing? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Thomas Berg thomas.b...@swedbank.se Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 23:22:32 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets They couldn't care less. They couldn't care less? About doing their job? You have a bigger problem than x37 abends! They have other things to do. They would see it as my job. (We have - according to many external viewers - a very lean organization for a relatively large MF shop. In other words - we are cheap... :) ) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, May 21, 2013 9:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se , on 05/20/2013 at 05:25 PM, Thomas Berg thomas.b...@swedbank.se said: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. Was the SB37 in FT or in a subsequent SUBMIT? Exactly at the point where FTINCL was done for a large include. (A previous FTINCL in the same FTOPEN-FTCLOSE chain was ok.) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, May 21, 2013 9:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se , on 05/20/2013 at 09:25 PM, Thomas Berg thomas.b...@swedbank.se said: === I think that part of this disagreement is that most of my opponents here is, more or less, sysprogs. And as such they haven't experienced the amount of time needed and lost at space allocation problems that lots and lots of jobs and applications are generating. Au contraire, the systems programmers will almost always see lots of space problems, most the results of ignoring documented procedures. Then why do the answers to my diatribe looks like they don't see this as a problem ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Space Management is critical for all usage of disk. Not just development. Otherwise, how to you rein in the space hogs? Or, maintain productivity? System Programming doesn't test products in development first? Just slap them in and hope they work in Production? As I've already said, you've a bigger problem than x37 abends? The pseudo-separaration of development from production is a disaster waiting to happen! Where do they thing new applications and fixes come from? Like Athena, fully grown, from the forehead o Zeus? Not to mention the potential morale problem of being mere developers. Or, the delay in problem solving due to under-resourced staff. Or, ... ... But, it's not my shop! TETO! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Thomas Berg thomas.b...@swedbank.se Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Wed, 22 May 2013 13:34:28 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets They are working with production. Not the development side which I work with. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Tuesday, May 21, 2013 12:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets At least space management is Space Management's job. Production support is Production Support's job. Or else, what are they doing? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Thomas Berg thomas.b...@swedbank.se Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 23:22:32 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets They couldn't care less. They couldn't care less? About doing their job? You have a bigger problem than x37 abends! They have other things to do. They would see it as my job. (We have - according to many external viewers - a very lean organization for a relatively large MF shop. In other words - we are cheap... :) ) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
In a90e503c23f97441b05ee302853b0e628f2a315...@fspas01ev010.fspa.myntet.se, on 05/22/2013 at 01:42 PM, Thomas Berg thomas.b...@swedbank.se said: In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se , on 05/20/2013 at 09:25 PM, Thomas Berg thomas.b...@swedbank.se said: === I think that part of this disagreement is that most of my opponents here is, more or less, sysprogs. And as such they haven't experienced the amount of time needed and lost at space allocation problems that lots and lots of jobs and applications are generating. Au contraire, the systems programmers will almost always see lots of space problems, most the results of ignoring documented procedures. Then why do the answers to my diatribe looks like they don't see this as a problem ? Why is the Moon made of green cheese? Nobody claimed that it wasn't a problem, just that you have not correctly assigned the blame. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Then why do the answers to my diatribe looks like they don't see this as a problem ? It's not that it's not a problem. It's just that there is 35+ years of prior art that your shop seems to be ignoring. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
W dniu 2013-05-20 18:42, Ted MacNEIL pisze: Windows make work until the disk is full. And that is what we want! I don't think so. Windows, in general, is a dedicated single user system. This philosophy is fine in that environment. Single user system? What about Windows SERVERS? Including FILE servers? Oh, btw: Windows CLUSTERS are able to share disks. Regarding disk quotas: such limits were available in Novell Netware 3, dated 1990. AFAIK it was also available in Netware 2 in the 80's. Netware 3 was able to manage 1024 disks and up to 32 TB disk space. With multiple users and quotas per user and/or per directory. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Slightly drifting topic: could it be that all this mess is responsible for z/OS file I/O not being able to compete with (for example) Unix file I/O on different platforms? We have a large application which needs high volumes of read only data. In Unix and Windows environment, this data comes from files through a table system with a main storage cache. In z/OS, up until now, we used DB2. Now, to save CPU, we tried the Unix/Windows solution on z/OS too. The result was: the CPU time was 25 % less, but elapsed time was significantly higher, due to waits on the file I/O - although there was not much file I/O - most of it was reduced by the main storage cache. Anyway: we have to experiment with larger cache sizes, but it appears that the z/OS file I/O is the bottleneck. We use fseek / ftell / fread to do the file I/O. The files are normal sequential OS files. Kind regards Bernd Am 20.05.2013 22:13, schrieb Paul Gilmartin: On Mon, 20 May 2013 13:45:46 -0500, Mike Schwab wrote: Our section uses and IEBGENER proc to SYSOUT=(A,,INTRDR) and works just fine. I have an EDIT macro that does very similar. _And_ it allocates the INTRDR with attributes of the data set being submitted; it doesn't quietly truncate my data to 80 columns. --On Mon, 20 May 2013 21:39:01 +0200, Thomas Berg wrote: 3. We have always done like this, therefore it must be good. http://www.thealders.net/humour/work/wk49.html Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. And z/OS UNIX cp command allocates its output data set with RLSE, then opens it several times. The first time it writes no data, guaranteeing an x37 shortly thereafter. IBM took an APAR. First they suggested secondary extents, then they agreed to provide a NORLSE option, with RLSE remaining the default, just to be inconsistent with almost all MVS allocation. cp() generates the RLSE TU only if the programmer specifies SPACE. Go figger. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
How about data striping? snip Now, to save CPU, we tried the Unix/Windows solution on z/OS too. The result was: the CPU time was 25 % less, but elapsed time was significantly higher, due to waits on the file I/O - although there was not much file I/O - most of it was reduced by the main storage cache. Anyway: we have to experiment with larger cache sizes, but it appears that the z/OS file I/O is the bottleneck. We use fseek / ftell / fread to do the file I/O. The files are normal sequential OS files. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
There are many ways to improve I/O for sequential files. My own experience suggests that the use of BUFNO= and NCP= is exiguous and should not be. Comparison shopping is unlikely to be helpful. These problems need to be addressed directly taking low-level measurements: To be told that one has lost a chess game does not much help improve one's game. Why, anyway, is the umlaut in 'för' being perpetuated? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se, on 05/20/2013 at 03:33 PM, Thomas Berg thomas.b...@swedbank.se said: The implied target for the FTINCL is the ISPFILE dataset that is preallocated. Why? Allocate one yourself that is big enough, or use FTOPEN TEMP if you ACS is appropriate. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se, on 05/20/2013 at 05:25 PM, Thomas Berg thomas.b...@swedbank.se said: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. Was the SB37 in FT or in a subsequent SUBMIT? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
In a90e503c23f97441b05ee302853b0e628c16e53...@fspas01ev010.fspa.myntet.se, on 05/20/2013 at 09:25 PM, Thomas Berg thomas.b...@swedbank.se said: === I think that part of this disagreement is that most of my opponents here is, more or less, sysprogs. And as such they haven't experienced the amount of time needed and lost at space allocation problems that lots and lots of jobs and applications are generating. Au contraire, the systems programmers will almost always see lots of space problems, most the results of ignoring documented procedures. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Have you checked sys1.parmlib(allocnn)? Space if not specified defaults to 4 tracks. Thank You, Dave O'Brien From: Thomas Berg [thomas.b...@swedbank.se] Sent: Monday, May 20, 2013 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets. Can anybody help me or hint to where to get the information. *Preferably not an answer that requires a reinstall/customization of the ISPF installment (time problem).* (I have tried the FTOPEN TEMP variant but then I got the B37 on the userid.ISPn.SPFTEMPn.CNTL dataset instead. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
You do not need to reinstall or customize ISPF. Setup an ACS entry in your DATA Class to handle the allocation you want **.SPFTEMP%.CNTL Then assign it a Dataclass that has the space allocations you want. I am not aware that this process (ACS) will not work to allocate the size file you want. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Monday, May 20, 2013 6:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets. Can anybody help me or hint to where to get the information. *Preferably not an answer that requires a reinstall/customization of the ISPF installment (time problem).* (I have tried the FTOPEN TEMP variant but then I got the B37 on the userid.ISPn.SPFTEMPn.CNTL dataset instead. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Sorry, you could probably do this with the **.SPFTEMP%.WORK as well. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, May 20, 2013 6:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets You do not need to reinstall or customize ISPF. Setup an ACS entry in your DATA Class to handle the allocation you want **.SPFTEMP%.CNTL Then assign it a Dataclass that has the space allocations you want. I am not aware that this process (ACS) will not work to allocate the size file you want. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Monday, May 20, 2013 6:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets. Can anybody help me or hint to where to get the information. *Preferably not an answer that requires a reinstall/customization of the ISPF installment (time problem).* (I have tried the FTOPEN TEMP variant but then I got the B37 on the userid.ISPn.SPFTEMPn.CNTL dataset instead. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Cross posting to ISPF and IBMMAIN newsgroups In the ISPF manual you can see that the DD names //ISPWRKW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPWRKx, where x can be //* 1-9, A-W. For example, if the value of the keyword = 8, //* only ISPWRK1 to ISPWRK8 need to be coded. //ISPWRK1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //ISPWRK2 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) The ISPF temporary data set default names associated with the ISPWRKx are SPFTEMPx.WORK, respectively, where x= value 1-9, A-W. So you could pre-allocate ISPWRK0-9 in your process with the size you want. But you will not necessarily know which one it will use. Just a thought. Lizette -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Styles, Andy (SMS - Scheduling and SCM Infrastructure Support) Sent: Monday, May 20, 2013 6:41 AM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Thomas, The links I gave specifically relate to the WORK datasets. Andy Styles -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of thomas.b...@swedbank.se Sent: 20 May 2013 14:29 To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Andy, Ren and Lizette, Thanks for the tips, but my problem lies at another level; at the WORK dataset that ISPF tries to allocate, NOT the target CNTL. E g userid.ISP012345.SPFTEMP2.WORK. If I use the TEMP variant and use the ZTEMPF dataset, I get a B37 on the (e g) userid.ISP04567.SPFTEMP2.CNTL dataset. And I can't reallocate the dataset as ISPF have it OPEN. (And it seems ISPF allocate a new dataset(name) every time.) And, as I mentioned, I prefer a non-reinstall/customization of the ISPF installment as it will take more time to get done that I have for the moment. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Lizette Koehler Sent: Monday, May 20, 2013 2:36 PM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I like using FTOPEN TEMP Then I have the ZTEMPF name to work with. Then I can code the ACS routines to handle the allocation. The name is nicer than FTOPEN with nothing behind it. But I think in either case (FTOPEN or FTOPEN TEMP) you may need to use ACS Code to change the DATA CLASS for a different allocation (I have not tried this) or You might be able to pre-allocate a file on ISPFILE DD Name and then try the FTOPEN process. See if it sees the allocated file and uses it rather than creating one. If that does not work, try setting ZTEMPF to the name on the ISPFILE allocation. I have not tried either actions, but they might work. There may also be something in the customization and planning guide (as others have stated) that controls the size of this file. You could use the configuration tool and see if there is an entry for ISPFILE sizes. You can also run TSO ISPVCALL (2 times) to see that ISPFILE looks like in your ISPF environment. This unloads the ISPF config file. Lizette -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of thomas.b...@swedbank.se Sent: Monday, May 20, 2013 4:40 AM To: isp...@listserv.nd.edu Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets. Can anybody help me or hint to where to get the information. Preferably not an answer that requires a reinstall/customization of the ISPF installment (time problem). Med Vänlig Hälsning Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) Lloyds TSB Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales, number 2065. Telephone: 020 7626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
As stated: pre-allocated ISPFILE then run your dialogue. Ie: address TSO ALLOC FI(ISPFILE) REUSE CYL ... address ... FTOPEN FT... etc. FTCLOSE VGET ZTEMPF address TSO SUB ztempf FREE ISPFILE Or give it a name: address TSO ALLOC FI(ISPFILE) DA( || dsn || ) ... --- FT stuff address TSO FREE FI(ISPFILE) SUB dsn DEL dsn - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Thomas Berg thomas.b...@swedbank.se Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 15:33:40 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets. Can anybody help me or hint to where to get the information. *Preferably not an answer that requires a reinstall/customization of the ISPF installment (time problem).* (I have tried the FTOPEN TEMP variant but then I got the B37 on the userid.ISPn.SPFTEMPn.CNTL dataset instead. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Way too complicated! Just dynamically allocated/de- as needed for each file tailoring dialogue. That way you can control the dsn sizes any way your lil ol heart desires. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Lizette Koehler stars...@mindspring.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 06:47:10 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Cross posting to ISPF and IBMMAIN newsgroups In the ISPF manual you can see that the DD names //ISPWRKW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPWRKx, where x can be //* 1-9, A-W. For example, if the value of the keyword = 8, //* only ISPWRK1 to ISPWRK8 need to be coded. //ISPWRK1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //ISPWRK2 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) The ISPF temporary data set default names associated with the ISPWRKx are SPFTEMPx.WORK, respectively, where x= value 1-9, A-W. So you could pre-allocate ISPWRK0-9 in your process with the size you want. But you will not necessarily know which one it will use. Just a thought. Lizette -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Styles, Andy (SMS - Scheduling and SCM Infrastructure Support) Sent: Monday, May 20, 2013 6:41 AM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Thomas, The links I gave specifically relate to the WORK datasets. Andy Styles -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of thomas.b...@swedbank.se Sent: 20 May 2013 14:29 To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Andy, Ren and Lizette, Thanks for the tips, but my problem lies at another level; at the WORK dataset that ISPF tries to allocate, NOT the target CNTL. E g userid.ISP012345.SPFTEMP2.WORK. If I use the TEMP variant and use the ZTEMPF dataset, I get a B37 on the (e g) userid.ISP04567.SPFTEMP2.CNTL dataset. And I can't reallocate the dataset as ISPF have it OPEN. (And it seems ISPF allocate a new dataset(name) every time.) And, as I mentioned, I prefer a non-reinstall/customization of the ISPF installment as it will take more time to get done that I have for the moment. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Lizette Koehler Sent: Monday, May 20, 2013 2:36 PM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I like using FTOPEN TEMP Then I have the ZTEMPF name to work with. Then I can code the ACS routines to handle the allocation. The name is nicer than FTOPEN with nothing behind it. But I think in either case (FTOPEN or FTOPEN TEMP) you may need to use ACS Code to change the DATA CLASS for a different allocation (I have not tried this) or You might be able to pre-allocate a file on ISPFILE DD Name and then try the FTOPEN process. See if it sees the allocated file and uses it rather than creating one. If that does not work, try setting ZTEMPF to the name on the ISPFILE allocation. I have not tried either actions, but they might work. There may also be something in the customization and planning guide (as others have stated) that controls the size of this file. You could use the configuration tool and see if there is an entry for ISPFILE sizes. You can also run TSO ISPVCALL (2 times) to see that ISPFILE looks like in your ISPF environment. This unloads the ISPF config file. Lizette -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of thomas.b...@swedbank.se Sent: Monday, May 20, 2013 4:40 AM To: isp...@listserv.nd.edu Subject: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Hi, I'm having problems in that when I try FTINCL för a JCL I get B37 on the userid.ISPn.SPFTEMPn.WORK dataset. The implied target for the FTINCL is the ISPFILE dataset that is preallocated. The code: FTOPEN FTINCL VKVASJOB FTINCL tgtenv NOFT FTINCL VKVASUPD FTCLOSE NAME(jbmbr) I haven't found how I do to get a larger allocation for that type of datasets
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Way too complicated! Just dynamically allocated/de- as needed for each file tailoring dialogue. That way you can control the dsn sizes any way your lil ol heart desires. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Lizette Koehler stars...@mindspring.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 06:47:10 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Cross posting to ISPF and IBMMAIN newsgroups In the ISPF manual you can see that the DD names //ISPWRKW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPWRKx, where x can be //* 1-9, A-W. For example, if the value of the keyword = 8, //* only ISPWRK1 to ISPWRK8 need to be coded. //ISPWRK1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //ISPWRK2 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) The ISPF temporary data set default names associated with the ISPWRKx are SPFTEMPx.WORK, respectively, where x= value 1-9, A-W. So you could pre-allocate ISPWRK0-9 in your process with the size you want. But you will not necessarily know which one it will use. Just a thought. Lizette -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Styles, Andy (SMS - Scheduling and SCM Infrastructure Support) Sent: Monday, May 20, 2013 6:41 AM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Thomas, The links I gave specifically relate to the WORK datasets. Andy Styles -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of thomas.b...@swedbank.se Sent: 20 May 2013 14:29 To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Andy, Ren and Lizette, Thanks for the tips, but my problem lies at another level; at the WORK dataset that ISPF tries to allocate, NOT the target CNTL. E g userid.ISP012345.SPFTEMP2.WORK. If I use the TEMP variant and use the ZTEMPF dataset, I get a B37 on the (e g) userid.ISP04567.SPFTEMP2.CNTL dataset. And I can't reallocate the dataset as ISPF have it OPEN. (And it seems ISPF allocate a new dataset(name) every time.) And, as I mentioned, I prefer a non-reinstall/customization of the ISPF installment as it will take more time to get done that I have for the moment. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: ISPF discussion list [mailto:isp...@listserv.nd.edu] On Behalf Of Lizette Koehler Sent: Monday, May 20, 2013 2:36 PM To: isp...@listserv.nd.edu Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I like using FTOPEN TEMP Then I have the ZTEMPF name to work with. Then I can code the ACS routines to handle the allocation. The name is nicer than FTOPEN with nothing behind it. But I think in either case (FTOPEN or FTOPEN TEMP) you may need to use ACS Code to change the DATA CLASS for a different allocation (I have not tried this) or You might be able to pre-allocate a file on ISPFILE DD Name and then try the FTOPEN process. See if it sees the allocated file and uses it rather than creating one. If that does not work, try setting ZTEMPF to the name on the ISPFILE allocation. I have not tried either actions, but they might work. There may also be something in the customization and planning guide (as others have stated) that controls the size of this file. You could use
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 20, 2013 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) SARCASM But maybe it's so complicated to construct such a solution that IBM needs to consult the Windows programmers ? :E /SARCASM Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On 5/20/2013 9:46 AM, Thomas Berg wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 20, 2013 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) SARCASM But maybe it's so complicated to construct such a solution that IBM needs to consult the Windows programmers ? :E /SARCASM But Thomas, dataset space / size parameters _are_ the constraints! That's what they're there for. Now, perhaps the various _default_ constraints should be larger, but that's what the various configuration settings and files are for, as is SMS. Windows doesn't let you choose / specify the constraints. -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Or you could ask your Storage Admin. to have SMS intercept the allocation and assign a dataclass with multiple volumes and a storage group with sufficient space. Thank You, Dave O'Brien From: Thomas Berg [thomas.b...@swedbank.se] Sent: Monday, May 20, 2013 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 20, 2013 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) SARCASM But maybe it's so complicated to construct such a solution that IBM needs to consult the Windows programmers ? :E /SARCASM Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Comstock Sent: Monday, May 20, 2013 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On 5/20/2013 9:46 AM, Thomas Berg wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, May 20, 2013 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) SARCASM But maybe it's so complicated to construct such a solution that IBM needs to consult the Windows programmers ? :E /SARCASM But Thomas, dataset space / size parameters _are_ the constraints! That's what they're there for. Now, perhaps the various _default_ constraints should be larger, but that's what the various configuration settings and files are for, as is SMS. Windows doesn't let you choose / specify the constraints. With constraints I meant something like ACS rules. That is: rules set according to the overall need for the business. Not according to some ancient technical needs. Windows make work until the disk is full. And that is what we want! Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
AFAIK that doesn't help with the technical problems of allocate. (Primary and secondary allocations for the immediate current needs, extents etc.) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, May 20, 2013 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Or you could ask your Storage Admin. to have SMS intercept the allocation and assign a dataclass with multiple volumes and a storage group with sufficient space. Thank You, Dave O'Brien From: Thomas Berg [thomas.b...@swedbank.se] Sent: Monday, May 20, 2013 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 20, 2013 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) SARCASM But maybe it's so complicated to construct such a solution that IBM needs to consult the Windows programmers ? :E /SARCASM Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On 2013-05-20, at 09:59, Thomas Berg wrote: Windows make work until the disk is full. And that is what we want! Someone is apt to point out that behavior is better suited to a single-user desktop system than to a multi-user enterprise system. And on Windows the constraint is your local disk. Unless you use a Samba-mounted filesystem. I'll restate my wish for an input DDNAME option to SUBMIT. Even if not a pipe, it might be an allocated UNIX file. z/OS UNIX with its private HOME filesystems approximates the Windows desktop behavior: you use what you want until it's all gone and you don't bother other users. Historians tell me that part of the motivation for JES was to shed the constraints of allocation parameters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Windows make work until the disk is full. And that is what we want! I don't think so. Windows, in general, is a dedicated single user system. This philosophy is fine in that environment. But, in a shared system, you are NOT the only one affected by full disks! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
And is the reason why UNIX came up with the idea of individual user quotas on resources. I'll get some nimrod filled up something like /tmp with a run away, over night, background process. Waking up a sysadmin with this sort of problem tends to make us just a tad upset (where is the sob? I'll hang him out the window as a warning!). I get very upset at some of our programmers who put on debugging information with DISPLAY UPON SYSOUT. And then never remove it. So we end up having the SYSPRINT go to DD DUMMY. Or, worse, out to an automatically purged SYSOUT class. The worst was when somebody sent it out the the class which is sent to our reporting system and it swamped the Windows server and disk space. They got a talking to. On Mon, May 20, 2013 at 11:42 AM, Ted MacNEIL eamacn...@yahoo.ca wrote: Windows make work until the disk is full. And that is what we want! I don't think so. Windows, in general, is a dedicated single user system. This philosophy is fine in that environment. But, in a shared system, you are NOT the only one affected by full disks! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
I seems to be extremely hard to understand what I say and mean. Or is it a cemented idiosyncrasy among mainframers ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On 5/20/2013 1:03 PM, Thomas Berg wrote: I seems to be extremely hard to understand what I say and mean. If it's hard for you, imagine how it is for us g Or is it a cemented idiosyncrasy among mainframers ? I worked for several service bureaus during my career. Aside from providing a reliable system, a major concern was to prevent (sometimes clueless) users from impacting others. Rather than idiosyncracy I'd call it philosophy. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, May 20, 2013 at 10:46 AM, Thomas Berg thomas.b...@swedbank.se wrote: What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) Our site has several dataclas with DCB and Space parameter values suitable for smaller files FB 80 and VB 251 with Cyl 10 10 rlse. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, May 20, 2013 at 11:22 AM, Paul Gilmartin paulgboul...@aim.com wrote: deleted I'll restate my wish for an input DDNAME option to SUBMIT. Even if not a pipe, it might be an allocated UNIX file. z/OS UNIX with its private HOME filesystems approximates the Windows desktop behavior: you use what you want until it's all gone and you don't bother other users. Historians tell me that part of the motivation for JES was to shed the constraints of allocation parameters. -- gil Our section uses and IEBGENER proc to SYSOUT=(A,,INTRDR) and works just fine. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, May 20, 2013 8:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, May 20, 2013 at 10:46 AM, Thomas Berg thomas.b...@swedbank.se wrote: What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) Our site has several dataclas with DCB and Space parameter values suitable for smaller files FB 80 and VB 251 with Cyl 10 10 rlse. Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Thomas, If you can describe the problem you can program for it. In your case, make an educated guess, if that fails, get some more education. On Tue, May 21, 2013 at 4:47 AM, Thomas Berg thomas.b...@swedbank.se wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, May 20, 2013 8:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Mon, May 20, 2013 at 10:46 AM, Thomas Berg thomas.b...@swedbank.se wrote: What is REALLY needed is to get rid of the absurd requirement to specify the amount of storage to allocate for datasets! The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) Our site has several dataclas with DCB and Space parameter values suitable for smaller files FB 80 and VB 251 with Cyl 10 10 rlse. Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? There are ways around that. Change the allocation to 150 150 track and a (partial) release on close. The technology is there to address most yah buts. But, you're not going to get off with no constraints either handled by the ACS routines or the user. There are two forms of wrong thinking: 1. This is old, therefore bad. 2. This is new, therefore better. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Why complicate your logon PROC? I prefer just the ISPCTLx. And, just allocate and de-allocate as your file tailoring requires. But, teto. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Ed Finnell efinnel...@aol.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 14:38:21 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets RTFM: ISPF uses temporary data sets to generate JCL or utility control statements or to generate listings. To preallocate these data sets to VIO, include the DD statements in _Figure 48_ (http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc80/1.4.9?SHELF=EZ2MZ921DT=20090610205143#FIGTDS) in the TSO LOGON procedure. Preallocation of these data sets to VIO is not mandatory; ISPF automatically allocates them to real data sets if required. However, preallocation is recommended, because it reduces overhead and eliminates potential problems from insufficient space. //ISPCTL0 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=80,BLKSIZE=800,RECFM=FB) //ISPCTL1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=80,BLKSIZE=800,RECFM=FB) . . . //ISPCTLW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=80,BLKSIZE=800,RECFM=FB) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPCTLx, where x can be //* 1-9, A-W. For example, if the keyword value = 8, only //* ISPCTL1 to ISPCTL8 need to be coded. //* ISPCTL0 is a special case, used only by Edit for the Submit //* command. //ISPWRK1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //ISPWRK2 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) . . . //ISPWRKW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=256,BLKSIZE=2560,RECFM=FB) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPWRKx, where x can be //* 1-9, A-W. For example, if the value of the keyword = 8, //* only ISPWRK1 to ISPWRK8 need to be coded. //ISPLST1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=121,BLKSIZE=1210,RECFM=FBA) //ISPLST2 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=121,BLKSIZE=1210,RECFM=FBA) . . . //ISPLSTW DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)), //DCB=(LRECL=121,BLKSIZE=1210,RECFM=FBA) //* In this section of JCL, there is one DD for each screen //* defined, based on the value of keyword MAXIMUM_NUMBER_OF_ //* SPLIT_SCREENS in the configuration table. //* The DD name is in the form ISPLSTx, where x can be //* 1-9, A-W. For example, if the value of the keyword = 8, //* only ISPLST1 to ISPLST8 need to be coded. Figure 48. DD statements to preallocate data sets Notes: 1. When allocating to VIO, make sure that enough auxiliary storage is dedicated to VIO so that system availability is not affected. 2. Use of the BUFNO parameter on allocation of ISPF libraries is not supported. 3. The ISPF temporary data set default names associated with the ISPCTLx are SPFTEMPx .CNTL, respectively, where x= value 0-9, A-W. 4. The ISPF temporary data set default names associated with the ISPWRKx are SPFTEMPx.WORK, respectively, where x= value 1-9, A-W. 5. The ISPF temporary data set default names associated with the ISPLSTx are SPFTEMPx.LIST, respectively, where x= value 1-9, A-W. 6. The ddnames ISPWRKx are used by ISPF for file tailoring services with ISPFILE allocated to a PDS. The ddnames ISPLSTx are used for generated listings. 7. The ddname ISPCTL0 is used with the edit SUBMIT command. The ddnames ISPCTLx are used with ISPF compress (both interactive and the LMCOMP service) and ISPF background (option 5), and for processing the file tailoring service FTOPEN TEMP. 8. ISPCTL1 is a required ddname when using SCLM. The data set should be allocated as an ISPF temporary data set for SCLM foreground processing and should be added to the FLMLIBS skeleton for batch processing. In a message dated 5/20/2013 1:23:01 P.M. Central Daylight Time, gerh...@valley.net writes: Rather than idiosyncracy I'd call it philosophy
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
I wish that I could tell my PC what size to expect for files. A lot of files grab small chunks creating files with many extents spread all over the drive. When I write a program, or transfer a file, I know about how large the file will be, yet I have no way to tell the system. In our shop we use thought out defaults and tools like StopX to help users. Then we help them better specify or fine tune when the defaults and tools are unable to assist. In the end we get better performance where needed and ease of use in the majority of cases. Thank you and have a Terrific day! Jonathan Goossen, DTM ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with verbal communication and leadership skills checkout Woodwinds Toastmasters. IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 05/20/2013 01:47:49 PM: Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 9:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? There are ways around that. Change the allocation to 150 150 track and a (partial) release on close. The technology is there to address most yah buts. But, you're not going to get off with no constraints either handled by the ACS routines or the user. There are two forms of wrong thinking: 1. This is old, therefore bad. 2. This is new, therefore better. 3. We have always done like this, therefore it must be good. Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. AND I don't assume no constraint. Rather that the constraint is/should not be different whether I specify the space amount manually in a repetition loop or letting the system do the same job. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, May 20, 2013 at 1:47 PM, Thomas Berg thomas.b...@swedbank.se wrote: Our site has several dataclas with DCB and Space parameter values suitable for smaller files FB 80 and VB 251 with Cyl 10 10 rlse. Well, how do you do when you not know in beforehand if the job needs 1 track or 5000 cyls ? And in most of the cases it needs just, say, 5 tracks ? And you have to allocate 1000 different files in different circumstances and your time is limited ? Regards Thomas Berg If they specify a value, it overrides the value on the DATACLAS definition. And yes, the default values are quite small on most of them. Some definitions have multiple volumes and large defaults. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, 20 May 2013 13:45:46 -0500, Mike Schwab wrote: Our section uses and IEBGENER proc to SYSOUT=(A,,INTRDR) and works just fine. I have an EDIT macro that does very similar. _And_ it allocates the INTRDR with attributes of the data set being submitted; it doesn't quietly truncate my data to 80 columns. --On Mon, 20 May 2013 21:39:01 +0200, Thomas Berg wrote: 3. We have always done like this, therefore it must be good. http://www.thealders.net/humour/work/wk49.html Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. And z/OS UNIX cp command allocates its output data set with RLSE, then opens it several times. The first time it writes no data, guaranteeing an x37 shortly thereafter. IBM took an APAR. First they suggested secondary extents, then they agreed to provide a NORLSE option, with RLSE remaining the default, just to be inconsistent with almost all MVS allocation. cp() generates the RLSE TU only if the programmer specifies SPACE. Go figger. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. Whoa! I'd like to see some examples of such broad (if not, exaggerated) statement! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 10:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I think that part of this disagreement is that most of my opponents here is, more or less, sysprogs. And as such they haven't experienced the amount of time needed and lost at space allocation problems that lots and lots of jobs and applications are generating. We're not opponents (nor adversaries); we're just trying to understand, and (if possible) help those who really do want it. I've been involved in space/DASD management for over 30 years. And, I HAVE experienced it all! As the technology evolves, the problems should reduce (if not, be totally eliminated) if your storage people are on the ball. Not to mention that you have to deal with many products that in practice have a lot of unsatisfying allocations that you NOT have the time to through in hundreds of scripts or jobs whenever a new version arrives. If you're in applications, why you involved to this level of detail? Maybe you haven't then experienced it all ? (Applications is not just business applications...) That's up to Production Support, Change Management, Storage and (most likely) System Programming. They couldn't care less. BTW, Change Management in itself contains one of the problem applications... You've turned a simple and, as demonstrated, solvable ISPF problem into tilting at the windmill of every space problem in your shop. And, it's NOT even your windmill! It is, when you are the one having problems with it. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
They couldn't care less. They couldn't care less? About doing their job? You have a bigger problem than x37 abends! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 10:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. Whoa! I'd like to see some examples of such broad (if not, exaggerated) statement! I suppose you mainly see the case of allocation for sequential files that have just one update - that at the allocation time. One case is when a PDS(E) is allocated for an undetermined number of members at an undetermined number of updates. And you can't determine this because it is dependent on actions from e g a group of developers that in turn is dependent on decisions taken by project leaders or maintenance circumstances. Or files that depending on many circumstances could be updated from zero to thousand times with data greatly varying in size. And that the time taken to analyze what maybe be needed in every specific case is not available. Either you grossly overallocate and have the possibility of running short of available disk space which is not better than x37's or you take some middle position and got some less, but still significant, problems from both extremes of the scale. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets They couldn't care less. They couldn't care less? About doing their job? You have a bigger problem than x37 abends! They have other things to do. They would see it as my job. (We have - according to many external viewers - a very lean organization for a relatively large MF shop. In other words - we are cheap... :) ) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
At least space management is Space Management's job. Production support is Production Support's job. Or else, what are they doing? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Thomas Berg thomas.b...@swedbank.se Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Mon, 20 May 2013 23:22:32 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, May 20, 2013 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets They couldn't care less. They couldn't care less? About doing their job? You have a bigger problem than x37 abends! They have other things to do. They would see it as my job. (We have - according to many external viewers - a very lean organization for a relatively large MF shop. In other words - we are cheap... :) ) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Thomas, The way you have been phrasing things, I get the impression that you want a one size fits all approach. Over the years our storage services department has worked with each of the many application groups and the fewer technical groups to assist them with their needs. Each group has its own issues and needs. We, as storage services, have setup SMS constructs and routines to help them meet their needs. When issues arise, we work with the person/group having the issue and any other technical group (FTP, database, etc.) that we need to. Often it is just educating the person on 'how to'. Each group has their common dataset types and know what to specify for allocation, and/or what defaults they get. We use tools like StopX37 to alleviate many common issues. We have automation in place to alert us of situations that could cause spaced abends so that we can fix them before they occur. Production support knows enough to apply a temporary fix after a space abend. They then pass it to the proper programming group for a permanent fix. (And they involve us if needed.) As you can see, we use multiple approaches to deal with space situations. I started out as a user of storage services before I transferred to administering the services. I really wish I could administer my PC files as well I can the mainframe files. Thank you and have a Terrific day! Jonathan Goossen, DTM ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with verbal communication and leadership skills checkout Woodwinds Toastmasters. IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 05/20/2013 04:19:00 PM: From: Thomas Berg thomas.b...@swedbank.se I suppose you mainly see the case of allocation for sequential files that have just one update - that at the allocation time. One case is when a PDS(E) is allocated for an undetermined number of members at an undetermined number of updates. And you can't determine this because it is dependent on actions from e g a group of developers that in turn is dependent on decisions taken by project leaders or maintenance circumstances. Or files that depending on many circumstances could be updated from zero to thousand times with data greatly varying in size. And that the time taken to analyze what maybe be needed in every specific case is not available. Either you grossly overallocate and have the possibility of running short of available disk space which is not better than x37's or you take some middle position and got some less, but still significant, problems from both extremes of the scale. Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
