Unsolved
This post is more than 5 years old
2 Posts
0
377
April 9th, 2008 18:00
Operating system delays on DASD during SAR consistant splits
Having just upgraded last weekend to DMX4 boxes and running current releases of TF, RPB, RDF etc. Haven't had any issues until this morning. All of a sudden we are getting a BCVA021E "Timeout occurred during consistant split". This then stops the SAR processing.
It also looks as though this is either causing, or shares blame for cauing operating system and tasks to go into device delays waiting for the SAR processing (The SCF task has the DASD device allocated for split). Having increased the Timeout value from the default to a full 60 seconds the same thing happened almost immediately after restarting SAR.
I am running a zOS R1.7 operating system.
It also looks as though this is either causing, or shares blame for cauing operating system and tasks to go into device delays waiting for the SAR processing (The SCF task has the DASD device allocated for split). Having increased the Timeout value from the default to a full 60 seconds the same thing happened almost immediately after restarting SAR.
I am running a zOS R1.7 operating system.
No Events found!
xe2sdc
2 Intern
•
2.8K Posts
0
April 10th, 2008 00:00
Have a look at primus solution emc46008 .. You can easily find this solution with a search in Powerlink. Maybe restricting the search to "Support Solutions" will speed up your search
xe2sdc
2 Intern
•
2.8K Posts
0
April 10th, 2008 06:00
Davidy8s
154 Posts
0
April 10th, 2008 06:00
There's another knowledgebase entry emc60355 that is similar to the one Stefano indicated. All of these fixes are dated fairly old, but this one has an explanation which may be more instructive; polling for a flag set in a prev. rel. of microcode...
We would need specific versions & error msgs to fine tune this any further. Honestly, if neither of the mentioned knowledgebase entries provide any immediate path to relief then :
OPEN A SERVICE REQUEST NOW ! - before the degradation gets worse. Better to open an SR erring on the side of caution than to get into a scenario in which processes are grinding to a halt. BTW, if you do open an SR, don't leave us hanging, let us know what the outcome turns out to be
Best regards,
Dave Yates
Host S/W & Mainframe Moderator
royccmc
2 Posts
0
April 10th, 2008 08:00
Thx
Davidy8s
154 Posts
0
April 10th, 2008 09:00
Roy, thanks for the update & SR number. Please keep us updated if you don't mind. This has the makings of some good knowledge transfer.
Since the SR is opened under Timefinder, Stefano's right - we should move this to the Mainframe forum (before he BOOTS us outta here! )
Moving this thread to Host S/W Mainframe Forum.
Dave Yates
Host S/W & Mainframe Moderator
xe2sdc
2 Intern
•
2.8K Posts
0
April 10th, 2008 12:00
ThX Dave.
@Roy, you are in good hands .. however keep us updated