Re: SMS and System Temporary Datasets
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave > Sent: Tuesday, January 20, 2009 2:41 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > > Are you assuming SMS will manage the 'extent problem', and > you can get > rid of the product? You can't. > > Maybe not totally, but space constraint relief, extended > format and multi-volume can go a long way. > Hi Dave, This is exactly what I intend. We use Extended as default in (most of) our data classes with an initial volume count of 1 and a dynamic volume count of up to 58. Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
> I can see that the issue, in my current environment, is that I tell VAM > (CA-Allocate) to bail out of it's ASR (EXIT CODE(0)) if it sees a non-null Storage Class. Why? Use it! VAM/BrightStore/SAMS-Allocate works with SMS and non-SMS data. >We are hoping to be able to eliminate VAM from the mix. Is this a cost issue? SMS will not solve the problem, by itself. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Hi Ted, I do have other SMS-managed data. I'm just doing the conversion a bit backwards. ;-) I can see that the issue, in my current environment, is that I tell VAM (CA-Allocate) to bail out of it's ASR (EXIT CODE(0)) if it sees a non-null Storage Class. We are hoping to be able to eliminate VAM from the mix. My intent with the "extent problem" is to identify which dsns are being twiddled by VAM and (for System Temporary dsns) update the space allocation in the JCL. For permanent dsns being change by VAM, I can either change the JCL to specify data class, or let SMS just add additional volumes. Thanks for the reply! Sounds like SMS-managed System Temporary files is a good thing. BobL > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL > Sent: Tuesday, January 20, 2009 2:15 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > >My options seem to be: > >1) plow thru all System Temporary allocations being increased by > >CA-Allocate and update the JCL, or > >2) Leave System Temporary datasets non-SMS. > > At the risk of repeating myself, what makes you think these > are mutually exclusive? > Are you assuming that you can't do both in an SMS > environment? You can. > Are you assuming SMS will manage the 'extent problem', and > you can get rid of the product? You can't. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access > instructions, send email to lists...@bama.ua.edu with the > message: GET IBM-MAIN INFO Search the archives at > http://bama.ua.edu/archives/ibm-main.html > > -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Amid Economic Turbulence, Mainframes Counter IT Cost-Cutting Trend
Swoyer makes some good observations ... http://www.esj.com/news/article.aspx?EditorialsID=3475 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
On Tue, 20 Jan 2009 16:39:32 -0500, Thompson, Steve wrote: > >Done found it, and fixed it. The "macro" was RES for RESET which is what >I type at the top of edit/view sessions when there are junk messages at >the top that I don't care about... (among other times). Some how I >managed to get it picked up as an initial edit macro. > >Regards, >Steve Thompson > >PS. I will keep that REXX around. Seems I have a fat finger problem from >time to time. > You're not alone. I've found telling someone to execute the exec is easier than trying to explain the settings to check / change in ISPF 3.4. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>> Are you assuming SMS will manage the 'extent problem', and you can get rid >> of the product? You can't. >Maybe not totally, but space constraint relief, extended format and >multi-volume can go a long way. Yes! But! The OP appeared to assume that: 1. You can't use CA-Allocate with SMS. 2. SMS will replace the functionality. >We never had any ISV product for this and x37 abends did occur. Not frequently >and we've always been small. That said, there hasn't been a x37 abend since >SMS came in that wasn't the result of a grossly low SPACE parameter. Yes! But! That's what these products are for. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
> Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. Maybe not totally, but space constraint relief, extended format and multi-volume can go a long way. We never had any ISV product for this and x37 abends did occur. Not frequently and we've always been small. That said, there hasn't been a x37 abend since SMS came in that wasn't the result of a grossly low SPACE parameter. Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, January 20, 2009 1:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets >My options seem to be: >1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or >2) Leave System Temporary datasets non-SMS. At the risk of repeating myself, what makes you think these are mutually exclusive? Are you assuming that you can't do both in an SMS environment? You can. Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Tuesday, January 20, 2009 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Edit Macro Put this exec in a library and execute it: /* rexx */ Address ISPEXEC /* "VERASE (ZUSERMAC) PROFILE" */ /* all edit sessions */ "VGET (ZDAEMAC) PROFILE"/* ispf 3.4 initial macro */ "VERASE (ZDAEMAC) PROFILE" /* ispf 3.4 initial macro */ If RC = 0 then do If ZDAEMAC = '' then , zedlmsg = 'Initial macro removed!' Else zedlmsg = 'Initial macro removed! It was "' || ZDAEMAC || '"' End Else zedlmsg = 'Error removing initial macro, it probably did not exist' "SETMSG MSG(ISRZ000)" Let me know if it fixes your problem. Done found it, and fixed it. The "macro" was RES for RESET which is what I type at the top of edit/view sessions when there are junk messages at the top that I don't care about... (among other times). Some how I managed to get it picked up as an initial edit macro. Regards, Steve Thompson PS. I will keep that REXX around. Seems I have a fat finger problem from time to time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
On Tue, 20 Jan 2009 15:19:50 -0500, Thompson, Steve wrote: >I am still scratching my head as to how that got picked up as an initial >macro. But, it is no more. > In my experience... type ahead with your emulator. The initial panel pops up for a flat file edit and you never see or notice it because you are typing fast. Then you edit a PDS and never see the panel, so you don't know it's there. I usually have to help someone fix the same problem at least a couple of times a year. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
On Tue, 20 Jan 2009 15:05:08 -0500, Thompson, Steve wrote: >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Betsy Jeffery >Sent: Tuesday, January 20, 2009 9:36 AM >To: IBM-MAIN@bama.ua.edu >Subject: ISPF Edit Macro > >I found the culprit. > > >Well, I have been following this with some interest, because it is >happening to me again on one of my 3 IDs (has been for about 2 weeks >now). > >It happens with PDS before I even select a member (ISRUDSM panel says >"Initial edit macro set"). I haven't tried a DSORG=PS file yet. > >And it is always from 3.4 or DSLIST panels, not EDIT (=2) or View (=1). > >I have been in the archives (took me quite some time to get connected >for some reason and searches have been very slow). I did not find >anything that helped -- and in 2007 when I had this happen, it was >because of an artifact left over from IPCS usage (a variable that had >junk in it). Doesn't seem to be the case this time. So far I can't get >ISPF to tell me what it thinks this Initial Macro name is. > >So, if anyone else has any ideas, I'd be interested. > Put this exec in a library and execute it: /* rexx */ Address ISPEXEC /* "VERASE (ZUSERMAC) PROFILE" */ /* all edit sessions */ "VGET (ZDAEMAC) PROFILE"/* ispf 3.4 initial macro */ "VERASE (ZDAEMAC) PROFILE" /* ispf 3.4 initial macro */ If RC = 0 then do If ZDAEMAC = '' then , zedlmsg = 'Initial macro removed!' Else zedlmsg = 'Initial macro removed! It was "' || ZDAEMAC || '"' End Else zedlmsg = 'Error removing initial macro, it probably did not exist' "SETMSG MSG(ISRZ000)" Let me know if it fixes your problem. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>My options seem to be: >1) plow thru all System Temporary allocations being increased by CA-Allocate >and update the JCL, or >2) Leave System Temporary datasets non-SMS. At the risk of repeating myself, what makes you think these are mutually exclusive? Are you assuming that you can't do both in an SMS environment? You can. Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Tuesday, January 20, 2009 2:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Edit Macro Whenever you get a short message that you don't understand, you should press PF1. After the "Initial edit macro set" you would have gotten An initial edit macro is defined for actions Edit and View. Enter a "/" in the prompt field for Edit or View Actions to display or change Edit/View entry fields. Ever play ADVENTURE? I think there was a little monkey in the tree where you have the door you need to open. The little monkey says to you, "The password is needed." Well of course the password is needed. So where do I find this needed password!? Well, it was not until I saw an example of what they meant... Senility: it is a state of mind. Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MODIFY VTAMOPTS,TCPNAME=
I guess I don't know the complete effect of setting this value. If there's a chance that setting it could disrupt our network I wanted to be able to change it back. Luke -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Tuesday, January 20, 2009 3:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: MODIFY VTAMOPTS,TCPNAME= On Tue, 20 Jan 2009 12:55:37 -0600, Rabbe, Luke wrote: >... >I modified VTAMOPTS to give TCPNAME a value. >... >Now I want to change it back to the initial value of *BLANKS*, but VTAM >won't let me enter a blank or the value *BLANKS* in the modify command. >Has anyone ever done this or have any suggestions? ... I looked and don't see that as an option. It's tricky because TCPNAME is one of three sort of equivalent options: TCPNAME, HOSTNAME, IPADDR. One of these, but any one of them, is required if your Enterprise Extender XCA def does not specify an IP addr or host name of its source VIPA. None of them is required if your EE XCA defs specify IPADDR or HOSTNAME. Given that, I'm not sure what you are trying to accomplish by setting the TCPNAME back to blanks.Are you trying to make sure that any EE XCA def without HOSTNAME or IPADDR fails? I think you could just as well set TCPNAME to a bogus name. Then any EE XCA defs without HOSTANAME or IPADDR would be ineffective because the default stack would not be found. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Bob, > >I've got a product (CA-Allocate) that allows dynamic increasing of > the allocation of System Temporary datasets. This current state. > >As I move to SMS, I see that only a STORCLAS is assigned for these. > If I understand correctly, this means that the space coded in the JCL is > what you get. > CA-Allocate can override the space amounts in alloc environment, no difference. Same applies to secondary space increase/reduction in extend environment. You would want to exclude sortwork datasets since *sort does its own thing. >My options seem to be: 1) plow thru all System Temporary allocations > being increased by CA-Allocate and update the JCL, or 2) Leave System > Temporary datasets non-SMS. > >Am I on the right track? Do most of y'all make System Temporary dsns > SMS-managed? > Temporary datasets were the first datasets I put under sms in the early 90's. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MODIFY VTAMOPTS,TCPNAME=
On Tue, 20 Jan 2009 12:55:37 -0600, Rabbe, Luke wrote: >... >I modified VTAMOPTS to give TCPNAME a value. >... >Now I want to change it back to the initial value of *BLANKS*, but VTAM >won't let me enter a blank or the value *BLANKS* in the modify command. >Has anyone ever done this or have any suggestions? ... I looked and don't see that as an option. It's tricky because TCPNAME is one of three sort of equivalent options: TCPNAME, HOSTNAME, IPADDR. One of these, but any one of them, is required if your Enterprise Extender XCA def does not specify an IP addr or host name of its source VIPA. None of them is required if your EE XCA defs specify IPADDR or HOSTNAME. Given that, I'm not sure what you are trying to accomplish by setting the TCPNAME back to blanks.Are you trying to make sure that any EE XCA def without HOSTNAME or IPADDR fails? I think you could just as well set TCPNAME to a bogus name. Then any EE XCA defs without HOSTANAME or IPADDR would be ineffective because the default stack would not be found. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>In every instance I've configured DFSMS, DFSMS has always managed System Temporary Data Sets. 1. This is a good thing. >ISV products that provide dynamic enhancements to the DFSMS structure >(CA-Alloc and MAINVIEW SRM Allocation/StopX37/II are two such products) 2. These products are independent of SMS. They will work with non-SMS data, as well. 3. As I've said, why restrict them to temporary datasets. The last shop I worked at had them for temp, perm, prod & test. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
In every instance I've configured DFSMS, DFSMS has always managed System Temporary Data Sets. ISV products that provide dynamic enhancements to the DFSMS structure (CA-Alloc and MAINVIEW SRM Allocation/StopX37/II are two such products) will continue to dynamically increase these and any other type of data set. The space coded in the JCL is always going to take precedence during initial allocation; unless your ISV product is coded to alter the primary and secondary amounts during allocation, but the ISV code can continue to add volumes, extend the data set if needed, reduce the secondary if needed, or whatever is required based on your install setups. In some cases the ISV product is more efficient in its methods of recovery than DFSMS. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lester, Bob Sent: Tuesday, January 20, 2009 3:35 PM To: IBM-MAIN@bama.ua.edu Subject: SMS and System Temporary Datasets Hi Folks, I've got a product (CA-Allocate) that allows dynamic increasing of the allocation of System Temporary datasets. This current state. As I move to SMS, I see that only a STORCLAS is assigned for these. If I understand correctly, this means that the space coded in the JCL is what you get. My options seem to be: 1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or 2) Leave System Temporary datasets non-SMS. Am I on the right track? Do most of y'all make System Temporary dsns SMS-managed? Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>I've got a product (CA-Allocate) that allows dynamic increasing of the >allocation of System Temporary datasets. This current state. >As I move to SMS, I see that only a STORCLAS is assigned for these. If I >understand correctly, this means that the space coded in the JCL is what you >get. I haven't used it since it was called BrightStor, but it (and STOPx37), would still manage the extent processing, SMS managed or not. SMS will not do it for you. You still need the product. PS: Why are you using it for only temporary datasets? It works for permanent, as well. And, in some production environments, it's a life-saver! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
On Tue, 20 Jan 2009 15:05:08 -0500, Thompson, Steve wrote: > >It happens with PDS before I even select a member (ISRUDSM panel says >"Initial edit macro set"). I haven't tried a DSORG=PS file yet. > >And it is always from 3.4 or DSLIST panels, not EDIT (=2) or View (=1). Whenever you get a short message that you don't understand, you should press PF1. After the "Initial edit macro set" you would have gotten An initial edit macro is defined for actions Edit and View. Enter a "/" in the prompt field for Edit or View Actions to display or change Edit/View entry fields. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
OP implied SAS was already available at the site :) IF so, MXG is a minor additional expense in the grand scheme of things :) Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Tuesday, January 20, 2009 12:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: TS7700 Historical data (BVIR) --- We're definitely talking huge $$, here. MXG is an EXPENSIVE $1500/annum as a site licence. How many multi-millions site can affor such an outlay? -- What about the cost of SAS?? That's not exactly "pocket change"!! -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Well, having not gotten a straight answer to a straight question, I did a quick test. I had a GDG: uid.GDGTEST.G0001V00 uid.GDGTEST.G0002V00 uid.GDGTEST.G0003V00 uid.GDGTEST.G0004V00 I then allocated uid.GDGTEST.G0005V03 And I ended up with uid.GDGTEST.G0001V00 uid.GDGTEST.G0002V00 uid.GDGTEST.G0003V00 uid.GDGTEST.G0004V00 uid.GDGTEST.G0005V03 Which shows that you do not have to go through V00, V01 and V02 before getting to V03. However, I did get some other results that I found surprising. I was able to allocate uid.GDGTEST.G0002V05 uid.GDGTEST.G0002V06 uid.GDGTEST.G0002V01 uid.GDGTEST.G0003V01 which ended up cataloged but not as part of the GDG. GDGALL processing correctly allocates me uid.TESTGDG.G0005V03 uid.TESTGDG.G0004V00 uid.TESTGDG.G0003V00 uid.TESTGDG.G0002V00 uid.TESTGDG.G0001V00 Yet a DSLIST lists me uid.TESTGDG.G0001V00 uid.TESTGDG.G0002V00 uid.TESTGDG.G0002V01 uid.TESTGDG.G0002V05 uid.TESTGDG.G0002V06 uid.TESTGDG.G0003V00 uid.TESTGDG.G0003V01 uid.TESTGDG.G0004V00 uid.TESTGDG.G0005V03 I didn't think that I would be able to catalog non-GDG datasets with the same prefix as the GDG base. Have I missed something? > Date: Tue, 20 Jan 2009 14:08:27 -0500 > From: jayare...@hotmail.com > Subject: Re: GDG Question > To: IBM-MAIN@bama.ua.edu > > Yes, it's understood that there is only one version cataloged at any one > time. > > The question remains: Must version numbers be assigned incrementally? > > > > Date: Tue, 20 Jan 2009 13:57:44 -0500 > > From: stars...@mindspring.com > > Subject: Re: GDG Question > > To: IBM-MAIN@bama.ua.edu > > > > My understanding is that you would only have ONE verions number at any > > given time. > > > > I have not seen a case where you would have G0001V00, and G0001V01 and > > G0001V02. Only the G0001V02 would be in the catalog. Any other > versions would not. > > > > Though I could be wrong, but that is currently my understanding. Version > > only allows you to replace the current Gen Number without losing the oldest > GDG (due to roll off). > > > > > > Lizette > > > > > > -Original Message- > > >From: J R jayare...@hotmail.com > > >Sent: Jan 20, 2009 1:49 PM > > >To: IBM-MAIN@bama.ua.edu > > >Subject: Re: GDG Question > > > > > >> The Version numbers are ascending (00 to 99). I have not known > > >> of a case where you would create a descending version (99 to 00). > > > > > > > > >Well, I can't imagine needing to create up to 99 replacement versions > > >either. > > > > > >However, if I were to use this feature, I could well imagine making > > >the version number meaningful. Examples might be day-of-week, > > >month-of-year, etc. In such a scenario they could well end up > > >going backwards ... V06 (Friday) to V02 (Monday) maybe. > > > > > >So, the question stands: May version numbers be created out > > >of sequence and randomly? > > > > > > > > >> Date: Tue, 20 Jan 2009 13:29:56 -0500 > > >> From: stars...@mindspring.com > > >> Subject: Re: GDG Question > > >> To: IBM-MAIN@bama.ua.edu > > >> > > >> The Version numbers are ascending (00 to 99). I have not known of a case > > >> where you would create a descending version (99 to 00). > > >> > > >> Lizette > > >> > > >> > > >> > > >> > > > >> >> The Vyy is the Version Number ... (allowing you to replace it up to > > >> >> 99 times). > > >> > > > >> > > > >> >Are you saying that replacement versions may only be created in > > >> >ascending sequence? > > >> > > > >> > > > >> >> > > >> >> >So what your saying is the the LOCATE/CAMLIST macros (and others I > > >> >> >suppose) > > >> >> >never even look at the Vxx part of the DSN. > > >> >> >Your usage of it is interesting, never thought of it myself, but > > >> >> >lord knows > > >> >> >I could have used it! > > >> >> > > > >> >> >Thank You, > > >> >> > > >> >> They look at and use it. It is just that when you catalog a GVyy > > >> >> it will replace an existent GVyy entry. The Vyy is the Version > > >> >> Number of the G dataset (allowing you to replace it up to 99 > > >> >> times). There can be only one version of each generation. To do this > > >> >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the > > >> >> GDGBASE(x) Relative type name. > > >> >> _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS and System Temporary Datasets
Hi Folks, I've got a product (CA-Allocate) that allows dynamic increasing of the allocation of System Temporary datasets. This current state. As I move to SMS, I see that only a STORCLAS is assigned for these. If I understand correctly, this means that the space coded in the JCL is what you get. My options seem to be: 1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or 2) Leave System Temporary datasets non-SMS. Am I on the right track? Do most of y'all make System Temporary dsns SMS-managed? Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
>As of right now one cannot define resource groups in terms of software MSUs. Yes. You can. It's just math. Each generation of z is just another 0.9. Just, divide by 0.9, 0.81, 0.72, etc. So, again another lesson for the student, glasshoppa! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
>What about the cost of SAS?? That's not exactly "pocket change"!! 1. The original post, asked if you already had SAS. There was nothing stating that you should go out and buy it. 2. SAS is available with sub-capacity licencing options. 3. SAS is available (and cheaper) on alternate platforms. So is MXG. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
-- -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman You should have seen how they were managed in a CVOL environment! Chewing gum, bailing wire, spit a and LOT of prayers! . . . So, does that mean the demise of CVOLs predated the availability of duct tape? :-) -jc- --- No, only that duct tape was cheaper than CVOL maintenance/upgrades. :-) -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
--- We're definitely talking huge $$, here. MXG is an EXPENSIVE $1500/annum as a site licence. How many multi-millions site can affor such an outlay? -- What about the cost of SAS?? That's not exactly "pocket change"!! -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
Except that the CPU service units used in controlling resource groups
are the hardware service units. I believe that the original poster
wants to define based on the software MSUs used for sub-capacity
pricing. It just appears to me that he's trying to control software
costs. That's just a guess since it wasn't specified. As of right now
one cannot define resource groups in terms of software MSUs.
Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Tuesday, January 20, 2009 11:06 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Controlling use of MSU's with WLM
>
> >You can use resource groups for percentage of LPAR share but I would
like
> to do it on MSU value.
>
> Unless they changed it, since I've last been involved with WLM,
resource
> groups are defined as unnormalised CPU service units.
> Since MSU stands for 'Millions of Service Units', I'll leave the
> calculation up to the student. (8-{]}
>
> -
> Too busy driving to stop for gas!
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com
NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS Mount Points
Thanks all. >>> "Bobbie Jo" 1/20/2009 2:56 PM >>> There should be a member in your new 1.9 "cpac.parmlib(bpxprm*)" that has exactly this info in it. - Original Message - From: "Matt Dazzo" Newsgroups: bit.listserv.ibm-main To: Sent: Tuesday, January 20, 2009 2:50 PM Subject: HFS Mount Points I have installed z1.9 and working on the configuration. When updating BPXPRMXX how do I determine what the mount point is of these new HFS files. Can't find this info in any manual or the archives. Thanks Matt SYS1.ZOS19.OMVS.JAVA31V5 SYS1.ZOS19.OMVS.JAVA31V6 SYS1.ZOS19.OMVS.JAVA64V5 SYS1.ZOS19.OMVS.JAVA64V6 SYS1.ZOS19.OMVS.JV390 SYS1.ZOS19.OMVS.SHPEROOT SYS1.ZOS19.OMVS.SHPHROOT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Field, Alan C. Sent: Tuesday, January 20, 2009 2:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Edit Macro I've captured the wisdom of this list over the years on this problem. Here's my notes: And for those poor souls who inadvertantly set the Initial macro value and now get a message from 3.4 doing Edit or View ... >From the extended member list ... ISPF 3.4 dataset list ... E or M against PDS dataset Select member (put an S or an E) and put a "/" in the prompt field of the selected member. e.g. Command ===> Name Prompt Size e AMSALT /7 1 _ AMSDEF 15 2 and up will come that magic popup screen ... And up pops. RES I am still scratching my head as to how that got picked up as an initial macro. But, it is no more. Thank you. Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
I've captured the wisdom of this list over the years on this problem. Here's my notes: And for those poor souls who inadvertantly set the Initial macro value and now get a message from 3.4 doing Edit or View ... >From the extended member list ... ISPF 3.4 dataset list ... E or M against PDS dataset Select member (put an S or an E) and put a "/" in the prompt field of the selected member. e.g. Command ===> Name Prompt Size e AMSALT /7 1 _ AMSDEF 15 2 and up will come that magic popup screen ... now you can correct the Initial Macro, Format or profile setting. An easier way? On the COMMAND line enter IMACRO NONE Are you trying to execute an ISPF MACRO called RE or is this an error? If this is an error, it is usually due to typing in something like RES (only it is RE) and it is in the ISPF Opt 3.4 Window when selecting datasets. It stays there until you erase it. If this is an error (not a requested MACRO) then do the following: In ISPF OPT2 check the fields towards the bottom of the panel and see if the MACRO has RE in it. If it does, erase it. In ISPF OPT 3.4 - bring up one of the datasets you are having problems with RE. On the line next to the dataset name enterE / Or if it is a PDS E /(X)--> X does not need to exist This should pop up the a panel. See if the first line in the panel has RE in it. If it does erase it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Tuesday, January 20, 2009 14:05 To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Edit Macro -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Betsy Jeffery Sent: Tuesday, January 20, 2009 9:36 AM To: IBM-MAIN@bama.ua.edu Subject: ISPF Edit Macro I found the culprit. Well, I have been following this with some interest, because it is happening to me again on one of my 3 IDs (has been for about 2 weeks now). It happens with PDS before I even select a member (ISRUDSM panel says "Initial edit macro set"). I haven't tried a DSORG=PS file yet. And it is always from 3.4 or DSLIST panels, not EDIT (=2) or View (=1). I have been in the archives (took me quite some time to get connected for some reason and searches have been very slow). I did not find anything that helped -- and in 2007 when I had this happen, it was because of an artifact left over from IPCS usage (a variable that had junk in it). Doesn't seem to be the case this time. So far I can't get ISPF to tell me what it thinks this Initial Macro name is. So, if anyone else has any ideas, I'd be interested. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Betsy Jeffery Sent: Tuesday, January 20, 2009 9:36 AM To: IBM-MAIN@bama.ua.edu Subject: ISPF Edit Macro I found the culprit. Well, I have been following this with some interest, because it is happening to me again on one of my 3 IDs (has been for about 2 weeks now). It happens with PDS before I even select a member (ISRUDSM panel says "Initial edit macro set"). I haven't tried a DSORG=PS file yet. And it is always from 3.4 or DSLIST panels, not EDIT (=2) or View (=1). I have been in the archives (took me quite some time to get connected for some reason and searches have been very slow). I did not find anything that helped -- and in 2007 when I had this happen, it was because of an artifact left over from IPCS usage (a variable that had junk in it). Doesn't seem to be the case this time. So far I can't get ISPF to tell me what it thinks this Initial Macro name is. So, if anyone else has any ideas, I'd be interested. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS Mount Points
Should be in the CPAC.PARMLIB from the serverpac. Member BPXPRM??
Dave Gibney
Information Technology Services
Washington State Univsersity
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)
Sent: Tuesday, January 20, 2009 11:55 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: HFS Mount Points
We don't have Java, but here's a couple of the mount points for our
system:
MOUNT FILESYSTEM('OMVS.TST1.SHPHROOT')
MOUNTPOINT('/usr/lpp/php')
TYPE(HFS) MODE(RDWR)
MOUNT FILESYSTEM('OMVS.TST1.SHPEROOT')
MOUNTPOINT('/usr/lpp/perl')
TYPE(HFS) MODE(RDWR)
We also have a JV390 link, but I think this one is old. Here it is:
MOUNT FILESYSTEM('OMVS.JV390')
MOUNTPOINT('/usr/lpp/java')
TYPE(HFS) MODE(RDWR)
Hope this helps.
From: IBM Mainframe Discussion List on behalf of Matt Dazzo
Sent: Tue 1/20/2009 2:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: HFS Mount Points
I have installed z1.9 and working on the configuration. When updating
BPXPRMXX how do I determine what the mount point is of these new HFS
files. Can't find this info in any manual or the archives. Thanks Matt
SYS1.ZOS19.OMVS.JAVA31V5
SYS1.ZOS19.OMVS.JAVA31V6
SYS1.ZOS19.OMVS.JAVA64V5
SYS1.ZOS19.OMVS.JAVA64V6
SYS1.ZOS19.OMVS.JV390
SYS1.ZOS19.OMVS.SHPEROOT
SYS1.ZOS19.OMVS.SHPHROOT
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS Mount Points
We don't have Java, but here's a couple of the mount points for our system:
MOUNT FILESYSTEM('OMVS.TST1.SHPHROOT')
MOUNTPOINT('/usr/lpp/php')
TYPE(HFS) MODE(RDWR)
MOUNT FILESYSTEM('OMVS.TST1.SHPEROOT')
MOUNTPOINT('/usr/lpp/perl')
TYPE(HFS) MODE(RDWR)
We also have a JV390 link, but I think this one is old. Here it is:
MOUNT FILESYSTEM('OMVS.JV390')
MOUNTPOINT('/usr/lpp/java')
TYPE(HFS) MODE(RDWR)
Hope this helps.
From: IBM Mainframe Discussion List on behalf of Matt Dazzo
Sent: Tue 1/20/2009 2:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: HFS Mount Points
I have installed z1.9 and working on the configuration. When updating BPXPRMXX
how do I determine what the mount point is of these new HFS files. Can't find
this info in any manual or the archives. Thanks Matt
SYS1.ZOS19.OMVS.JAVA31V5
SYS1.ZOS19.OMVS.JAVA31V6
SYS1.ZOS19.OMVS.JAVA64V5
SYS1.ZOS19.OMVS.JAVA64V6
SYS1.ZOS19.OMVS.JV390
SYS1.ZOS19.OMVS.SHPEROOT
SYS1.ZOS19.OMVS.SHPHROOT
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
HFS Mount Points
I have installed z1.9 and working on the configuration. When updating BPXPRMXX how do I determine what the mount point is of these new HFS files. Can't find this info in any manual or the archives. Thanks Matt SYS1.ZOS19.OMVS.JAVA31V5 SYS1.ZOS19.OMVS.JAVA31V6 SYS1.ZOS19.OMVS.JAVA64V5 SYS1.ZOS19.OMVS.JAVA64V6 SYS1.ZOS19.OMVS.JV390 SYS1.ZOS19.OMVS.SHPEROOT SYS1.ZOS19.OMVS.SHPHROOT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
Yup, probably the best deal in software costs ever, and I include open source in this statement :) Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, January 20, 2009 11:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TS7700 Historical data (BVIR) >Why would the site that has SAS and wants to do customized reporting not have MXG? We're definitely talking huge $$, here. MXG is an EXPENSIVE $1500/annum as a site licence. How many multi-millions site can affor such an outlay? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman > > You should have seen how they were managed in a CVOL environment! > Chewing gum, bailing wire, spit a and LOT of prayers! . . . So, does that mean the demise of CVOLs predated the availability of duct tape? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
>Why would the site that has SAS and wants to do customized reporting not have >MXG? We're definitely talking huge $$, here. MXG is an EXPENSIVE $1500/annum as a site licence. How many multi-millions site can affor such an outlay? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GDGs, Long Dataset Names, Generated DSNs, etc.
I've been following this extensive discussion of GDG's and the side notes related to generating unique dataset names, long dataset names, GDG limits and other limitations. These are all just characteristics of the underlying architecture, which is unlikely to change. What you do with that architecture is only limited by your imagination. IBM provided a really nice facility for doing whatever you want with these 'limitations'. If you want some added features, write a subsystem. There's really not much to it. I'm surprised some enterprising person, group or organization hasn't done so already. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Well... if the system allowed larger limits then we'd probably use them. GDG catalog processing has always been something of a kludge (my opinion... sorry if you're lurking, Mark). GDG sphere records are too big for their own good, and GDS extension records (if you have too many datasets to fit within the sphere's MAXLRECL) are created one at a time. Years ago those extension records were never deleted until the entire GDG was deleted, but maybe that's changed -- it's been awhile since I last looked. I think of the implementation as a dancing bear; nobody cares how well the bear dances, it's simply wondrous that it dances at all. - You should have seen how they were managed in a CVOL environment! Chewing gum, bailing wire, spit a and LOT of prayers! Between BLDL-like searches and linked-lists on disk, they were a PITA! -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
-
Total agreement! What I wish were a possibility would be an totally new
construct with similar semantics to a GDG. But the LLQ would somehow
encode the creation date & time (perhaps to the nearest second). No, I
don't know how to encode that into 8 "printable" characters. The
semantics I would like would be the ability to get the "current", "-1",
and so on entries without knowing the actual LLQ. And the ability to
create a new "generation" symbolically (likeunto the +1). Of course, the
problem is once again, what is the "date & time". Submition, or job
initiation or step initiation or dataset open or ...? Oh, and should the
encoding be for local time or GMT? OK, it's a stupid idea.
--
Not such a stupid idea at all. At Clearing, we "archived" huge numbers
of small reports every day. We developed a routine that incorporated the
last 6 bytes of the TOD clock into the DSNAME, as the last two
qualifiers. The dataset was ultimately created by a subroutine ("DYNAM",
from the CBTTAPE site) that was called by the report generator program.
The actual report name, time and date were entered into a VSAM database,
along with the true DSNAME, and made available to users via a
custom-built search/print program. FDRABR, then later, HSM, managed the
actual reports' location and the VSAM cluster was periodically reorged,
because of the large number of splits even when we used Sequential
Insert Strategy. A relatively simple-minded compression algorithm
reduced the report sizes' by about 70%, on the average. Rather than use
hard-coded values for dsnames, we used the PARMLIB interface, so we
didn't have to re-link anything if we changed any of the "hard-coded"
values.
--
Rick
--
Remember that if you’re not the lead dog, the view never changes.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Yes, it's understood that there is only one version cataloged at any one time. The question remains: Must version numbers be assigned incrementally? > Date: Tue, 20 Jan 2009 13:57:44 -0500 > From: stars...@mindspring.com > Subject: Re: GDG Question > To: IBM-MAIN@bama.ua.edu > > My understanding is that you would only have ONE verions number at any given > time. > > I have not seen a case where you would have G0001V00, and G0001V01 and > G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. > > Though I could be wrong, but that is currently my understanding. Version only > allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). > > > Lizette > > > -Original Message- > >From: J R jayare...@hotmail.com > >Sent: Jan 20, 2009 1:49 PM > >To: IBM-MAIN@bama.ua.edu > >Subject: Re: GDG Question > > > >> The Version numbers are ascending (00 to 99). I have not known > >> of a case where you would create a descending version (99 to 00). > > > > > >Well, I can't imagine needing to create up to 99 replacement versions > >either. > > > >However, if I were to use this feature, I could well imagine making > >the version number meaningful. Examples might be day-of-week, > >month-of-year, etc. In such a scenario they could well end up > >going backwards ... V06 (Friday) to V02 (Monday) maybe. > > > >So, the question stands: May version numbers be created out > >of sequence and randomly? > > > > > >> Date: Tue, 20 Jan 2009 13:29:56 -0500 > >> From: stars...@mindspring.com > >> Subject: Re: GDG Question > >> To: IBM-MAIN@bama.ua.edu > >> > >> The Version numbers are ascending (00 to 99). I have not known of a case > >> where you would create a descending version (99 to 00). > >> > >> Lizette > >> > >> > >> > >> > > >> >> The Vyy is the Version Number ... (allowing you to replace it up to 99 > >> >> times). > >> > > >> > > >> >Are you saying that replacement versions may only be created in ascending > >> >sequence? > >> > > >> > > >> >> > >> >> >So what your saying is the the LOCATE/CAMLIST macros (and others I > >> >> >suppose) > >> >> >never even look at the Vxx part of the DSN. > >> >> >Your usage of it is interesting, never thought of it myself, but lord > >> >> >knows > >> >> >I could have used it! > >> >> > > >> >> >Thank You, > >> >> > >> >> They look at and use it. It is just that when you catalog a GVyy > >> >> it will replace an existent GVyy entry. The Vyy is the Version > >> >> Number of the G dataset (allowing you to replace it up to 99 > >> >> times). There can be only one version of each generation. To do this > >> >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the > >> >> GDGBASE(x) Relative type name. > >> >> _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Utility for LE Options?
SHOWzOS and COBANAL display the CEExOPT settings but not for CEEROPT. However the code should also work for CEEROPT unless you modify it and load the CEEROPT entry. Starting with z/OS R9 (?) IBM deliver a macro (CEEOCB?) to map the CEExOPT. Regards Roland >Is there some utility out there where you supply as input the CEEROPT load >module, and the utility reports on what options it specifies? > > I'd hate to write one only to find out that I re-invented the wheel... > > Thanks. > >Adam Johanson >IMS Systems Programming >USAA > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I forgot to add, the reason would be that DSN(0) would never know which Version to pull in should there be more than one version. That is why many shops want a different process for getting dates and times into data set names. Lizette > >My understanding is that you would only have ONE verions number at any given >time. > >I have not seen a case where you would have G0001V00, and G0001V01 and >G0001V02. Only the G0001V02 would be in the catalog. Any other versions >would not. > >Though I could be wrong, but that is currently my understanding. Version only >allows you to replace the current Gen Number without losing the oldest GDG >(due to roll off). > > >Lizette > > >-Original Message- >>From: J R >>Sent: Jan 20, 2009 1:49 PM >>To: IBM-MAIN@bama.ua.edu >>Subject: Re: GDG Question >> >>> The Version numbers are ascending (00 to 99). I have not known >>> of a case where you would create a descending version (99 to 00). >> >> >>Well, I can't imagine needing to create up to 99 replacement versions either. >> >> >>However, if I were to use this feature, I could well imagine making >>the version number meaningful. Examples might be day-of-week, >>month-of-year, etc. In such a scenario they could well end up >>going backwards ... V06 (Friday) to V02 (Monday) maybe. >> >>So, the question stands: May version numbers be created out >>of sequence and randomly? >> >> >>> Date: Tue, 20 Jan 2009 13:29:56 -0500 >>> From: stars...@mindspring.com >>> Subject: Re: GDG Question >>> To: IBM-MAIN@bama.ua.edu >>> >>> The Version numbers are ascending (00 to 99). I have not known of a case >>> where you would create a descending version (99 to 00). >>> >>> Lizette >>> >>> >>> >>> > >>> >> The Vyy is the Version Number ... (allowing you to replace it up to 99 >>> >> times). >>> > >>> > >>> >Are you saying that replacement versions may only be created in ascending >>> >sequence? >>> > >>> > >>> >> >>> >> >So what your saying is the the LOCATE/CAMLIST macros (and others I >>> >> >suppose) >>> >> >never even look at the Vxx part of the DSN. >>> >> >Your usage of it is interesting, never thought of it myself, but lord >>> >> >knows >>> >> >I could have used it! >>> >> > >>> >> >Thank You, >>> >> >>> >> They look at and use it. It is just that when you catalog a GVyy >>> >> it will replace an existent GVyy entry. The Vyy is the Version >>> >> Number of the G dataset (allowing you to replace it up to 99 >>> >> times). There can be only one version of each generation. To do this >>> >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the >>> >> GDGBASE(x) Relative type name. >>> >> >> >> >> >> >> >>_ >>Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. >>http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
My understanding is that you would only have ONE verions number at any given time. I have not seen a case where you would have G0001V00, and G0001V01 and G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. Though I could be wrong, but that is currently my understanding. Version only allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). Lizette -Original Message- >From: J R >Sent: Jan 20, 2009 1:49 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: GDG Question > >> The Version numbers are ascending (00 to 99). I have not known >> of a case where you would create a descending version (99 to 00). > > >Well, I can't imagine needing to create up to 99 replacement versions either. > >However, if I were to use this feature, I could well imagine making >the version number meaningful. Examples might be day-of-week, >month-of-year, etc. In such a scenario they could well end up >going backwards ... V06 (Friday) to V02 (Monday) maybe. > >So, the question stands: May version numbers be created out >of sequence and randomly? > > >> Date: Tue, 20 Jan 2009 13:29:56 -0500 >> From: stars...@mindspring.com >> Subject: Re: GDG Question >> To: IBM-MAIN@bama.ua.edu >> >> The Version numbers are ascending (00 to 99). I have not known of a case >> where you would create a descending version (99 to 00). >> >> Lizette >> >> >> >> > >> >> The Vyy is the Version Number ... (allowing you to replace it up to 99 >> >> times). >> > >> > >> >Are you saying that replacement versions may only be created in ascending >> >sequence? >> > >> > >> >> >> >> >So what your saying is the the LOCATE/CAMLIST macros (and others I >> >> >suppose) >> >> >never even look at the Vxx part of the DSN. >> >> >Your usage of it is interesting, never thought of it myself, but lord >> >> >knows >> >> >I could have used it! >> >> > >> >> >Thank You, >> >> >> >> They look at and use it. It is just that when you catalog a GVyy >> >> it will replace an existent GVyy entry. The Vyy is the Version >> >> Number of the G dataset (allowing you to replace it up to 99 >> >> times). There can be only one version of each generation. To do this >> >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the >> >> GDGBASE(x) Relative type name. >> >> > > > > > >_ >Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. >http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 12:18 -0600, Tom Marchant wrote: > On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote: > >But the LLQ would somehow > >encode the creation date & time (perhaps to the nearest second). > Dddd.Thhmmss? One second is not fine enough. In a backup application I use Dddd.Thhmmsst -- good enough for today, but not necessarily for tomorrow. Also when you append 18 characters of date/time information to a dataset name you run afoul of our 44-character limitations. It's a small embarrassment when I explain it to the k1dd13z. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MODIFY VTAMOPTS,TCPNAME=
I started VTAM with no TCPNAME specified. A display of VTAMOPTS showed: TCPNAME=*BLANKS* I modified VTAMOPTS to give TCPNAME a value. Now I want to change it back to the initial value of *BLANKS*, but VTAM won't let me enter a blank or the value *BLANKS* in the modify command. Has anyone ever done this or have any suggestions? The Reference Guide doesn't say anything about it. Thank you, Luke -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TS7700 Historical data (BVIR)
On Tue, 13 Jan 2009 13:06:46 -0600, Steve McCulloch wrote: >Has anyone created a SAS macro that maps out the Historical data from the >TS7700 BVIR tool? Barry Merril has created one for MXG. However, this is to >support non-MXG client site and would be used for customized reporting. Why would the site that has SAS and wants to do customized reporting not have MXG? Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
> The Version numbers are ascending (00 to 99). I have not known > of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? > Date: Tue, 20 Jan 2009 13:29:56 -0500 > From: stars...@mindspring.com > Subject: Re: GDG Question > To: IBM-MAIN@bama.ua.edu > > The Version numbers are ascending (00 to 99). I have not known of a case > where you would create a descending version (99 to 00). > > Lizette > > > > > > >> The Vyy is the Version Number ... (allowing you to replace it up to 99 > >> times). > > > > > >Are you saying that replacement versions may only be created in ascending > >sequence? > > > > > >> > >> >So what your saying is the the LOCATE/CAMLIST macros (and others I > >> >suppose) > >> >never even look at the Vxx part of the DSN. > >> >Your usage of it is interesting, never thought of it myself, but lord > >> >knows > >> >I could have used it! > >> > > >> >Thank You, > >> > >> They look at and use it. It is just that when you catalog a GVyy > >> it will replace an existent GVyy entry. The Vyy is the Version > >> Number of the G dataset (allowing you to replace it up to 99 > >> times). There can be only one version of each generation. To do this > >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the > >> GDGBASE(x) Relative type name. > >> _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 17:49 +0100, R.S. wrote: > Is there any other reason? No one wants 365 generations? Well... if the system allowed larger limits then we'd probably use them. GDG catalog processing has always been something of a kludge (my opinion... sorry if you're lurking, Mark). GDG sphere records are too big for their own good, and GDS extension records (if you have too many datasets to fit within the sphere's MAXLRECL) are created one at a time. Years ago those extension records were never deleted until the entire GDG was deleted, but maybe that's changed -- it's been awhile since I last looked. I think of the implementation as a dancing bear; nobody cares how well the bear dances, it's simply wondrous that it dances at all. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
>I have always *tried* to avoid GDGs like the plague that they are. They have their uses, if you understand their quirks. The biggest thing I used them for was SMF dumps. At each switch dump to a GDG. Switch at midnight, consolodate with a simple reference to the base(s). Delete if successful. Don't have to remember any names. GDGs are perfect for this function. I've had other uses, but I would keep them for this one use. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette > >> The Vyy is the Version Number ... (allowing you to replace it up to 99 >> times). > > >Are you saying that replacement versions may only be created in ascending >sequence? > > >> >> >So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) >> >never even look at the Vxx part of the DSN. >> >Your usage of it is interesting, never thought of it myself, but lord knows >> >I could have used it! >> > >> >Thank You, >> >> They look at and use it. It is just that when you catalog a GVyy >> it will replace an existent GVyy entry. The Vyy is the Version >> Number of the G dataset (allowing you to replace it up to 99 >> times). There can be only one version of each generation. To do this >> you must use an Absolute Dataset Name (GDGBASE.GVyy) not the >> GDGBASE(x) Relative type name. >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Hmmm, why wasn't hex used for this "rollover" then if anyone were crazy enough to do it, they could have 65535 generations (GVxx) before rollover. Surely that is enough! I have always *tried* to avoid GDGs like the plague that they are. Guy Gardoit z/OS Systems Programming On Tue, Jan 20, 2009 at 12:20 PM, Robert A. Rosenberg wrote: > At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: > > This brings up a question I've had before. >> >> Why is the 'V00' not made use of? >> >> Why doesn't'GV00 roll over to G0001V01? >> Rather than starting over at G0001V00... >> >> Just a thought >> > > All automatically created files have the v00 version number. The V01-V99 > suffixes are reserved for use in creating replacement versions of a G > Generation when needed (via hard coding the full absolute file name in lieu > of using the (x) Relative Generation Number form of the Dataset name). > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
> The Vyy is the Version Number ... (allowing you to replace it up to 99 > times). Are you saying that replacement versions may only be created in ascending sequence? > Date: Tue, 20 Jan 2009 12:15:46 -0500 > From: hal9...@panix.com > Subject: Re: GDG Question > To: IBM-MAIN@bama.ua.edu > > At 09:29 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: > > >So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) > >never even look at the Vxx part of the DSN. > >Your usage of it is interesting, never thought of it myself, but lord knows > >I could have used it! > > > >Thank You, > > > >Joe Aulph, > >Senior Systems Programmer: > >850-487-8945 > >joe_au...@dcf.state.fl.us > > They look at and use it. It is just that when you catalog a GVyy > it will replace an existent GVyy entry. The Vyy is the Version > Number of the G dataset (allowing you to replace it up to 99 > times). There can be only one version of each generation. To do this > you must use an Absolute Dataset Name (GDGBASE.GVyy) not the > GDGBASE(x) Relative type name. > _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote: > >What I wish were a possibility would be an totally new >construct with similar semantics to a GDG. But the LLQ would somehow >encode the creation date & time (perhaps to the nearest second). No, I >don't know how to encode that into 8 "printable" characters. Dddd.Thhmmss? >The semantics >I would like would be the ability to get the "current", "-1", and so on >entries without knowing the actual LLQ. And the ability to create a new >"generation" symbolically (likeunto the +1). Of course, the problem is >once again, what is the "date & time". Submition, or job initiation or >step initiation or dataset open or ...? I'd say allocation time. >Oh, and should the encoding be for >local time or GMT? GMT. Otherwise you couldn't tell what order they were created. >OK, it's a stupid idea. I don't think so. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 20 Jan 2009, Ted MacNEIL wrote: > > Why doesn't'GV00 roll over to G0001V01? > > Rather than starting over at G0001V00... > > Why does it really matter? > You can only have a max of 255 entries. > Just like 640K was enough memory on a PC, 255 entries is enough! > > - Total agreement! What I wish were a possibility would be an totally new construct with similar semantics to a GDG. But the LLQ would somehow encode the creation date & time (perhaps to the nearest second). No, I don't know how to encode that into 8 "printable" characters. The semantics I would like would be the ability to get the "current", "-1", and so on entries without knowing the actual LLQ. And the ability to create a new "generation" symbolically (likeunto the +1). Of course, the problem is once again, what is the "date & time". Submition, or job initiation or step initiation or dataset open or ...? Oh, and should the encoding be for local time or GMT? OK, it's a stupid idea. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
>If I'm not mistaken, the only recourse with WLM is to change the workload's >importance. No, you can use resource groups to ensure a min/max (or both) for any service class. I've only used them to ensure a minimum for a service class in a constrained environment. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
What do you wish to do if the workload exceeds the maximum? If I'm not mistaken, the only recourse with WLM is to change the workload's importance. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dick de Groot Sent: Tuesday, January 20, 2009 8:34 AM To: IBM-MAIN@bama.ua.edu Subject: Controlling use of MSU's with WLM Is there a way to control the maximum use of MSU's for a specific workload with WLM.You can use resource groups for percentage of LPAR share but i would like to do it on MSU value. -- Met vriendelijke groeten/With kind regards Dick de Groot NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Just a thought All automatically created files have the v00 version number. The V01-V99 suffixes are reserved for use in creating replacement versions of a G Generation when needed (via hard coding the full absolute file name in lieu of using the (x) Relative Generation Number form of the Dataset name). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 09:29 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 02:36 + on 01/20/2009, Ted MacNEIL wrote about Re: GDG Question: >That is because the GDG is in a VSAM catalog. ICF catalogue -- different from VSAM. True. I was using VSAM as the alternative to CVOL catalogs. ICF is still VSAM but just a new way of handling the Catalog (as opposed to Dataset) organization. In the past when CVOL catalogs were used I think you were SOL since there was no rollover ability. I don't recall it ever being a problem, even with CVOLs. I started this business as a JCL jockey in Production Support, log before UCC7 & UCC11 and their sucessors came out. We used CVOLs for almost everything except IMS -- we didn't have CICS, and DB2 wasn't available, yet. We used GDG datasets all the time, and we never had a 'roll over' problem. Since it requires that 10,000 Generations be created before there can be a need to roll the Absolute Generation number over, it would take a while and thus you might never have gotten to G. It is my impression that with CVOL support, the organization of the GDG record type had no provision for a Relative Generation Number that had an lower Absolute Generation number than a prior Relative Generation Number (ie: (0) = G0001 and (-1) = G). I seem to remember that the recommendation was to reset when you got to G9500 or so. This was not that hard a process since a simple rename (using Absolute Generation Numbers) for DASD datasets would reset the numbers and refresh the catalog. For Tape the process was a little more complex since it involved the need to copy the tapes to new volumes under new names. Since the Dataset Name in a Tape HDR1 label was only 17 Characters (not the full 44 Characters) and 9 of these were the .GVxx suffix you could create the new tape using any prefix you wanted. You then did the delete of the old GDG entries and creation of the new ones (and deleted the temporary catalog entries if you had cataloged the new tapes). Thus .GDGNAME.G9500V00 would be copied as .TEMP.GDGNAME.G0001V00 (with only .GDGNAME.G0001V00 being in the tape's HDR1 label), the .GDGNAME.G9500V00 entry (and the rest of the 95XX ones) deleted, and a new .GDGNAME.G0001V00 catalog entry created. Since all of the entries were first deleted, the new entries would be created in the correct order. There might be a need to delete and recreate the GDG Index CVOL entry since I have the impression that it contained the next Generation number to use and thus needed to be reset (since the current list of generations was not consulted in processing a (+1) request. Of course, my memory could be failing. So might mine. It has been so long that I might -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: GDG Question
The interesting question is what the intended use of the "V00" part was ? And if any system actions is taken regarding changes in that part ? Regards, Thomas Berg __ Thomas Berg Specialist IT-U SWEDBANK > -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] För Ted MacNEIL > Skickat: den 20 januari 2009 18:03 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: GDG Question > > > Why doesn't'GV00 roll over to G0001V01? > > Rather than starting over at G0001V00... > > Why does it really matter? > You can only have a max of 255 entries. > Just like 640K was enough memory on a PC, 255 entries is enough! > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access > instructions, send email to lists...@bama.ua.edu with the > message: GET IBM-MAIN INFO Search the archives at > http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
>You can use resource groups for percentage of LPAR share but I would like to
>do it on MSU value.
Unless they changed it, since I've last been involved with WLM, resource groups
are defined as unnormalised CPU service units.
Since MSU stands for 'Millions of Service Units', I'll leave the calculation up
to the student. (8-{]}
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
> > Are you haevy user of GDGs created *more frequently* than daily? We run a batch job to copy off smf and ims log data whenever a switch occurs. Just our kind of normal. > BTW: I think that a reason why IBM didn't increase maximum LIMIT() for > GDG is lack of interest: Those customers who needed it already use > "pseudo-GDG" (batch scheduler failities). > > Is there any other reason? No one wants 365 generations? > We learned to live with the limitation. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
> Why doesn't'GV00 roll over to G0001V01? > Rather than starting over at G0001V00... Why does it really matter? You can only have a max of 255 entries. Just like 640K was enough memory on a PC, 255 entries is enough! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
we certainly create GDG "members" more frequently than daily - more importantly (for us) - they are "ad hoc" - we simply dont know how many will be generated in a day - until they are generated (CA-IDMS transaction log and recovery journal offloads) Chris Hoelscher Senior IDMS & DB2 Database Administrator Humana Inc 502-476-2538 choelsc...@humana.com The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
David Andrews wrote: On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote: Of course it is possible to use GDGs for cyclic jobs running hourly (still over year) or even more frequently. [...] But I think it is uncommon. Commonplace here. We are heavy, regular users of GDGs. Are you haevy user of GDGs created *more frequently* than daily? My opinion wasn't GDGs are not used, rather GDGs are usually created on daily basis or less frequently. BTW: I think that a reason why IBM didn't increase maximum LIMIT() for GDG is lack of interest: Those customers who needed it already use "pseudo-GDG" (batch scheduler failities). Is there any other reason? No one wants 365 generations? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 files complaint against IBM
In a message dated 1/20/2009 8:55:58 A.M. Central Standard Time, steve_thomp...@stercomm.com writes: Given IBM's behavior, T3 and FSI are the only ways one would get a drop and play mainframe (vis-à-vis MP3000). Which in my opinion is what it would take to go into server farms to have a better one on one competition price wise. >> Was interesting to see CICSO throw their hat into the 'server' market. _http://www.siliconrepublic.com/news/article/12130/cio/cisco-plans-major-virtu alisation-offensive_ (http://www.siliconrepublic.com/news/article/12130/cio/cisco-plans-major-virtualisation-offensive) Also might want to check the 'downadup' virus article **A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/10075x1215855013x1201028747/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=De cemailfooterNO62) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote: > Of course it is possible to use GDGs for cyclic jobs running hourly > (still over year) or even more frequently. [...] But I think it is > uncommon. Commonplace here. We are heavy, regular users of GDGs. Lots and LOTS of old-master-in, transaction-file-in, new-master-out stuff. Lots of new generations that are subsequently aggregated. It's the technology that Would Not Die. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Wanted: Used STK 8500
We are looking for a small, used, STK 8500 tape library for use with a z/VM system. If you have one for sale, please contact me via email. Please don't respond to the list. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
On Tue, 20 Jan 2009 09:21:50 -0600, Betsy Jeffery wrote: >Thanks for the posts. Unfortunatley, the suggestions have not worked yet. >My profile shows IMACRO NONE and EDSET shows no inital macro. The >problem persists but not in all files. >Betsy > Is it only happening for flat file (dsorg=ps) from ISPF 3.4? If so, you need to turn on the option once you have your list to "Display Edit/View entry panel (*)" Then when you see the initial panel, blank out the edit macro. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
David Magee wrote: [...] If for some reason an entry in group A does not roll off (i.e., an expiration date is changed so that the entry doesn't expire in a timely matter, etc.), group B will not have it's wrap bits turned off. When group B gets to G0999V00, then next attempt to create an entry by using DSN=...(+1) will fail. Manual intervention is required by the user to correct all the existing entries in the GDG before any new entries can be created. Good doc from IBM about how to correct the problem is not easily found. At 3:00 AM Sunday morning, this could really be FUN!! Actually, I think, the problem is theoretical. How often do you create new generation? Usually it's being created daily (weekly, monthly). One generation a day means 1 days to overlap. That's 27 years! Even if you are still working here, there is small chance that application didn't change and this GDG is dropped. Of course it is possible to use GDGs for cyclic jobs running hourly (still over year) or even more frequently. It is also possible that for such jobs real GDG is used, not some "autoedit" feature of batch scheduler (like %%ODATE in ControlM). But I think it is uncommon. Last but not least: uncommon processing x uncommon error... My €0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: UNABLE TO FIND ERROR MESSAGE - ADR849E
Esmie I assume you wanted to say "I am unable to find error message - ADR849E". You may even know about the IBM web page service "LookAt!". In case you are unfamiliar with "LookAt!", it can be found at the following web page: http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/ In case you are aware of "LookAt!" but by mischance - as happened when I tried LookAt! the first time just now looking for ADR849E - you didn't notice that you had not selected the z/OS level you are clearly using but happened to have a level earlier than that which corresponded to when this message was introduced selected, that may have been why you imagine the message cannot be found. If you had selected V1R10 - perhaps also V1R9 since I failed with V1R8 and, since I spotted revision bars, maybe Jim was quoting from the V1R9 manual rather than the V1R10 manual - you would have been successful in finding the message explanation Jim McAlpine presented for you without having to take all the trouble to compose a couple of posts for us all to puzzle over! Chris Mason On Mon, 19 Jan 2009 10:43:31 -0800, esmie moo wrote: >Good Day > >I am -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ISPF Edit Macro
I found the culprit. The 'ISRUEDIT DSLIST' panel had an errant character in the inital macro screen. Clearing it fixed the problem for PDS/PDSE/sequential files. Don't you hate it when the answer is right in front of you but you can't see it! Thanks to all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
Betsy Jeffery wrote: Thanks for the posts. Unfortunatley, the suggestions have not worked yet. My profile shows IMACRO NONE and EDSET shows no inital macro. The problem persists but not in all files. Betsy But in your initial post you wrote: "Some how I have managed to create something that ISPF thinks is an edit macro. Opening any file/member tries to execute the macro (which is junk and therefore invalid)." Can you tell us: 1) what is the name of this "something"? 2) is it all files or just some? 3) how are you doing the edit: ISPF 2 ISPF 3.4 w/ 'e' line command ISPF 3.1 other 4) what is the content of this something? 5) have you tried deleting it or renameing it? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques ==> Check out the Trainer's Friend Store to purchase z/OS <== ==> application developer toolkits. Sample code in four<== ==> programming languages, JCL to Assemble or compile, <== ==> bind and test. <== ==> http://www.trainersfriend.com/TTFStore/index.html<== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
As entries are added to a GDG by DSN=...(+1), G0001V00 thru GV00 are created with the wrap bit OFF (I'll refer to these entries members of group A). After GV00 exists, the next entries created by DSN=...(+1) are G0001V00 - G0999V00 with the wrap bit ON (I'll refer to these entries as members of group B). Note that GV00 is not used. Normal processing of GDGs using DSN=...(+1) should cause older entries to roll off so that as members of group B are created, all members of group A should become uncataloged. When this happens, the system will turn off all the wrap bits in group B and it will then look like group A did in its early stages. The GDG has wrapped successfully! If for some reason an entry in group A does not roll off (i.e., an expiration date is changed so that the entry doesn't expire in a timely matter, etc.), group B will not have it's wrap bits turned off. When group B gets to G0999V00, then next attempt to create an entry by using DSN=...(+1) will fail. Manual intervention is required by the user to correct all the existing entries in the GDG before any new entries can be created. Good doc from IBM about how to correct the problem is not easily found. At 3:00 AM Sunday morning, this could really be FUN!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
Thanks for the posts. Unfortunatley, the suggestions have not worked yet. My profile shows IMACRO NONE and EDSET shows no inital macro. The problem persists but not in all files. Betsy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Unix File names EKM and dates
You can modify the config file names via operator command, so a process that Peter outlined could work. I do not know if the new file names take effect immediately, or on the next cycle. So you could set something up on a daily basis. In our case, I have turned off all AUDIT recording except for errors, and made the metadata.xml files 8 MB, and after running now for almost a year, that file is only 1.5MB with 11,500 tapes worth of data in it. We backup the file systems, so I do not plan on externalizing these files. Of course, over a number of years that file will probably get too big, but then I can manually do something, in the absence of an automated process. Dave _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, January 20, 2009 8:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Unix File names EKM and dates The config information will need to be changed each time the EKM STC is cycled. So, yes, I am looking at creating a pre or post REXX to alter the config file in Unix to have the names that I want. It would have been nicer if Unix provided this function or the JZOS process provided it. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 files complaint against IBM
> -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Bob Shannon > Sent: Tuesday, January 20, 2009 8:01 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: T3 files complaint against IBM > > >It's good to see that T3 Technologies has not yet given up the struggle > >to bring back competition into the IBM mainframe market. > > Or it could be construed as beating a dead horse I surely hope not. To the contrary, T3 and FSI (or new competitors yet unborn) should be viable, growing businesses. Monopoly is never a good thing. IBM doesn't want the hassle of dealing with tiny, barely profitable (for IBM, that is) small business and ISV users. Why IBM won't permit other businesses to serve that limited market I cannot fathom. It might be a very long shot for T3 to succeed over IBM's assaults, but I do applaud T3 for continuing to fight for their rights and ours. I wish them every success, and so should each and every one of us here. If T3 started an internet donations campaign for their legal expenses vs IBM, I for one would contribute to it and consider it money well spent. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 files complaint against IBM
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Bowler Sent: Tuesday, January 20, 2009 6:36 AM To: IBM-MAIN@bama.ua.edu Subject: T3 files complaint against IBM It's good to see that T3 Technologies has not yet given up the struggle to bring back competition into the IBM mainframe market. http://openmainframe.org/featured-articles/the-t3-technologies-story.html I for one, would like to see them succeed. Given IBM's behavior, T3 and FSI are the only ways one would get a drop and play mainframe (vis-à-vis MP3000). Which in my opinion is what it would take to go into server farms to have a better one on one competition price wise. Regards, Steve Thompson -- Poster's opinions may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling use of MSU's with WLM
"Dick de Groot" wrote in message news:<1cb107490901200633t4f2e3004qf732fc7fdac44...@mail.gmail.com>... > Is there a way to control the maximum use of MSU's for a specific workload > with WLM.You can use resource groups for percentage of LPAR share but i > would like to do it on MSU value. > > -- > Met vriendelijke groeten/With kind regards > > Dick de Groot > Today you have 3 options to specify the limit of a RG: Define Capacity: 1. In Service Units (Sysplex Scope) 2. As Percentage of the LPAR share (System Scope) 3. As a Number of CPs times 100 (System Scope) Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Controlling use of MSU's with WLM
Is there a way to control the maximum use of MSU's for a specific workload with WLM.You can use resource groups for percentage of LPAR share but i would like to do it on MSU value. -- Met vriendelijke groeten/With kind regards Dick de Groot -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us Lizette Koehler To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Re: GDG Question 01/20/2009 09:16 AM Please respond to IBM Mainframe Discussion List The V00 part of the GV00 number is used to create the same GDG number without impacting the GDG numbers. Say I have G0001V00 and I find that it is incorrect, I then create a G0001V01. Now let's say the G0001V01 is still the Generation 0 entry in the GDG. Then when I use DSN(0) it pulls in G0001V01 as if it were G0001V00. And the G0001V00 is gone. Best part I did not roll off any other GDGs when creating the G0001V01 entry. Lizette > > This brings up a question I've had before. > > Why is the 'V00' not made use of? > > Why doesn't'GV00 roll over to G0001V01? > Rather than starting over at G0001V00... > > > > > >How did you handle this situation? Just delete all generations or create a > >new GDG? > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The V00 part of the GV00 number is used to create the same GDG number without impacting the GDG numbers. Say I have G0001V00 and I find that it is incorrect, I then create a G0001V01. Now let's say the G0001V01 is still the Generation 0 entry in the GDG. Then when I use DSN(0) it pulls in G0001V01 as if it were G0001V00. And the G0001V00 is gone. Best part I did not roll off any other GDGs when creating the G0001V01 entry. Lizette > > This brings up a question I've had before. > > Why is the 'V00' not made use of? > > Why doesn't'GV00 roll over to G0001V01? > Rather than starting over at G0001V00... > > > > > >How did you handle this situation? Just delete all generations or create a > >new GDG? > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Unix File names EKM and dates
Peter, No for now it is just the file names inside the Unix Config file for EKM that I want to change. At this time, all of our unix files are unique per LPAR for EKM. I will be working on setting up a SYSPLEX ROOT in my Unix so we can look at unix file sharing closer. As well as automove for our mount points. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hunkeler Peter (KIUK 3) > Sent: Tuesday, January 20, 2009 8:26 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Unix File names EKM and dates > > >The config information will need to be changed each time the EKM STC > >is cycled. > > Apart from the filenames you already posted, what else do you need to > change in the config file? > > If it is only filenames so they point to the current files, this is > exactly what symbolic links are good for. You can keep the filenames > the program refers to unchanged since these are the symbolic link names. > As proposed in my REXX, you then create the files with the variable > names > and let the symlink point to them. > > I just recognized that my sample REXX will only work it the /EKM > directory > is unique to each z/OS instance and that this probably is not the case. > You'd need to change the symlink names so these are different for > different > instances..h... this would require a different config file for > each EKM instance. > > Do the EKM instances share the config file? Is it specified in the > JCL? If so, you can use system symbolics to point to different > (but constant) config files for each EKM instance. > > -- > Peter Hunkeler > Credit Suisse > > - > - > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Just a thought Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us Scott Barry To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Re: GDG Question 01/19/2009 02:41 PM Please respond to IBM Mainframe Discussion List On Mon, 19 Jan 2009 14:13:34 -0500, Jerry Fuchs wrote: >It seems to me that I saw a thread that stated when you hit GV00 you >will be unable to create (+1). > >Is this correct? > >How did you handle this situation? Just delete all generations or create a >new GDG? > >THI > >Jerry Fuchs >Senior Systems Engineer >Wendy's Arby's Group >One Dave Thomas Blvd. >Dublin, Ohio 43017 >(614) 764-3594 > The GDG assignment rolls from GV00 to **.G0001V00 on this condition. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Edit Macro
And check your Edit settings with the Edit_Settings pull-down or the EDSET command. Regards, John K Wayne B of the IBM Mainframe Discussion List wrote on 01/19/2009 09:04:04 PM: > Make sure you didn't accidentally set up an initial macro on your ISPF EDIT > panel. > > In option 2) look below the Workstation File line and make sure nothing is > in the initial macro field. > > I've done this by accident a few times. The macro setting will stay in your > ISPF profile until you remove it. > > Hope this helps your problem... > > On Tue, Jan 20, 2009 at 3:05 AM, Betsy Jeffery wrote: > > > Some how I have managed to create something that ISPF thinks is an edit > > macro. Opening any file/member tries to execute the macro (which is junk > > and > > therefore invalid). Simple question for simple mind: How do I get rid of > > it? I > > have searched high and low and cannot find the reference. TSO/ISPF manuals > > don't quite say. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler TCP/IP
(1) I would expect the listener task to be performing GIVESOCKET to one of the subtasks (which will perform TAKESOCKETs) (2) Yes - you just need to handle the subtasks and dish work out from the mother task - the mother could be the listener task Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 rsc...@rs.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: 20 January 2009 04:20 To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP Thankx for help I have a couple of more questions 1) The Orignal Socket Created via socket & bind and later on used on the listen is the one which the server is listining on Later on the socket reterived on the Accept via the Retcode is the one from the Client it is this socket used on Send And Recv 2) Can concurrent Sockets program receive input from a number of tcpip clients with different tcp/ip address thankx in My Case its Windows program -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of Rob Scott Sent: Monday, January 19, 2009 2:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP Regarding EZASMI, I have used it quite extensively in two products that I am involved in - the ECB list method seems to be the only way to correctly manage the interface - there are just too many ways that EZASMI can get into a "never post" style situation. It is a bit of a pain to have to keep building and destroying timers around the call but worth it in the end. GWA03PSA is the loaded address of EZASOH03 which is the EZASMI API module Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 rsc...@rs.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: 19 January 2009 17:36 To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP Thankx was that your IDEA setting ECBLIST (that way if TCP/IP doesn't post you down get deadlocked) re: GLOBAL storage there are 2 storage areas defined by it GWAUSCNT GWA03PSA They dont seem to be refrenced by any of the EZASMI api's -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of Rob Scott Sent: Monday, January 19, 2009 12:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP A) The EZASMI global storage block contains important state information - including things like the load epaddr of the API load module. You should perform a USING on EZASMGWA for it. B) If the INITAPI has been done correctly for the subtask, the logic for ASYNC ECB API call should be something like : (1) Clear TCPIP ECB (2) Setup timer (3) Build ECBLIST containing TCPIP EBC and timer ECB (4) Call EZASMI API (5) Wait on ECBLIST (6a) If TCPIP ECB popped - cancel timer and then test TCPIP RC and ERRNO (6b) If timer ECB popped - branch to "timeout" code Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 rsc...@rs.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: 19 January 2009 16:43 To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP Thankx I am using async processing ECB= a couple of more questions A) Why would have to pass the address of the global stroage to the SubTasks ?? B) I debugging both Mother and Daughter task under TSO TEST if retocde = 0 for the API's that 0 is a good return code for example "takesocket" or "GetCleintId" should the ECB passed on WZASMI macro post in my case it never does maybe because I have defined a INITAPI in the SubTask -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of Rob Scott Sent: Monday, January 19, 2009 8:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler TCP/IP (A) Yes - and if the subtask is going to TakeSocket pay attention to the SUBTASK= keyword (B) The way I have implemented this in the past is to have the mother task pass a parameter list to the daughter subtasks that includes the address of the EZASMI GLOBAL area - and then each subtask will obtain its own task storage (TIE). Another couple of points : (1) If you are writing anything non-trivial, then I would advise using the ASYNC ECB flavour of EZASMI. (2) Before calling the send/recv interfaces, setup a timer and add its ECB to an ECBLIST along with the ECB for the EZASMI call (and also your STC "stop" ECB maybe) - this will help situations where communications are lost midway thru a conversation and your EZASMI call hangs. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 rsc...@rs.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: 19 January 2009 13:39 To: IBM-MAIN@bama.ua.edu Subject
Re: Unix File names EKM and dates
>The config information will need to be changed each time the EKM STC >is cycled. Apart from the filenames you already posted, what else do you need to change in the config file? If it is only filenames so they point to the current files, this is exactly what symbolic links are good for. You can keep the filenames the program refers to unchanged since these are the symbolic link names. As proposed in my REXX, you then create the files with the variable names and let the symlink point to them. I just recognized that my sample REXX will only work it the /EKM directory is unique to each z/OS instance and that this probably is not the case. You'd need to change the symlink names so these are different for different instances..h... this would require a different config file for each EKM instance. Do the EKM instances share the config file? Is it specified in the JCL? If so, you can use system symbolics to point to different (but constant) config files for each EKM instance. -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Unix File names EKM and dates
The config information will need to be changed each time the EKM STC is
cycled.
So, yes, I am looking at creating a pre or post REXX to alter the config
file in Unix to have the names that I want. It would have been nicer if
Unix provided this function or the JZOS process provided it.
Lizette
>
> >How would I code the EKM paramenter to include a date and
> >time stamp? I want the process to generate a new file each
> >time it is cycled. [snip]
>
> >Audit.metadata.file.name = /EKM/ekmetc/SDH8_metafile.xml
> >Would become
> >Audit.metadata.file.name=/EKM/ekmetc/&SYSNAME_metafile.xml
>
> Lizette, did you come to a solution yet?
>
> I admit, I'm pretty much ignorant about EKM but from a previous
> post I seem to remember it is startet as STC?
>
> You could add an initial step to create these files and then
> create a link to them so that you don't have to change the
> EKM configuration. Something like this:
>
> /*REXX*/
> syscallsrc = syscalls("ON")
>
>
>
> if syscallsrc > 0
>
> then do
>
> say "SYSCALLS environment could not be established, RC=" !!
> syscallsrc
> say "aborting..."
>
> exit 16
>
> end
>
>
>
> address syscall
>
>
>
> sysname = MVSVAR("SYSNAME")
>
> cdate = date("S")/* date as mmdd */
>
> ctime = time("N") /* time as hh:mm:ss, transform to hhmmss */
>
> ctime = left(ctime,2) !! substr(ctime,4,2) !! right(ctime,2)
>
>
>
> metafile = "/EKM/ekmetc/" !! sysname !! "_metafile.xml"
>
> metafilelink = "/EKM/ekmetc/metafile.xml"
>
>
>
> debugfile = "/EKM/ekmlog/" !! sysname !! "_" !! cdate !! "_" ,
>
> !! ctime !! "_debug"
>
> debugfilelink = "/EKM/ekmlog/debug"
>
>
>
> "open" metafile O_CREAT+O_WRONLY "660" /* create the file using open */
>
> "close" RETVAL /* then close it again*/
>
> "unlink" metafilelink /* remove the old link*/
>
> "symlink" metafile metafilelink /* and create the new link*/
>
>
>
>
> "open" debugfile O_CREAT+O_WRONLY "660" /* create the file using open */
>
> "close" RETVAL /* then close it again*/
>
> "unlink" debugfilelink /* remove the old link*/
>
> "symlink" debugfile debugfilelink /* and create the new link*/
>
>
>
> exit 0
>
> /*end-of-REXX*/
>
>
> Store this REXX as CRESLINK in a REXX library and run it before
> the EKM step:
>
> //IRXJCL01 EXEC PGM=IRXJCL,PARM='CRESLINK'
> //SYSEXEC DD DISP=SHR,DSN=your-rexx-library-goes-here
> //SYSTSPRT DD SYSOUT=*
>
> You may want to add some more sophisticated error handling and possibly
> other files to create. But this should give you an idea.
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 files complaint against IBM
>It's good to see that T3 Technologies has not yet given up the struggle to >bring back competition into the IBM mainframe market. Or it could be construed as beating a dead horse Bob Shannon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Netview Access Services (NVAS) and Mixed-case Passwords
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin > > On Tue, 20 Jan 2009 14:42:47 +0900, Timothy Sipples wrote: > > > >But yes, you can get mixed case password support with NVAS. Take a look at > >APAR PK16580 for more information. Here's a Web link that should work: > > > > http://www.ibm.com/support/docview.wss?uid=swg1PK16580 > > > Wherein I read: > > Note: As suggested by RACF, if you use a mix of applications > that do an do not support mixed-case passwords, do not > activate the SETROPTS PASSWORD(MIXEDCASE) option in RACF and > do not activate MIXCASE in NVAS. > > ??? > > I don't understand how this works. I would expect that if > the SETROPTS PASSWORD(MIXEDCASE) option in RACF is inactive, the > setting of MIXCASE in NVAS should have no effect and be irrelevant. I agree. According to RACF doc, if SETROPTS PASSWORD(MIXEDCASE) is NOT in effect, then RACF itself uppercases whatever is tendered as a password. I observe that daily, since my terminal is defined to CICS with UCTRAN=TRANID, which causes CICS to uppercase only the first n (n <= 4) characters of an input datastream if the context requires a transaction ID (it assumes the first "text word" is the tran. ID). Our "ryo" CICS signon program does not uppercase any input tendered, and I normally don't have the capslock on when I sign on to CICS. > What do these settings actually do? How do they interact? what > is the (adverse) effect of leaving one active and the other > inactive? NVAS without the cited PTF uppercases whatever is tendered in the password field (and presumably the other fields of the sign-on panel) -before- submitting it to RACF, so if RACF has mixed-case passwords enabled -AND- the user has established a mixed-case password, that user would be unable to sign on via NVAS without the cited PTF. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
T3 files complaint against IBM
It's good to see that T3 Technologies has not yet given up the struggle to bring back competition into the IBM mainframe market. http://openmainframe.org/featured-articles/the-t3-technologies-story.html Roger Bowler http://perso.wanadoo.fr/rbowler Hercules "the people's mainframe" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Unix File names EKM and dates
>How would I code the EKM paramenter to include a date and
>time stamp? I want the process to generate a new file each
>time it is cycled. [snip]
>Audit.metadata.file.name = /EKM/ekmetc/SDH8_metafile.xml
>Would become
>Audit.metadata.file.name=/EKM/ekmetc/&SYSNAME_metafile.xml
Lizette, did you come to a solution yet?
I admit, I'm pretty much ignorant about EKM but from a previous
post I seem to remember it is startet as STC?
You could add an initial step to create these files and then
create a link to them so that you don't have to change the
EKM configuration. Something like this:
/*REXX*/
syscallsrc = syscalls("ON")
if syscallsrc > 0
then do
say "SYSCALLS environment could not be established, RC=" !!
syscallsrc
say "aborting..."
exit 16
end
address syscall
sysname = MVSVAR("SYSNAME")
cdate = date("S")/* date as mmdd */
ctime = time("N") /* time as hh:mm:ss, transform to hhmmss */
ctime = left(ctime,2) !! substr(ctime,4,2) !! right(ctime,2)
metafile = "/EKM/ekmetc/" !! sysname !! "_metafile.xml"
metafilelink = "/EKM/ekmetc/metafile.xml"
debugfile = "/EKM/ekmlog/" !! sysname !! "_" !! cdate !! "_" ,
!! ctime !! "_debug"
debugfilelink = "/EKM/ekmlog/debug"
"open" metafile O_CREAT+O_WRONLY "660" /* create the file using open */
"close" RETVAL /* then close it again*/
"unlink" metafilelink /* remove the old link*/
"symlink" metafile metafilelink /* and create the new link*/
"open" debugfile O_CREAT+O_WRONLY "660" /* create the file using open */
"close" RETVAL /* then close it again*/
"unlink" debugfilelink /* remove the old link*/
"symlink" debugfile debugfilelink /* and create the new link*/
exit 0
/*end-of-REXX*/
Store this REXX as CRESLINK in a REXX library and run it before
the EKM step:
//IRXJCL01 EXEC PGM=IRXJCL,PARM='CRESLINK'
//SYSEXEC DD DISP=SHR,DSN=your-rexx-library-goes-here
//SYSTSPRT DD SYSOUT=*
You may want to add some more sophisticated error handling and possibly
other files to create. But this should give you an idea.
--
Peter Hunkeler
Credit Suisse
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: UNABLE TO FIND ERROR MESSAGE - ADR849E
On Mon, Jan 19, 2009 at 6:43 PM, esmie moo wrote: > Good Day > > I am > > > __ > | 3.2.507 *ADR849E* -- | *ADR849E* *(*ttt*)-*m*(*yy*),* *COPY* *FROM* *VOLUME* input_volume_serial_number *TO* |*VOLUME* output_volume_serial_number *FAILED* *BECAUSE* *THE* *OUTPUT* *VOLUME* |*IS* *A* *SPACE* *EFFICIENT* *VOLUME* | *Explanation:* For a COPY FULL or a COPY TRACKS operation specifying one | track range that includes the entire volume, space efficient FlashCopy | must be used to perform the full volume copy to a space efficient volume. | DFSMSdss was unable to establish a space efficient FlashCopy relationship | for one of the following reasons: - | FASTREPLICATION(NONE) was specified. DFSMSdss failed the operation | because the keyword prohibits space efficient FlashCopy. - | FCSETGTOK(FAILRELATION) and FCNOCOPY were not specified. Space | efficient FlashCopy is not permitted unless both of these keywords are | specified. - | At least one of the volumes was not eligible to participate in a space | efficient FlashCopy relationship at this time. - | DFSMSdss attempted to establish a space efficient FlashCopy | relationship and failed with an error. | *System* *Action:* DFSMSdss terminates the full volume copy operation. The | return code is 8. | *Operator* *Response:* None. | *Application* *Programmer* *Response:* If you do not intend to copy the data to | a space efficient volume, replace the output volume with a fully | provisioned volume on the COPY command and resubmit the job. If the space | efficient volume is the intended output volume, depending on the detected | condition, take the appropriate action listed as follows: - | Ensure FASTREPLICATION(NONE) is not specified. - | Ensure FCSETGTOK(FAILRELATION) and FCNOCOPY are specified. - | Refer to previously issued message for the reason why the volume is | not eligible to participate in a space efficient FlashCopy | relationship. - | Refer to previously issued message for the FlashCopy failing reason. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
