F49090...

Ok, so I know that F49090 is a workday calendar. And that it's not the one we actually use. But what does use it? It's being selected from at the somewhat alarming rate of over 200 times per second in our system, and we're not sure what's actually issuing those selects -- according to the crossreference, it's used by B4900810, P49090, and R34A600, none of which we seem to be using. Any ideas?

Hi Scotti

What is R34A600 ? I just checked Xe and ERP 8.0 - and I don't see any reference to R34A600 in either install. I'd be surprised if that would use F49090.

Its description is "APS Transportation Calendar Extract"... I don't know exactly what it does, since we're not using it, I just saw it listed in the crossreference in my desperate search for what the heck is hitting that table so much.

Looking at our system (AS400) every JDENET_K allocates F49090. Do you have any _K's that are using excessive CPU cycles? Don't know how to translate that to your platform however...Just a random observation that might help.

Darrell

From: [email protected] [mailto:[email protected]] On B ehalf Of swhitmire
Sent: Tuesday, July 31, 2007 12:46 PM
To: [email protected]
Subject: F49090...

Ok, so I know that F49090 is a workday calendar. And that it's not the one we actually use. But what does use it? It's being selected from at the some what alarming rate of over 200 times per second in our system, and we're no t sure what's actually issuing those selects -- according to the crossrefer ence, it's used by B4900810, P49090, and R34A600, none of which we seem to be using. Any ideas?

--Scotti Whitmire DeRoyal Industries OW Xe, SP23_R1, U8, AIX 5.2, Oracle 10 .2.0.2 <*>

Re: RE: F49090...

Not to hijack Scotti's thread, but it isn't one specific jdenet_k process that has issued the statement. It does look like the majority of the calls are from jdenet_k processes in general.

The thing is, this process is executing thousands of times per minute ( actually 85 times per second ) and never returning any rows. I know the table is not populated for the current calendar year, and I'm not sure what will happen if we did populate it. So currently evertime it executes, it is doing a buffer cache read and returning no rows. So it is using cpu for every execution.

If we populate it I could see a couple of things possibly happening.

1. The process gets it data and quits making the request.
2. The process finds data and then starts pulling data for every request and uses more resources.
3. It was never expecting data and when it finds some, it breaks other processes.

What do you mean exactly by "allocates F49090"?

RE: RE: F49090...

It's a term borrowed from back in my OLD DEC PDP/VAX days that rises to the surface when I'm not looking. It means that a process has opened and has control of the file. It could be exclusive or shared but ultimately that p rocess controls that file. Other applications or processes can open that f ile but if another process needs exclusive access, it will have to wait til l the original releases or deallocates the file. I'm not sure what the equ ivalent term would be on the iSeries. I'm not really sure this is truly t he case in this instance but it plays ok in my head. At any rate as I had said, I was just tossing in an observation, good or bad, in hopes it might mean something. But I've seen JDENET's run crazy and suck down gobs of CPU with no apparent explanation. Thought this might be one of those times. Sorry if I've just confused the issue.

Darrell

From: [email protected] [mailto:[email protected]] On B ehalf Of BenA
Sent: Friday, August 03, 2007 12:35 PM
To: [email protected]
Subject: Re: RE: F49090...

Not to hijack Scotti's thread, but it isn't one specific jdenet_k process t hat has issued the statement. It does look like the majority of the calls a re from jdenet_k processes in general.

The thing is, this process is executing thousands of times per minute ( act ually 85 times per second ) and never returning any rows. I know the table is not populated for the current calendar year, and I'm not sure what will happen if we did populate it. So currently evertime it executes, it is doin g a buffer cache read and returning no rows. So it is using cpu for every e xecution.

If we populate it I could see a couple of things possibly happening.

1. The process gets it data and quits making the request.
2. The process finds data and then starts pulling data for every request an d uses more resources.
3. It was never expecting data and when it finds some, it breaks other proc esses.

What do you mean exactly by "allocates F49090"?

! Ben Alvey DeRoyal Industries, Sr Systems Analyst/DBA OWXE, AIX5L, Oracle 10.2.0.2

Re: RE: RE: F49090...

Thanks for the explanation.

One other thing, I'm wondering if you could question your dba to see how many executions you have against that table? For the sql statement

SELECT * FROM PRODDTA.F49090 WHERE ( CZMMCU = :KEY1 AND CZWDCT = :KEY2 AND CZWDCK = :KEY3 AND CZCTRY = :KEY4 AND CZYR = :KEY5 AND CZMT = :KEY6 )

in particular. I'm just curious if this is "normal" behaviour that we are seeing and if others actually keep this table up to date.