05149 - Note 0450351 - CHKXDA - check for and then end "orphan" QXDARECVR jobs

05149 - Note 0450351 - CHKXDA - check for and then end "orphan" QXDARECVR jobs

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   CPI1466 during Backup  
This documentation is copyright by SAP AG.
SAP E-Book

Note 0450351 - CHKXDA - check for and then end "orphan" QXDARECVR jobs

Hi Volker,

Since we've not stopped SAP since Jan 5; our joblogs are quite long
Yes, I'm impressed with the fact that CHKXDA even handled that much garbage.

I reviewed all the *NONE jobs
-If they were created by our IPL'd application server instance userid; and the
job stat showed that it started before the date the app server IPL'd' I ended
the job (since all COMM to that box should have ended with the IPL); ended 8
QXDARECVR jobs manually

We do not typically have this kind of mess; but on this last (run out of disk)
IPL it occurred at midnight and I did not get awakened by the 3rd shift operator
- In the past, the IPL's have not been clean and I have needed to get involved;
gotten good at ending 40 QXDARECVR jobs at 3am - its quite incentive to key (4 -
F4 - *immed) quickly.

Anyway, enough silly remarks....No, I do not believe that there needs to be any
enhancement - I just wanted to provide feedback on the tool

Doreen Anderson
Ball Horticultural Company
(630) 231-3600 x3214

-----Original Message-----
From: Gueldenpfennig, Volker [mailto:volker.gueldenpfennigZs...]
Sent: Wednesday, February 20, 2002 3:01 AM
To: 'dandersoZb...'
Cc: Sap400 (E-mail)
Subject: RE: Note 0450351 - CHKXDA - check for and then end
"orphan" QXDARECVR jobs

Hi Doreen,

I'm aware of this situation, that you could get *NONE because of wrapped
joblogs. First I think, it's fine, that the tool worked at all! Because it
is designed, to be started first (e.g. in the QSTRUP).
Then you do have the point, that no QXDARECVR jobs are there. Then, when you
start SAP, the first ones appear and they become checked within 1 minute.
Then the joblogs will be very small (I would say for 99,999% nnot already
wrapped) and then the CHKXDA will complete the round in a few sends perhaps
a few minutes and will check again after 1 more minute. Your job took the
first time about 5 hours because of the long joblogs.
As CHKXDA reads every joblog only once at the beginning and then enters the
results in the table XDAJOBS, it is very fast after the first round, because
either none new QXDARECVR appears or only a very few ones, that do have
small joblogs.

Thanks a lot for your good and detailed feedback on this tool!

Please let me know, if you still would appreciate enhancements to this tool,
because I think there are not that easy, because it is really hard to detect
on the DB-server where a wrapped QXDAREVR belongs to. I don't want to add
any code in the kernel, if possible.

Please let me espeically know, if you detect again jobs with *NONE, that are
attached to WPs, because I really would say, that this won't happen, if you
start this job before. As you probably can't cycle the system at the moment,
you could have a look into every *NONE job and if it would be a WP shadow
job, that you then stop the WP on the appl-server and if necessary
afterwards the shadow job on the db-server if it doesn't die automatically.
All new created WPs then should appear correctly in the XDAJOBS table.

Hope, this helps a bit,


> -----Original Message-----
> From: Anderson, Doreen [mailto:dandersoZb...]
> Sent: Dienstag, 19. Februar 2002 18:14
> To: SAP AS/400 Discussion Group
> Subject: Note 0450351 - CHKXDA - check for and then end
> "orphan" QXDARECVR jobs
> We put "CHKXDA" to the test for the first time on our
> production DB last night
> CHKXDA had 133 active QXDARECVR jobs to review which took
> 5hrs to complete
> The result was; 37 QXDARECVR jobs were ended due to being duplicates
> CHKXDA had a lot of checking to do because the night before,
> one of our application servers IPL'd due to running out of
> storage caused by a 6hr running SDV03V02 rescheduling job
> submitted by a user.
> When an app server "goes down" this way; the orphaned
> QXDARECVR jobs are never handled properly
> CHKXDA program could have a little improvement made to
> it................
> There are some of the QXDARECVR jobs which are contained in
> file XDAJOBS with a *NONE for the PID which is not correct
> From what I could tell; the joblog is scanned for each
> QXDARECVR job to determine the app server PID that it belongs to
> We have many occurrences where the joblog "wraps" and the PID
> information is not contained anymore;
> hence the *NONE - but these are also duplicates and should be ended
> Trying to come up with a way to also end the duplicate
> QXDARECVR where the joblogs have wrapped.......
> Maybe the XDAJOBS file could have "START DATE"; "START TIME";
> and either "CURRENT USER PROFILE" or "JOB USER IDENTITY" added to it;
> Then maybe generate a report for the entries in XDAJOBS and
> *NONE entries in XDAJOBS so that those jobs can be
> interrogated by the customer and deleted manually if necessary
> Just my thoughts
> Doreen Anderson
> Ball Horticultural Company
> dandersoZb...
> (630) 231-3600 x3214
> [Non-text portions of this message have been removed]
> ------------------------ consolut Sponsor
> ---------------------~-->
> Sponsored by VeriSign - The Value of Trust
> Secure all your Web servers now - with a proven 5-part
> strategy. The FREE Server Security Guide shows you how.
> --------------------------------------------------------------
> -------~->
> Have a look to our homepage at:
> Your use of consolut is subject to

Durban Tours - Südafrika Safari

TXBHW - Original Tax Base Amount in Local Currency   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.

Length: 7641 Date: 20240305 Time: 081816     sap01-206 ( 4 ms )