Re:Re: Area's defined to a subschema

[ca.portal.admin]

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 [e-mail]
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
[e-mail]
SMTP
[e-mail]
[e-mail]
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: [phone]
Telefax: 336-393-4080
E-mail: [e-mail]
"
IDMS 3rd-party providers forum
[e-mail]
SMTP
[e-mail]
[e-mail]
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: [phone]
Telefax: 336-393-4080
E-mail: [e-mail]
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
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
[e-mail]

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
[e-mail]
SMTP
[e-mail]
[e-mail]
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
[e-mail]

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
[e-mail]
SMTP
[e-mail]
[e-mail]
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