Re: Rationalise policy domains
John, if you set the "Query Schedule Period" to a low number, say 4 hours, you will be able to change the domain and schedule and avoid having the client schedule obtain a schedule which you then delete. In the admin ref, see the set command for query schedule period and try to find some guidance on it in the admin guide. I haven't done this but I think it will work. Bill At 11:30 AM 8/27/2002, you wrote: >Historically I have a number of policy domains based on client os. >Well it seemed a good idea at the time. >My question is I now want to rationalise all the policy domains into say two, >but with the least disruption or work at client level(none if possible) >My main concern is that I will lose all the schedules and their associations, >and that I will need on netware for example to reload the scheduler on the >client to pick >up the new schedule information. >I think I may also need to stop/ start the scheduler for nt clients >Am I correct in these beliefs? >I know that I will need to ensure that the new domains contain the same >management classes, to avoid rebinding, but are there any other things I need to >be aware of. >Thanks >John > > > > >** >The information in this E-Mail is confidential and may be legally >privileged. It may not represent the views of Scottish and Southern >Energy plc. >It is intended solely for the addressees. Access to this E-Mail by >anyone else is unauthorised. If you are not the intended recipient, >any disclosure, copying, distribution or any action taken or omitted >to be taken in reliance on it, is prohibited and may be unlawful. >Any unauthorised recipient should advise the sender immediately of >the error in transmission. > >Scottish Hydro-Electric, Southern Electric, SWALEC and S+S >are trading names of the Scottish and Southern Energy Group. >** -- Bill Colwell C. S. Draper Lab Cambridge Ma.
Re: Rationalise policy domains
John, My understanding is that if you are using the managedservices (or cadmode depending on client version) option for scheduling then changes in schedules are picked up by the dsmcad and restarts are no longer required. If, on the other hand you are just using the scheduler service then restarts probably are required. Jim John Naylor wrote: > Historically I have a number of policy domains based on client os. > Well it seemed a good idea at the time. > My question is I now want to rationalise all the policy domains into say two, > but with the least disruption or work at client level(none if possible) > My main concern is that I will lose all the schedules and their associations, > and that I will need on netware for example to reload the scheduler on the > client to pick > up the new schedule information. > I think I may also need to stop/ start the scheduler for nt clients > Am I correct in these beliefs? > I know that I will need to ensure that the new domains contain the same > management classes, to avoid rebinding, but are there any other things I need to > be aware of. > Thanks > John > > ** > The information in this E-Mail is confidential and may be legally > privileged. It may not represent the views of Scottish and Southern > Energy plc. > It is intended solely for the addressees. Access to this E-Mail by > anyone else is unauthorised. If you are not the intended recipient, > any disclosure, copying, distribution or any action taken or omitted > to be taken in reliance on it, is prohibited and may be unlawful. > Any unauthorised recipient should advise the sender immediately of > the error in transmission. > > Scottish Hydro-Electric, Southern Electric, SWALEC and S+S > are trading names of the Scottish and Southern Energy Group. > ** John Naylor wrote: > Historically I have a number of policy domains based on client os. > Well it seemed a good idea at the time. > My question is I now want to rationalise all the policy domains into say two, > but with the least disruption or work at client level(none if possible) > My main concern is that I will lose all the schedules and their associations, > and that I will need on netware for example to reload the scheduler on the > client to pick > up the new schedule information. > I think I may also need to stop/ start the scheduler for nt clients > Am I correct in these beliefs? > I know that I will need to ensure that the new domains contain the same > management classes, to avoid rebinding, but are there any other things I need to > be aware of. > Thanks > John > > ** > The information in this E-Mail is confidential and may be legally > privileged. It may not represent the views of Scottish and Southern > Energy plc. > It is intended solely for the addressees. Access to this E-Mail by > anyone else is unauthorised. If you are not the intended recipient, > any disclosure, copying, distribution or any action taken or omitted > to be taken in reliance on it, is prohibited and may be unlawful. > Any unauthorised recipient should advise the sender immediately of > the error in transmission. > > Scottish Hydro-Electric, Southern Electric, SWALEC and S+S > are trading names of the Scottish and Southern Energy Group. > ** -- Jim Kirkman AIS - Systems UNC-Chapel Hill 966-5884
Re: Rationalise policy domains
We are running 1 domain per node. At first I thought this would be an administrative nightmare, but it really isn't. It also makes changes and exceptions easier because you know that when you change any settings in the domain you are affecting just one node. I actually like running this way. Just my 2 cents. Cory >>> [EMAIL PROTECTED] 08/28/02 03:56AM >>> John, I too had many domains. One for each client os and eveing application, Oracle exchange SAP. It was a nightmare with copy groups. After much thought and consultation with Tivoli I have rationalized it to two domains. The process was slow in that we moved so many clients a day, and had to restart the scheduler. One domain is for application servers, or systems less than 30GB storage, without collocation in it's storage pool. Another inessence is for database servers such as Oracle, Exchange and SAP and also NAS with collocation andit's own storage pool. I have also set up pool NAS_TAPE that collates on filespace for both NFS and CIFS. We also have a pool for disaster recovery. I have set up schedules to start at various times during the evening and spread the clients across those, e.g client_2000 starting at 20:00. It'll be a lot of work but it makes it so much easier. This was not completed on the original node as we moved to a new service, but I got the comfort factor seeing how it worked. Kind Regards Mike Wiggan, TCS/31 Infrastructure Integration Specialist Petroleum Devlopment Oman LLC ([EMAIL PROTECTED]) -Original Message- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 7:31 PM To: [EMAIL PROTECTED] Subject: Rationalise policy domains Historically I have a number of policy domains based on client os. Well it seemed a good idea at the time. My question is I now want to rationalise all the policy domains into say two, but with the least disruption or work at client level(none if possible) My main concern is that I will lose all the schedules and their associations, and that I will need on netware for example to reload the scheduler on the client to pick up the new schedule information. I think I may also need to stop/ start the scheduler for nt clients Am I correct in these beliefs? I know that I will need to ensure that the new domains contain the same management classes, to avoid rebinding, but are there any other things I need to be aware of. Thanks John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **
Re: Rationalise policy domains
John, I too had many domains. One for each client os and eveing application, Oracle exchange SAP. It was a nightmare with copy groups. After much thought and consultation with Tivoli I have rationalized it to two domains. The process was slow in that we moved so many clients a day, and had to restart the scheduler. One domain is for application servers, or systems less than 30GB storage, without collocation in it's storage pool. Another inessence is for database servers such as Oracle, Exchange and SAP and also NAS with collocation andit's own storage pool. I have also set up pool NAS_TAPE that collates on filespace for both NFS and CIFS. We also have a pool for disaster recovery. I have set up schedules to start at various times during the evening and spread the clients across those, e.g client_2000 starting at 20:00. It'll be a lot of work but it makes it so much easier. This was not completed on the original node as we moved to a new service, but I got the comfort factor seeing how it worked. Kind Regards Mike Wiggan, TCS/31 Infrastructure Integration Specialist Petroleum Devlopment Oman LLC ([EMAIL PROTECTED]) -Original Message- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 7:31 PM To: [EMAIL PROTECTED] Subject: Rationalise policy domains Historically I have a number of policy domains based on client os. Well it seemed a good idea at the time. My question is I now want to rationalise all the policy domains into say two, but with the least disruption or work at client level(none if possible) My main concern is that I will lose all the schedules and their associations, and that I will need on netware for example to reload the scheduler on the client to pick up the new schedule information. I think I may also need to stop/ start the scheduler for nt clients Am I correct in these beliefs? I know that I will need to ensure that the new domains contain the same management classes, to avoid rebinding, but are there any other things I need to be aware of. Thanks John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **
Rationalise policy domains
Historically I have a number of policy domains based on client os. Well it seemed a good idea at the time. My question is I now want to rationalise all the policy domains into say two, but with the least disruption or work at client level(none if possible) My main concern is that I will lose all the schedules and their associations, and that I will need on netware for example to reload the scheduler on the client to pick up the new schedule information. I think I may also need to stop/ start the scheduler for nt clients Am I correct in these beliefs? I know that I will need to ensure that the new domains contain the same management classes, to avoid rebinding, but are there any other things I need to be aware of. Thanks John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **
