CA IDMS IUA EIUA

Re:Re: Area's defined to a subschema

  • 1.  Re:Re: Area's defined to a subschema

    Posted 05-19-2010 08:18 AM
    Look at the SSA-024 record in the dictionary.

    You can use Culprit, or OLQ or write a real program.
    s-nam-024 Schema
    ss-name-024 Subschema
    ssa-name-024 Area

    SS=IDMSNWKA
    DICT=SYSDIRL
    DBN=application dictionary name

    Tommy Petersen





    ""Barta, Michael""
    <Michael.Barta@IN
    FOCROSSING.COM>
    To
    Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
    Public Discussion
    cc
    Forum
    <IDMS-L@LISTSERV.
    Subject
    IUASSN.COM> Area's defined to a subschema


    05/19/2010 10:44
    AM


    Please respond to
    IDMS Public
    Discussion Forum
    <IDMS-L@LISTSERV.
    IUASSN.COM>






    I have one schema that has many subschemas associated with it. I'm
    trying to find out what areas are included in a particular subschema.
    Is there a easy way to find this information besides displaying each
    subschema?

    Mike Barta



    Confidentiality Note: This e-mail, including any attachment to it, may
    contain material that is confidential, proprietary, privileged and/or
    ""Protected Health Information,"" within the meaning of the regulations
    under
    the Health Insurance Portability & Accountability Act as amended. If it
    is
    not clear that you are the intended recipient, you are hereby notified
    that
    you have received this transmittal in error, and any review,
    dissemination,
    distribution or copying of this e-mail, including any attachment to it,
    is
    strictly prohibited. If you have received this e-mail in error, please
    immediately return it to the sender and delete it from your system.
    Thank
    you.

    Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or ""Protected Health Information,"" within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    American Express to North Carolina
    "Hello All,

    There was a newspaper article today stating that American Express will=
    build a new data center in the Greensboro area. Does anyone know if they u=
    se IDMS?

    Thanks for your info.


    _________________________________________________
    John N. Baloga
    IDMS DBA, Global I & O
    Volvo Information Technology
    7825 National Service Road, Greensboro, NC 27409
    United States of America

    Telephone: 336-393-3425
    Telefax: 336-393-4080
    E-mail: john.baloga@volvo.com
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    American Express to North Carolina
    "Hello All,

    There was a newspaper article today stating that American Express will build a new data center in the Greensboro area. Does anyone know if they use IDMS?

    Thanks for your info.


    _________________________________________________
    John N. Baloga
    IDMS DBA, Global I & O
    Volvo Information Technology
    7825 National Service Road, Greensboro, NC 27409
    United States of America

    Telephone: 336-393-3425
    Telefax: 336-393-4080
    E-mail: john.baloga@volvo.com
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    something to ponder - is CA-IDMS R17 z/IIP exploitation right for your CVs?
    "Is IDMS r17 z/IIP exploitation right for you?
    Chris Hoelscher
    Senior DB2 and IDMS DBA
    Humana Inc.

    (note ? the following represents my experiences and my experiences alone=20
    implementing , monitoring, and tuning z/IIP exploitation across our IDMS=20
    enterprise. The opinions expressed herein do not necessarily reflect thos=
    e=20
    of any other site or CA Technologies. Any part of this document may be=20
    reproduced, with or without the express written consent of Major League=20
    Baseball).
    z/IIP processor exploitation is a very powerful and popular feature of=20
    CA-IDMS Release 17; proper exploitation can certainly create white space=20
    (diverting cpu cycles to z/IIP processor(s) allowing room for additional=20
    non-z/IIP processing that otherwise would have nowhere else to immediatel=
    y=20
    execute) and saving money (formerly billable CPU cycles are diverted to=20
    z/IIP processors and become non-billable). But how do we determine proper=
    =20
    exploitation?
    When I moved our IDMS production environments to Release 17 in=20
    April 2009, and implemented z/IIP exploitation immediately upon the=20
    upgrade, we saw an immediate overall 20% reduction in billable CPU cycles=
    ,=20
    and I was informed by our performance/billing monitoring group that due t=
    o=20
    the cpu reduction, we could (under the provisions of our licensing=20
    agreement) reduce our payments for IDMS by an annualized amount in 6=20
    figures. Admittedly, I felt rather pleased with myself and accepted the=20
    results without further examination. In other words, I rested upon my=20
    laurels with regard to z/IIP. In fact, I was so pleased with our results=20
    that I made a point of sharing my results with the IDMS user community.=20
    Also, having other work activities to complete, I did not, at that point,=
    =20
    investigate z/IIP exploitation further.
    Then a funny thing happened; In early 2010 DBAs at other sites=20
    emailed me privately with some concern. What was I doing that they were=20
    not? Their results were substantially different than mine. Admittedly, I=20
    was baffled, but could not let a good challenge go unanswered. I began to=
    =20
    investigate each of our on-line environments in depth, and the results=20
    were very surprising (at least to me).
    To explain these surprising results, let?s take a very broad -loo=
    k=20
    at what happens during the life of an average task, both in a non-z/IIP=20
    environment (ZIIP=3DN specified on the EXEC JCL card PARM attribute), and=
    a=20
    real or simulated z/IIP environment (ZIIP=3DY). In non-z/IIP mode, the ta=
    sk=20
    executes whatever it needs to do, both ?user (non-DB or DC calls)? and=20
    ?system (database and communication calls and system housekeeping)? code,=
    =20
    consumes CPU, and finishes (for this example, consuming instructions=20
    equivalent to 0.02 CPU seconds). The machine instructions, without regard=
    =20
    to content, are executed in ?TCB? mode, anchored off one or more TCB=20
    control blocks. In ZIIP=3DY mode, the same task would continue to execute=
    =20
    all ?user? code and specifically-excluded ?system? code in TCB mode, but=20
    would execute all non-excluded ?system? code in ?SRB? mode, and a portion=
    =20
    of that ?SRB? mode instructions (in our testing we reached a high water=20
    mark of 33%) would be routed to a z/IIP processor for (billing-free)=20
    execution. Were there no overhead to ZIIP=3DY mode processing, this=20
    ?average? task would consume the same .02 seconds of CPU (an instruction=20
    is an instruction, be it processed on a regular or z/IIP processor,=20
    right?), but, alas, there is overhead to ZIIP=3DY mode processing.
    What, then, is this overhead that can so drastically affect z/IIP=
    =20
    exploitation results? It is the CPU instructions consumed to move an=20
    executing process from TCB mode to SRB mode and vice versa. The number o=
    f=20
    swaps occurring can easily be seen in the DCMT D SUBT *** (where *** is=20
    001 in a non-multitasking site) beside the heading Count actual swaps.=20
    Some IDMS environments (CVs), such as a CV at my site where nearly 90% of=
    =20
    our tasks execute, is exclusively a back-end for CICS (and other IDMS=20
    CV?s) front end transactions. In this type of environment, there is NO=20
    user code, and as such, very low swapping between TCB and SRB modes (the=20
    only swapping would occur when swapping between included and excluded=20
    system code). In this environment we averaged from 0.5 to 1.7 ?swaps? per=
    =20
    task. In other environments at our site, we have tasks that execute user=20
    and system code, but are very simple in design, and do not require many=20
    swaps. In these environments, I have recorded an average of 50 to 125=20
    swaps per task. Lastly, we have a few online environments where the tasks=
    =20
    are ADS/O and DC-COBOL, and have very complex user code intermixed with D=
    B=20
    and DC calls. In these environments, I have recorded averages of over 250=
    0=20
    swaps per task!
    How can I determine if the overhead is defeating the benefits of=20
    z/IIP exploitation, as so clearly seemed the case to the sites with whom =
    I=20
    was corresponding? Every observation will have its own sets of caveats,=20
    but this is the method I chose to investigate: in ZIIP=3DN mode, we=20
    determined the average CPU per task (in my fictional example, 0.02=20
    seconds) . In ZIIP=3DY mode, any additional CPU per task is attributable =
    to=20
    z/IIP overhead (let?s say, 0.025 total CPU task, for an overhead of 0.005=
    =20
    cpu seconds per task (and this overhead currently executes in TCB mode).=20
    The next step is to determine the average z/IIP-processed CPU per task=20
    (from summing the ZIIP counts (in cpu seconds) from DCMT D SUBT *** (zIIP=
    =20
    time) for each subtask. In our example, let?s say that the average z/IIP=20
    per task is .008 cpu seconds ? then we have shown that each task has a ne=
    t=20
    reduction in billable CPU of .002 seconds (.008 z/IIP transfer - .005=20
    z/IIP overhead). In this case we are doing a good thing. But what if the=20
    results showed that we are now executing in ZIIP=3DY mode 0.03 total CPU=20
    seconds per task (with a resulting overhead of 0.01 cpu seconds/task, or=20
    150% of the original CPU, but still routing that same .008 cpu=20
    seconds/task to z/IIP? In this case we are costing ourselves .002 billabl=
    e=20
    cpu seconds/task (.008 z/IIP transfer - .010 z/IIP overhead). In these=20
    cases, z/IIP exploitation is certainly not beneficial. This appears to be=
    =20
    the scenario that other sites are experiencing, and (previously=20
    unbeknownst to me, at my site as well). I am in the process of extensivel=
    y=20
    testing CVs with high swap rates AND DEFERRING z/IIP EXPLOITATION until=20
    release 18.=20
    What did he say, you might be asking yourself, RELEASE 18? Releas=
    e=20
    17 has only been GA for 18 months. What is up with Release 18 (announced=20
    as GA possibly in May 2011)? *** the following is based only upon current=
    =20
    plans of CA Technologies (yep another name change ? in the name game they=
    =20
    are catching up to Elizabeth Taylor!!) as announced at CA-WORLD 2010 -=20
    nothing is guaranteed nor should be construed as a promise for Release 18=
    =2E=20
    Having said that, the announced plans are to improve z/IIP efficiency in=20
    the newest release, and I can only assume/hope that the improved=20
    efficiency will be in the area of swap management. CA acknowledged that=20
    z/IIP exploitation, like multitasking and shared cache exploitation befor=
    e=20
    it, was introduced at one release with favorable results, and will be=20
    continually refined in subsequent results for closer to optimal results.=20
    Are there activities you can perform to make your CVs more z/IIP=20
    friendly in Release 17 RIGHT NOW ??? Surprisingly, the answer is YES. If=20
    you can identify periods of time (evening and or weekend batch cycles )=20
    where swapping is low, consider multiple CV startup configurations=20
    (requiring CV bouncing) to match ZIIP=3D value to the type of processing=
    =20
    occurring within each time interval. I have identified 2 candidate CVS=20
    with high swapping on the weekend and low swapping during the week which =
    I=20
    will attempt such a startup (dare I say) swap. Additionally, while beyond=
    =20
    the scope of what I have the time (and authority) to investigate, and not=
    =20
    much hope of success, there is the possibility that application=20
    re-engineering might have success in reducing application TCB/SRB=20
    swapping. One last idea, if it is possible to remove any user exits that=20
    your tasks hit, you can remove a large hindrance to successful z/IIP=20
    exploitation. At our site, our least z/IIP-friendly CVs execute exit 23=20
    for every ads or cobol run unit ? and this appears to be a very big=20
    contributor to swapping.
    In the end, I will admit that initially I treated z/IIP=20
    exploitation as I would the Ronco Showtime Compact Rotisserie and Barbequ=
    e=20
    Oven ? to SET IT AND FORGET IT. Obviously, a global policy toward z/IIP=20
    exploitation may be acceptable as a very first intention, but simply=20
    cannot lead to optimum results.

    Chris Hoelscher
    IDMS/DB2 Database Architect
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly=20




    The information transmitted is intended only for the person or entity to =
    which it is addressed and may contain CONFIDENTIAL material. If you rece=
    ive this material/information in error, please contact the sender and del=
    ete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    something to ponder - is CA-IDMS R17 z/IIP exploitation right for your CVs?
    "Is IDMS r17 z/IIP exploitation right for you?
    Chris Hoelscher
    Senior DB2 and IDMS DBA
    Humana Inc.

    (note ? the following represents my experiences and my experiences alone
    implementing , monitoring, and tuning z/IIP exploitation across our IDMS
    enterprise. The opinions expressed herein do not necessarily reflect those
    of any other site or CA Technologies. Any part of this document may be
    reproduced, with or without the express written consent of Major League
    Baseball).
    z/IIP processor exploitation is a very powerful and popular feature of
    CA-IDMS Release 17; proper exploitation can certainly create white space
    (diverting cpu cycles to z/IIP processor(s) allowing room for additional
    non-z/IIP processing that otherwise would have nowhere else to immediately
    execute) and saving money (formerly billable CPU cycles are diverted to
    z/IIP processors and become non-billable). But how do we determine proper
    exploitation?
    When I moved our IDMS production environments to Release 17 in
    April 2009, and implemented z/IIP exploitation immediately upon the
    upgrade, we saw an immediate overall 20% reduction in billable CPU cycles,
    and I was informed by our performance/billing monitoring group that due to
    the cpu reduction, we could (under the provisions of our licensing
    agreement) reduce our payments for IDMS by an annualized amount in 6
    figures. Admittedly, I felt rather pleased with myself and accepted the
    results without further examination. In other words, I rested upon my
    laurels with regard to z/IIP. In fact, I was so pleased with our results
    that I made a point of sharing my results with the IDMS user community.
    Also, having other work activities to complete, I did not, at that point,
    investigate z/IIP exploitation further.
    Then a funny thing happened; In early 2010 DBAs at other sites
    emailed me privately with some concern. What was I doing that they were
    not? Their results were substantially different than mine. Admittedly, I
    was baffled, but could not let a good challenge go unanswered. I began to
    investigate each of our on-line environments in depth, and the results
    were very surprising (at least to me).
    To explain these surprising results, let?s take a very broad -look
    at what happens during the life of an average task, both in a non-z/IIP
    environment (ZIIP=N specified on the EXEC JCL card PARM attribute), and a
    real or simulated z/IIP environment (ZIIP=Y). In non-z/IIP mode, the task
    executes whatever it needs to do, both ?user (non-DB or DC calls)? and
    ?system (database and communication calls and system housekeeping)? code,
    consumes CPU, and finishes (for this example, consuming instructions
    equivalent to 0.02 CPU seconds). The machine instructions, without regard
    to content, are executed in ?TCB? mode, anchored off one or more TCB
    control blocks. In ZIIP=Y mode, the same task would continue to execute
    all ?user? code and specifically-excluded ?system? code in TCB mode, but
    would execute all non-excluded ?system? code in ?SRB? mode, and a portion
    of that ?SRB? mode instructions (in our testing we reached a high water
    mark of 33%) would be routed to a z/IIP processor for (billing-free)
    execution. Were there no overhead to ZIIP=Y mode processing, this
    ?average? task would consume the same .02 seconds of CPU (an instruction
    is an instruction, be it processed on a regular or z/IIP processor,
    right?), but, alas, there is overhead to ZIIP=Y mode processing.
    What, then, is this overhead that can so drastically affect z/IIP
    exploitation results? It is the CPU instructions consumed to move an
    executing process from TCB mode to SRB mode and vice versa. The number of
    swaps occurring can easily be seen in the DCMT D SUBT *** (where *** is
    001 in a non-multitasking site) beside the heading Count actual swaps.
    Some IDMS environments (CVs), such as a CV at my site where nearly 90% of
    our tasks execute, is exclusively a back-end for CICS (and other IDMS
    CV?s) front end transactions. In this type of environment, there is NO
    user code, and as such, very low swapping between TCB and SRB modes (the
    only swapping would occur when swapping between included and excluded
    system code). In this environment we averaged from 0.5 to 1.7 ?swaps? per
    task. In other environments at our site, we have tasks that execute user
    and system code, but are very simple in design, and do not require many
    swaps. In these environments, I have recorded an average of 50 to 125
    swaps per task. Lastly, we have a few online environments where the tasks
    are ADS/O and DC-COBOL, and have very complex user code intermixed with DB
    and DC calls. In these environments, I have recorded averages of over 2500
    swaps per task!
    How can I determine if the overhead is defeating the benefits of
    z/IIP exploitation, as so clearly seemed the case to the sites with whom I
    was corresponding? Every observation will have its own sets of caveats,
    but this is the method I chose to investigate: in ZIIP=N mode, we
    determined the average CPU per task (in my fictional example, 0.02
    seconds) . In ZIIP=Y mode, any additional CPU per task is attributable to
    z/IIP overhead (let?s say, 0.025 total CPU task, for an overhead of 0.005
    cpu seconds per task (and this overhead currently executes in TCB mode).
    The next step is to determine the average z/IIP-processed CPU per task
    (from summing the ZIIP counts (in cpu seconds) from DCMT D SUBT *** (zIIP
    time) for each subtask. In our example, let?s say that the average z/IIP
    per task is .008 cpu seconds ? then we have shown that each task has a net
    reduction in billable CPU of .002 seconds (.008 z/IIP transfer - .005
    z/IIP overhead). In this case we are doing a good thing. But what if the
    results showed that we are now executing in ZIIP=Y mode 0.03 total CPU
    seconds per task (with a resulting overhead of 0.01 cpu seconds/task, or
    150% of the original CPU, but still routing that same .008 cpu
    seconds/task to z/IIP? In this case we are costing ourselves .002 billable
    cpu seconds/task (.008 z/IIP transfer - .010 z/IIP overhead). In these
    cases, z/IIP exploitation is certainly not beneficial. This appears to be
    the scenario that other sites are experiencing, and (previously
    unbeknownst to me, at my site as well). I am in the process of extensively
    testing CVs with high swap rates AND DEFERRING z/IIP EXPLOITATION until
    release 18.
    What did he say, you might be asking yourself, RELEASE 18? Release
    17 has only been GA for 18 months. What is up with Release 18 (announced
    as GA possibly in May 2011)? *** the following is based only upon current
    plans of CA Technologies (yep another name change ? in the name game they
    are catching up to Elizabeth Taylor!!) as announced at CA-WORLD 2010 -
    nothing is guaranteed nor should be construed as a promise for Release 18.
    Having said that, the announced plans are to improve z/IIP efficiency in
    the newest release, and I can only assume/hope that the improved
    efficiency will be in the area of swap management. CA acknowledged that
    z/IIP exploitation, like multitasking and shared cache exploitation before
    it, was introduced at one release with favorable results, and will be
    continually refined in subsequent results for closer to optimal results.
    Are there activities you can perform to make your CVs more z/IIP
    friendly in Release 17 RIGHT NOW ??? Surprisingly, the answer is YES. If
    you can identify periods of time (evening and or weekend batch cycles )
    where swapping is low, consider multiple CV startup configurations
    (requiring CV bouncing) to match ZIIP= value to the type of processing
    occurring within each time interval. I have identified 2 candidate CVS
    with high swapping on the weekend and low swapping during the week which I
    will attempt such a startup (dare I say) swap. Additionally, while beyond
    the scope of what I have the time (and authority) to investigate, and not
    much hope of success, there is the possibility that application
    re-engineering might have success in reducing application TCB/SRB
    swapping. One last idea, if it is possible to remove any user exits that
    your tasks hit, you can remove a large hindrance to successful z/IIP
    exploitation. At our site, our least z/IIP-friendly CVs execute exit 23
    for every ads or cobol run unit ? and this appears to be a very big
    contributor to swapping.
    In the end, I will admit that initially I treated z/IIP
    exploitation as I would the Ronco Showtime Compact Rotisserie and Barbeque
    Oven ? to SET IT AND FORGET IT. Obviously, a global policy toward z/IIP
    exploitation may be acceptable as a very first intention, but simply
    cannot lead to optimum results.

    Chris Hoelscher
    IDMS/DB2 Database Architect
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly




    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: American Express to North Carolina
    " They had a UK data center some time ago and used IDMS. I used to see some=
    of the employees at the UK IUA meetings. I believe they shut that data ce=
    nter awhile back. Not sure if they are still using IDMS or not.

    Leslie Jordan


    =20

    =20