Sounds like one (or more ) of the LPARs/tasks has a very low relative weight and is not getting services. This is similar in concept (although not structure) to the purpose of the ERV value in IEAOPTxx.
i.e. "prefer" this work for a short period of time because it might be holding resources needed by someone else and not be able to get control to release those resources. If the above is the case, *MY* preferred solution would be to adjust the weight/priority of the problem LPAR/TASK. YMMV. I don't see any issue w/the GRS conversion, except for remembering to undo it if you go to a shared MAS. <snip> We run three z/OS 1.13 images in a "bronzeplex" configuration, but do not share the spool; each image is a "single-member MAS". We're also "having fun" with an ISV product on the "sandbox", that started out as simply a S0C4 at shutdown time of the product's STC, but only "frequently". At other times shutdown was "clean and normal", and now, fairly consistently, shutdown of this STC somehow causes the sandbox to go into a disabled spin while (apparently) "somebody" on the sandbox holds the JES checkpoint lock. "Naturally", the other two images quickly bog down and start "complaining" on the consoles about the JES checkpoint lock being held. GRS also says "ISG378I GRS QSCAN ERROR COMMUNICATING WITH SYSTEM xxxx, DIAG=00000001", where "xxxx" is the SMFID of the sandbox and DIAG= "is for diagnostic data for IBM." Since we don't (yet) share spool access and each z/OS image has its own JES checkpoint dataset, would it be safe to "convert" the GRS enqueue from SYSTEMS (plural) to SYSTEM (singular)? Would it be wise to do so? </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
