ca.portal.admin

Batch jobs - CV vs Local

Discussion created by ca.portal.admin on Apr 16, 2007
Hi all,

When a batch job runs in Local mode, the CPU usage is reported in the JES2
joblog. However, when a batch job runs in CV mode, the CPU usage is not
shown in the JES2 joblog, as it is actually the CV which is chewing up the
CPU.

I've had look through a couple of the manuals, and there appear to be a
couple of possibilities for measuring the CPU usage by a batch CV job:
1: DCMT DISPLAY SUBTASK
2: OPER WATCH TIME

However, it would also seem, that the only way to get an accurate statistic
is to be logged onto IDMS-DC while the actual batch job IS running, so that
you can monitor (in real-time) the progress of the OPER WATCH TIME.

Could someone please clarify this question for me. Thanks very much.

Mike.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
WSJ.com - Directors' Probe Ties CA Founder To Massive Fraud
"*Please note, the sender's email address has not been verified.



For those of you wondering if Charles is going to get his comeupance...




********************

If you are having trouble with any of the links in this message, or if the URL's are not appearing as links, please follow the instructions at the bottom of this email.

Title: WSJ.com - Directors' Probe Ties CA Founder To Massive Fraud
This article will be available to non-subscribers of the Online Journal for up to seven days after it is e-mailed.

Copy and paste the following into your Web browser to access the sent link:
http://www.emailthis.clickability.com/et/emailThis?clickMap=viewThis&etMailToID=1782070733&pt=Y




Copy and paste the following into your Web browser to SAVE THIS link:
http://www.savethis.clickability.com/st/saveThisPopupApp?clickMap=saveFromET&partnerID=150&etMailToID=1782070733&pt=Y


Copy and paste the following into your Web browser to forward this link:
http://www.emailthis.clickability.com/et/emailThis?clickMap=forward&etMailToID=1782070733&partnerID=150&pt=Y



********************


Email pages from any Web site you visit - add the EMAIL THIS button to your browser, copy and paste the following into your Web browser:
http://www.emailthis.clickability.com/et/emailThis?clickMap=browserButtons&pt=Y""


*********************



Instructions:
-----------------------------------------
If your e-mail program doesn't recognize Web addresses:
1. With your mouse, highlight the Web Address above. Be sure to highlight the entire Web address, even if it spans more than one line in your email.
2. Select Copy from the Edit menu at the top of your screen.
3. Launch your Web browser.
4. Paste the address into your Web browser by selecting Paste from the Edit menu.
5. Click Go or press Enter or Return on your keyboard.

********************
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Batch jobs - CV vs Local
"Cheers, thanks very much for the help guys. Much appreciated.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Batch jobs - CV vs Local
"Mike -

In the SYSTEM statement of the SYSGEN, you can specify STATISTICS....TASK
WRITE USER.....

You will get a statisitcs record for every execution of an online task or
batch run-unit.

Then you can run an IDMSBCF PRINT LOG job to print the log specifying that
you want STATISTICS.

The keyword USER above will break the CPU time down into user-mode and
system-mode CPU components.

For a batch program, user-mode CPU time will be zero because that component
of CPU is burned by the program running in the class initiator.

Hope this gets you started.

Jon Gocher


----- Original Message -----
From: ""Mike Baker"" <mikebaker345@HOTMAIL.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, April 16, 2007 5:40 AM
Subject: Batch jobs - CV vs Local

Hi all,

When a batch job runs in Local mode, the CPU usage is reported in the JES2
joblog. However, when a batch job runs in CV mode, the CPU usage is not
shown in the JES2 joblog, as it is actually the CV which is chewing up the
CPU.

I've had look through a couple of the manuals, and there appear to be a
couple of possibilities for measuring the CPU usage by a batch CV job:
1: DCMT DISPLAY SUBTASK
2: OPER WATCH TIME

However, it would also seem, that the only way to get an accurate
statistic
is to be logged onto IDMS-DC while the actual batch job IS running, so
that
you can monitor (in real-time) the progress of the OPER WATCH TIME.

Could someone please clarify this question for me. Thanks very much.

Mike.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Sanjay's troubles continue to mount ... the latest
"http://www.washingtonpost.com/wp-dyn/content/article/2007/04/19/AR2007041900004.html?hpid=entnews




This is Chris Hoelscher and I approved this message!

Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com



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
CA-World
"Would anyone who attended CA-World be willing to provide a summary or
points of interest, for those of us who were unable to attend?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: INDEX Updating
"Claude,

Check out your IBC settings. The load IBC should be much smaller than the run-time
IBC to allow for these index inserts. Note: Not much of anything will help if all the
new records are indexed to the same (or similar) key. (For example an index of yyyymmdd<seq> will cause
all sorts of problems if the date involved is the current date of the index records store.

Dick Pierce
DBA, State of Mass Registry of Motor Vehicles running 3 million transactions/day
richard.pierce@state.ma.us

Date: Tue, 24 Apr 2007 20:41:58 -0500
From: JEC <jectec@WORLDNET.ATT.NET>
Subject: Re: INDEX Updating

All good replies from you all as usual,

First, the index is OM ASC.with about 8 million member records maximum. The
idea is to keep only the last month of records connected to the index.
Every week another job disconnects a number of records to limit the size of
the index.

The idea of unlinked index is something we will seriously consider.

Sort key in descending order is also a good idea

We have tried the TUNE INDEX but that would fix only the bottom level and
that utility is notoriously slow, at least according to our own tests.

One other idea: frequent index rebuilds. But that would be a weekly job.

I see we have a lot of testing in front of us this week.

Thanks again everybody,
Claude Ferland
Contractor, NYC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: INDEX Updating
"Hi Claude

In order to give a more tailored response to your query on how
to reduce the creation of orphans in your index, I need to know
the following information about your index.


Definitions:
===========

1. The SCHEMA definition of the INDEX.

2. If any ""sort-element-names"" in the ""key-expression"" in the
INDEX definition contains subordinate elements, please list
each such ""sort-element-name"" together with all its
subordinate elements.

Index value characteristics (for set members ONLY):
===================================================

3. For each ""sort-element-name"" in the SCHEMA definition and for
each subordinate element listed in ""2."" above, please list
the data element name with answers to the following questions:

a. Are the values for this element UNIQUE within the INDEX?

b. If the values for the element are NOT unique, how many
record occurrences (on average) share each non-unique
value within the INDEX:

1) on a daily basis

2) on a monthly basis

3) within the entire INDEX

c. Whether or not the values for this element UNIQUE, do the
values occur ""randomly"" or sequently:

1) on a daily basis

2) on a monthly basis

3) within the entire INDEX

Once I have a chance to analyze your responses to the above
questions, I will hopefully be able to give you some suggestions
that will help alleviate your orphan problem.


Gordon Fitz-Simons


JEC wrote:
Hello all,

We now have a job that inserts about 350,000 records in an index every day.
Heavy stuff. We also purge some entries on a weekly basis, so it won't grow
much more in size in the future.

That job has been running for a month and already has created a huge number
of orphans and of course performance went down the tube from there. It was
so bad we had to rebuild it.

Perhaps I could tap into your collective memory and ask how a program can
process that kind of volume without so many SR8 splits.

We know from experience that the structure of the index is fine, we have
many similar ones. The problem seems to be the massive updates against this
index. What we are looking for is a programming tip or tips. Otherwise
we'll have to rebuild this index every week.

TIA,

Claude Ferland
Contractor, NYC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: INDEX Updating
"Again some good and intriguing ideas from this ""collective"".

We basically have everything you mention below but I'm not sure we would get
into building a user index though.

But something to consider, thank you.

Claude Ferland
Contractor, NYC

----- Original Message -----
From: ""Martin Wieland"" <martin.wieland@NECKNET.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Wednesday, April 25, 2007 2:13 AM
Subject: Re: [IDMS-L] INDEX Updating


You could consider using a user indexed set, eg. creating top level
owner records (eg. one for each month or week) and make this an OM
indexed set. At the end of a month you only disconnect from the specific
month or week record(s). This should also result in a better
distribution of your SR8's over the available area space. Also use a lot
of pages and a fair amount of reserved space. For a system owned index
make sure you have a separate area and file(s) with separate buffers.
And make your IBC and page offset settings large enough!

Good luck,

Martin Wieland





-----Oorspronkelijk bericht-----
Van: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
Namens JEC
Verzonden: Tuesday, April 24, 2007 11:38 PM
Aan: IDMS-L@LISTSERV.IUASSN.COM
Onderwerp: INDEX Updating


Hello all,

We now have a job that inserts about 350,000 records in an index every
day. Heavy stuff. We also purge some entries on a weekly basis, so it
won't grow much more in size in the future.

That job has been running for a month and already has created a huge
number of orphans and of course performance went down the tube from
there. It was so bad we had to rebuild it.

Perhaps I could tap into your collective memory and ask how a program
can process that kind of volume without so many SR8 splits.

We know from experience that the structure of the index is fine, we have
many similar ones. The problem seems to be the massive updates against
this index. What we are looking for is a programming tip or tips.
Otherwise we'll have to rebuild this index every week.

TIA,

Claude Ferland
Contractor, NYC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
TCP/IP question
"I am using the IDMS TCP/IP sockets interface. For most errors, I get
return codes that are documented in the Z/OS ""UNIX Messages and Code""
manual. But when a ""get host"" command fails, either because I mistyped
the name or IP address, or because of a network/firewall problem, I get
the following:

- Return code: -1
- Error number: +1
- Reason code: +22313988 (if doing GETHOSTBYNAME) or +22248452 (if
doing GETHOSTBYADDR)

These reason codes are out of the ranges documented in the manual. Does
anyone know what they mean?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: INDEX Updating
"You could consider using a user indexed set, eg. creating top level
owner records (eg. one for each month or week) and make this an OM
indexed set. At the end of a month you only disconnect from the specific
month or week record(s). This should also result in a better
distribution of your SR8's over the available area space. Also use a lot
of pages and a fair amount of reserved space. For a system owned index
make sure you have a separate area and file(s) with separate buffers.
And make your IBC and page offset settings large enough!

Good luck,

Martin Wieland





-----Oorspronkelijk bericht-----
Van: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
Namens JEC
Verzonden: Tuesday, April 24, 2007 11:38 PM
Aan: IDMS-L@LISTSERV.IUASSN.COM
Onderwerp: INDEX Updating


Hello all,

We now have a job that inserts about 350,000 records in an index every
day. Heavy stuff. We also purge some entries on a weekly basis, so it
won't grow much more in size in the future.

That job has been running for a month and already has created a huge
number of orphans and of course performance went down the tube from
there. It was so bad we had to rebuild it.

Perhaps I could tap into your collective memory and ask how a program
can process that kind of volume without so many SR8 splits.

We know from experience that the structure of the index is fine, we have
many similar ones. The problem seems to be the massive updates against
this index. What we are looking for is a programming tip or tips.
Otherwise we'll have to rebuild this index every week.

TIA,

Claude Ferland
Contractor, NYC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: INDEX Updating
"Hello,
some useful tips on indexes:

1 insert in descending order
2 define an offset for the top level big enough
3 a lot of buffers (equal or bigger than the offset pages)
4 page reserve on the pages at least 30 % (better 40 %)

grz


Peter van de Ven

Outcomes