W dniu 2013-05-02 15:35, Pommier, Rex R. pisze: > Radoslaw, > > One additional reason would be expediency - which relates to the > territorialism Ted mentioned. One of the shops I work at has a > scheduler, with a separate scheduling team that "owns" the scheduler > and all the schedules that go into it. Any changes to the schedule > need to go through this group. In my mind, it makes sense to bypass > the scheduler for quick one-off jobs that require a database to be > down for example.
Well, such territorialism mean mistakes in management. The teams should cooperate, not fight. I would never allow such situation. BTDT - I'm a manager of mainframe division. A solution which should satisfy both parties would be to create two (maybe more) scheduling instances, one for "regular users". Another mean would be scheduler security facilities. -- Radoslaw Skorupka Lodz, Poland Agreed. Unfortunately not all managers are level-headed and not all work toward a common goal. Way too many have their little fiefdom and want to protect it at all costs. Not right, but reality. Rex The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
