We run on a 30 second minimum cycle time, but that occasionally elongates (naturally) when things get really busy. We don't use special consistency groups... we just have the consistency flag turned on for the one RDF group we use.
I am a UNIX/Windows guy that will be implementing SRDF/A for the first time.  Unfortunately, I have to start off with our z/OS mainframe before I work on the platforms that I am so comfortable with.   I have asked our z systems programmer to provide me with some info regarding which volumes will be replicated and how they will be grouped.  I was hoping he would come back with something like this -    volumes bb0-bdf - OS volumes to be replicated every 8 hours volumes bc0-bff - Application volumes (DB2, VSAM, flat files to be replicated every 30 seconds).   This would allow me to have a minimum of device groups, RA groups and consistency groups.  I feel like the fewer of these things to manage the better.  Instead, he is coming back with many (8-12) different smaller groups - some with only a few volumes.  There are two different applications on the host so I could easily tolerate 1 OS group and 2 application groups.  If I have as many as 12 groups each with a device groups, RA group, and consistency group; will this be difficult to manage?  Isn't it better to have fewer of these groups?     Once I'm done with the IBM mainframe I will have to tackle our Unisys, Windows and UNIX environments.  I feel like I need to keep the complexity to a minimum.  What do you think?  Any insight to current z/OS SRDF implementations would be great.
Mainframe SRDF