Author: Bill O'Boyle
Subject: Reply to: How LOAD PROGRAM and LOAD on HOLD is said as affinity?
Posted: Tue May 03, 2016 8:45 pm (GMT 5.5)
LOAD with HOLD is a definite no-no, especially in a DTR environment.
If it's left on HOLD and the next task issues a LOAD with HOLD and then the next task and so on and so on, you run the risk of going SOS in this region, a serious problem. LOAD with HOLD must be explicitly released with a RELEASE PROGRAM API as it's not released at task termination.
Once it's on HOLD, are you writing to it? If not, then I don't understand the purpose of loading it into storage.
What about RES=YES in the PPT (different than LOAD HOLD) and (if you're writing to it) use the ENQ/DEQ API's, which ensures serialization.
But, the resource name used in the ENQ/DEQ API's needs to be the same for all programs updating this table (resource) as you'll have multiple TCB's in a Threadsafe environment.
HTH....
_________________
Nothing in fine print is ever good news.![icon_wink.gif]()
!!!!!!!
ò ¿ ó
(~~)
Mr. Bill
Subject: Reply to: How LOAD PROGRAM and LOAD on HOLD is said as affinity?
Posted: Tue May 03, 2016 8:45 pm (GMT 5.5)
LOAD with HOLD is a definite no-no, especially in a DTR environment.
If it's left on HOLD and the next task issues a LOAD with HOLD and then the next task and so on and so on, you run the risk of going SOS in this region, a serious problem. LOAD with HOLD must be explicitly released with a RELEASE PROGRAM API as it's not released at task termination.
Once it's on HOLD, are you writing to it? If not, then I don't understand the purpose of loading it into storage.
What about RES=YES in the PPT (different than LOAD HOLD) and (if you're writing to it) use the ENQ/DEQ API's, which ensures serialization.
But, the resource name used in the ENQ/DEQ API's needs to be the same for all programs updating this table (resource) as you'll have multiple TCB's in a Threadsafe environment.
HTH....
_________________
Nothing in fine print is ever good news.
!!!!!!!
ò ¿ ó
(~~)
Mr. Bill