Incorrect APPLWAIT with wait for previous generation

[Neil_Simmonds]

Hi all, we have an issue with a few applications where on the 22nd May this year we had a major issue wit out CAWA DSeries system which was 11.3.1 and we ended up upgrading to 11.3.3 on the fly to fix the issue.

 

Since then we have been unable to use the wait for previous generation flag on a number of applications as they immediately go into an Applwait state. We suspected it was due to the applications from the 22nd May which are showing in the database as STATE = COMPLETE but with no END_DATE_TIME value (it's NULL). That seems to fit as other applications which have good entries on the 22nd May don't have the issue. 

 

In an attempt to sort this without having to resort to a cold start we have been looking at our data. We founf that we had about 4 years worth of data on ESP_GENERIC_JOB and ESP_APPLICATION as we hadn't been running MOVEHISTORYDATA due to a bug in 11.3.1. 

 

We have now run that and we have 120 days on live tables and another 280 days on history. This has moved the 22nd May onto history tables. 

 

On Friday, I tested one of the problem applications that runs every hour and set the "wait for previous generation" flag on then uploaded the app, I then triggered it and it worked OK. The next scheduled run at 14:00 also worked OK but then from 15:00 they started coming back on in APPLWAIT atate again despite the fact that the previous two had completed ok. 

 

I've since tested again this morning and it is still happening if I set the wait for previous generation flag back on. 

 

I'd really like to get this sorted but a cold start is not feasible (there is never a time when nothing is running and this issue is not a showstopper so it's not justified) 

 

I'd thought about deleting the lines where END_DATE_TIME is null from the history tables but not sure what effect this might have on the system. 

 

Has anyone any ideas as to what we could do? 

[SHARON SHIMANEK]

we recently had this issue in non prod but for us the records were only in WSS_APPL, WSS_JOB and RTWOB. 

 

we know application in questions I ran sql specific to that appl.gen.

select * from WA.ESP_WSS_APPL where WA.ESP_WSS_APPL.appl_name = 'EDMS_UAT';

 

we thought we had the issue with 1 application.gen but after doing this we found out we had 7.  However our applications that thought they were active were only in WSS_APPL, WSS_JOBS and RTWOB, the records were not in ESP_GENERIC_JOB or ESP_APPLICATION

SELECT * FROM WA.ESP_WSS_APPL WHERE NOT EXISTS (SELECT 1 FROM WA.ESP_APPLICATION APPL WHERE WA.ESP_WSS_APPL.appl_name = APPL.appl_name and WA.ESP_WSS_APPL.appl_gen_no=APPL.appl_gen_no)

 

ca had us

bring down manager, and db, back up database, run sql to update the status of 1 to 2 on the applications in question.  start up again and that fixed our issue

update ESP_WSS_APPL set STATUS = 2 where APPL_NAME = 'EDMS_UAT' and APPL_GEN_NO = 50686;

[Leandro Laurenti]

In addition to what Shimaneks mentioned, you can refer to the following article:

 

https://comm.support.ca.com/kb/applications-stuck-in-processing/kb000007217

[Neil_Simmonds]

We've now updated the ESP_WSS_APPL table but we still have the issue. I've looked at the ESP_RTWOB table and there are 30 entries in thee that need updating but I'm not sure what to update. I'm guessing at "update ESP_RTWOB SET THESTATE = 'COMPLETE' and COMPLETE = 'T' WHERE APPLID = " for the relvant APPLID's but if anyone knows for sure that would be very helpful. 

[Ravi Kiran Kunduri]

Hi,

 

Can you please let me know if you got this problem again in the recent past.

 

Thanks and regards,

Ravi Kiran

[Neil_Simmonds]

Hi Ravi, 

We can currently replicate this issue at any time by adding "wait for previous generation" to about 27 of our applications. We still don't know how to fix it and the most recent advice from CA is a cold start which is going to be very difficult for us to do. 

Regards,

Neil Simmonds