IDMS

  • 1.  Why have multiple CV regions?

    Posted Nov 20, 2017 03:34 PM

    I was asked today if it is possible to reduce the number of IDMS CV regions we are running.
    We currently have 9 production regions, but most of them do very little work, and I really cannot come up with a good reason why we need this many regions.
    I think it goes back to the early years when we had limited memory available, and there was a limit to the size of the program and storage pools, but today that should not be an issue.

    What are the limiting issues for a single CV?
      Number of transactions per second?

      Amount of journaling?

      Amount of I/O?

    If you run many CVs because of resource constraints, would you be willing to share your experiences?



  • 2.  Re: Why have multiple CV regions?

    Posted Dec 02, 2017 03:46 PM

    Hi Tommy,

     

    Assuming your shop has sufficient MIPS, Real Memory, and  DASD Available for IDMS to use; I'm not aware of any limitations of having one CV do all. This is also assuming most of your applications are running above the line.

     

    And yes, you are correct saying today a IDMS DBA can carve out YUGE amounts of storage for pro and sto pools, not to mention just having to maintain one global DMCL with buffers also that don't get allocated if not used. Also, when running out of locks, more are allocated until the storage available is exhausted.

     

    With DASD Performance today, I wouldn't be concerned about I/O bottlenecks/limitations writing journal and general DB I/O.

     

    In my years of supporting IDMS, especially since Release 12 stabilized, I only see more than one Production CV to isolate applications (such as CAS) that have unique operational requirements.

     

    I doubt that I mentioned anything that you weren't already thinking and others might chime in with their 2-3 cents as well

     

    Happy Holidays,

     

    Joe Perkins



  • 3.  Re: Why have multiple CV regions?

    Posted Dec 02, 2017 04:29 PM
      |   view attached

    Some reasons …..

     

    Front-end cics may be on different lpars – and they do not implement cics transaction pass-thru

     

    Easier to segregate read-only transactions to a separate CV to avoid locking

     

    Take advantage of ziips on different lpars – if the ziip on 1 lpar is maxxed out

     

    And most importantly – if something works – don’t try to fix it

     

     

     

     

     

     

    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services

     

    123 East Main Street

    Louisville, KY 40202

    Humana.com

    (502) 476-2538 or 407-7266