Mainframe Storage

IDEA CSM-I-161  - Re-add small Global Mirror RPO graphs for DS8000 

• All sessions in CSM that use DS8000 Global Mirror, will store historical RPO information for the session.  This RPO data can either be exported to a CSV file, or can be view graphically within the CSM GUI itself. 
• When the 6.3.10 release came out with support for DS8000 Multi-target Global Mirror - Global Mirror, the options to view the RPO data in a small 15 minute or 24 hour format, was no longer available because for sessions where there might be multiple Global Mirror role pairs active at the same time, the small graphs didn't fit. 
• The historical RPO could be still see in the larger, more customizable graph format, however, customers expressed that they like the original small graph format as it allowed them to do a quick glance at the RPO without having to pull up the larger graph.
• We listened to this feedback, and in the 6.3.12 release the small RPO graphs have been reintroduced for all DS8000 sessions with Global Mirror.  A new "RPO History" tab is now available which will show the small graphs for all active Global Mirror role pairs.  It will also allow you to popup the larger graph (which includes LSS out of synch track history), or export the data to CSV.

By default, automatically start Global Mirror after a HyperSwap 3 site and 4 site sessions 

• Prior to this release, when z/OS HyperSwap was enabled on any 3 site or 4 site session in CSM, while in a multi-target configuration, if a planned or unplanned HyperSwap event occurred, customers would need to manually startup replication from the site that HyperSwap swapped to. 
• For planned swaps, this could be easily handled in a scheduled task that coordinates the swap and the restart.  But in unplanned swaps, this could mean that customers after the swap, had no disaster recovery protection until after a user manually starts the replication from the new site.
• Starting with 6.3.12, the above affected sessions will automatically attempt to start the session between the new production site and the other remote site.  For example, in a MT MM-GM session running H1->H2 (HyperSwap) and H1->H3 (Global Mirror), after a swap occurs to the H2 volumes, moving all production to H2, the session will automatically start Global Mirror between H2 and H3.  This ensures that even if the customer is not actively watching the session, the session will attempt to provide disaster recovery protection.
• Once the original production site is available again, a manual Start command will then be necessary to restart replication back to that site.
• NOTE: This support also includes the 3 site and 4 site MT MM-MM session types. 

IDEA CSM-I-173  - Setup password policies for Basic Users 

• CSM supports both LDAP and Basic Users.   When using LDAP, password policies can be setup on the LDAP server, however, CSM never provided a way to provide basic user password policies previously.
• Starting with 6.3.12, an Administrator or User Administrator can now select the Password Security Requirements link under the Administration panel header in order to define the password policy for the server.  The following are the options available:
• • Expiration in Days:  This is the number of days until users will need to change their password.  When the password expires, the next time they attempt to login they will be prompted to provide a new password.  Setting this value to 0 will indicate that passwords will not expire.

• • Minimum Length:  This defines the minimum number of characters necessary for all passwords.

• • Mixed Case:  Check this box if you want to require that the password have both upper and lower case characters

• • Numbers: Check this box if you want to require that the password have at least one numerical character.

• • Symbols: Check this box if you want to require that the password have at least one of the supported symbols:  ! @ $ % ^ & ( ) _ 

Automatically put Active server into an inactive mode after a Standby takeover 

• This new features adds onto the change made in CSM 6.3.11, where the active server will now automatically attempt to resync to the standby once both servers are back up after a disconnect.  The auto reconnect feature in CSM 6.3.11 can save customers valuable time and helps to ensure all updates are consistently being sent to the standby server without manual intervention.
• But what happens if it is was actually necessary to issue a Takeover from the standby server?   By issuing the Takeover command the standby server now becomes an active server which includes running any Scheduled tasks that were enabled to run on a schedule.  If the original active server comes back up after the Takeover on the standby, then you may end up with two active servers, both running the same Scheduled tasks on the same schedule.
• In the CSM 6.3.12 release, if a Takeover is issued on the standby, when the original active server comes back up, it will attempt to reconnect to the standby per the 6.3.11 feature.  When it does this though, it will see that a Takeover was in fact already issued on the standby server which will them prompt the original active to go into an inactive (standby) mode.  In this state, Scheduled Tasks will not run and the server will not respond to hardware events.
• The active/standby status for the server will be a disconnected consistent state.  Customers can then either set this server up as a standby to the original standby, or they can issue the Takeover command which will make the original active server an active server again.