Re: CTRACE writer peculiarity
On Wed, 7 May 2008 18:14:34 -0500, Richard Peurifoy r- [EMAIL PROTECTED] wrote: I changed my CTRACE writer to SPACE=(CYL,(10,5),RLSE) and after starting and stopping a trace I was left with a 1 CYL dataset. ... I confirmed that this has nothing to do with the CTRACE writer be GENERing an empty dataset into output datasets essentially identical to my CTRACE datasets (including no RLSE). Same results. Our dasd management folks were able to reproduce this and are now trying to find why and where they are providing me with RLSE. Thanks to those that responded. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CTRACE writer peculiarity
In the past I have always started a CTRACE writer with WRAP and allocated a dasd datasets with only primary allocation. I thought only the primary allocation was used. Today I noticed that the CTRACE writer would honor secondary allocation if it is started with NOWRAP. So I tried it. It worked, but my SPACE allocation of (CYL,(100,100)) had been changed to (CYL,(1,100)). That's ok for NOWRAP, but not so great for WRAP. If I remove the secondary allocation the dataset allocation stays as I specified on the DD statement. Our dasd management group swears it's not SMS doing this for me, but I don't see how it could be the CTRACE writer itself doing it. Anyone have any ideas where I should look? This is WAY outside my area of expertice. Thanks in advance. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
Patrick O'Keefe wrote: In the past I have always started a CTRACE writer with WRAP and allocated a dasd datasets with only primary allocation. I thought only the primary allocation was used. Today I noticed that the CTRACE writer would honor secondary allocation if it is started with NOWRAP. So I tried it. It worked, but my SPACE allocation of (CYL,(100,100)) had been changed to (CYL,(1,100)). That's ok for NOWRAP, but not so great for WRAP. If I remove the secondary allocation the dataset allocation stays as I specified on the DD statement. Our dasd management group swears it's not SMS doing this for me, but I don't see how it could be the CTRACE writer itself doing it. Anyone have any ideas where I should look? This is WAY outside my area of expertice. Thanks in advance. Pat O'Keefe Do you specify RLSE on you allocation? If ther CTRACE writer opens/closes and reopens the dataset, it would cause this. I have not used wrap, so I don't have any experience with this. If I have some time, I will experiment. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
Richard Peurifoy wrote: I have not used wrap, so I don't have any experience with this. If I have some time, I will experiment. You didn't mention an option that was introduced for both CTRACE and GTF in z/OS V1R7, VSAM linear data sets with a 32K CISIZE. They can be used for either WRAP or NOWRAP purposes. Striping is supported as is extended format (64-bit RBAs). The striping option allows you to increase the effective data rate for recording, and extended format yields capacity. Trace processing subcommands under IPCS accept them directly. If you're experimenting, give them a try. Bob Wright - z/OS Service Aids -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
Robert Wright wrote: Richard Peurifoy wrote: I have not used wrap, so I don't have any experience with this. If I have some time, I will experiment. You didn't mention an option that was introduced for both CTRACE and GTF in z/OS V1R7, VSAM linear data sets with a 32K CISIZE. They can be used for either WRAP or NOWRAP purposes. Striping is supported as is extended format (64-bit RBAs). The striping option allows you to increase the effective data rate for recording, and extended format yields capacity. Trace processing subcommands under IPCS accept them directly. If you're experimenting, give them a try. Bob Wright - z/OS Service Aids Thanks Bob, We are at 1.7, but I had missed this. I will look into it. My tracing so far has been mainly TCPIP packet traces, and they have been for small issues that didn't need to be traced for a long period of time. The data rate has also been small. But it is always good to know of options. Pat, I did a GTF trace of open, and close and tried a packet trace with wrap and nowrap. My trace dataset showed the first extent as what I allocated (I didn't use RLSE). From looking at the GTF trace it does appear that CTRACE writer does open/close/open and then a final close when it is stopped. I don't know why it does this, but there is probably a reason. If you specify RLSE on your allocation, I would expect what you are seeing. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
On Wed, 7 May 2008 17:13:54 -0500, Richard Peurifoy r- [EMAIL PROTECTED] wrote: ... Do you specify RLSE on you allocation? If ther CTRACE writer opens/closes and reopens the dataset, it would cause this. ... I forgot to mention that. I do not specify RLSE. Our dasd mgt folks claim that RLSE is not set by SMS, but there doesn't seem to be a NORLSE in JCL that would override and SMS-supplied value so I don't know of a way to check that. I thought RLSE would reduce the allocation to nothing (rather than 1) if the dataset were empty. I vaguely remember that I tried using RLSE at my last shop. The CTRACE writer (or maybe it was GTF) opened, closed, and reopened the dataset before writing to it. I didn't try it more than once. :-) It probably would have worked if I had included secondary allocation, but I hadn't. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
On Wed, 7 May 2008 18:36:48 -0400, Robert Wright [EMAIL PROTECTED] wrote: ... VSAM linear data sets with a 32K CISIZE. They can be used for either WRAP or NOWRAP purposes. Striping is supported as is extended format (64-bit RBAs). The striping option allows you to increase the effective data rate for recording, and extended format yields capacity. Trace processing subcommands under IPCS accept them directly. If you're experimenting, give them a try. ... I know nothing about VSAM linear datasets, but something tells me I can't have a GDG of them. :-) I'll look into this, though. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
Patrick O'Keefe wrote: On Wed, 7 May 2008 17:13:54 -0500, Richard Peurifoy r- [EMAIL PROTECTED] wrote: ... Do you specify RLSE on you allocation? If ther CTRACE writer opens/closes and reopens the dataset, it would cause this. ... I forgot to mention that. I do not specify RLSE. Our dasd mgt folks claim that RLSE is not set by SMS, but there doesn't seem to be a NORLSE in JCL that would override and SMS-supplied value so I don't know of a way to check that. I thought RLSE would reduce the allocation to nothing (rather than 1) if the dataset were empty. I thought it would leave one unit of allocation if the dataset was empty (1 TRK, 1 CYL). I checked the JCL reference, and it says it releases unused space, but doesn't say anything about a completely empty dataset. I changed my CTRACE writer to SPACE=(CYL,(10,5),RLSE) and after starting and stopping a trace I was left with a 1 CYL dataset. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
An open/close will produce an EOF marker and the minimum allocation will be one track... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Wednesday, May 07, 2008 3:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CTRACE writer peculiarity snip I thought RLSE would reduce the allocation to nothing (rather than 1) if the dataset were empty. snip _ Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics. http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
CICS Guy wrote: An open/close will produce an EOF marker and the minimum allocation will be one track... Of course, obvious once it's explained. ;-) -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CTRACE writer peculiarity
On Wed, 7 May 2008 16:16:20 -0700, CICS Guy [EMAIL PROTECTED] wrote: An open/close will produce an EOF marker and the minimum allocation will be one track... ... Well, in that case it sure sounds like someting is giving me RLSE free of charge if I include secondary allocation but not when I have only primary. I think I need to talk with our dasd management folks again. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
