IBM Z Hardware and Operating Systems Ideas Portal
This is the public portal for all IBM Z Hardware and Operating System related offerings. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hello, I read the developer anwser and I have to say that having CPM messages (SYSLOG, JOBLOG and OPERLOG) based on GMT makes CPM really unusable and misleading for system operators and system administrators.
The case in which CPM have to coordinate systems with different local time is a very particular case vs the majority of cases in which there is a unique time-zone and even if different time-zones, each system should receive CPO messages with the correct local time letting the CPM translate its internal time GMT to local time when sending WTO to the controlled systems. This is true for all z/OS components and it should also be true for CPM.
Please implement messages in both modes (GMT and Local time-zone) and let the user decide which mode to use.
Thanks a lot for your attention.
At least please, implement messages in both way (GM and Local Time) and the let the user decide which mode to use. Thanks!
At least please, implement messages in both way (GM and Local Time) and the let the user decide which mode to use. Thanks!
Hello, I read the developer anwser and I have to say that having CPM messages (SYSLOG, JOBLOG and OPERLOG) based on GMT makes CPM really unusable and misleading for system operators and system administrators.
The case in which CPM have to coordinate system with different local time is a very particular case and even if so, each system should receive CPO messages with the correct local time letting the CPM translate its internal time GMT to local time when sending WTO to the controlled systems. This is true for all z/OS components and it should also be true for CPM. Thanks for the attention.
CPM's domain spans several CPCs and systems, each of which might be defined to a different time zone.
This requires compromises when putting all actions into a (legible) chronological order.
Therefore, CPM intentionally uses UTC as reference for time-conditions and omits handling of DST changes.
CPM intends to give a timely uniform view to all its planned, ongoing and past activities.
As an example, understanding a single activation on a single CPC, but which has been triggered concurrently by multiple workload on several systems with different time-zones, is more comprehensive if all of the triggering moments are listed with a single (UTC) time reference instead of displaying each trigger with a differing local time.
You may vary this case with subsequent activations triggered by different time-zoned system's workload on a single CPC: which came first, or which time-lag was in-between?
Then there are scheduled activations: for a comprehensive chronological order - especially when listed together with workload triggered activations - CPM takes UTC are reference as well.
CPM's tests and reviews have shown that operators usually were confused when being confronted with multiple time-zones within a single policy or report.
We also found it difficult to let specify or automaticall decide which (single) time-zone should be used for management.
Letting the operator explicitly set one time-zone in the policy is difficult: workload conditions allow to specify a system filter (*) which may span multiple systems, possibly belonging to different time-zones; letting CPM find out shortly before the time-condition starts (because the system has been IPLed only recently) that the observed system is set to a different time-zone, would cause additional confusion.
Letting CPM set a single time-zone automatically, e.g. using the local time-zone of the CPM runtime system, has also been discarded by design, because it would disallow a CPM failover to another runtime-system with different time-zone and DST setting during management.
The basic question of CPM's design is: do we benefit from the ability of CPM to manage CPCs and systems defined to different time-zones and accept the resulting restrictions in regard to DST handling, or do we restrict management to a single time-zone reference and possibly benefit from DST handling?
CPM made a choice for the first variant.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - BCP_Capacity Provisioning
Operating system - IBM z/OS
Source - Client
For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - IBM Z Performance and Capacity Analytics
Component - All
Operating system - z/OS
Source - Client