Difference between revisions of "Information Systems:IBM i restricted state"
m |
m |
||
| Line 1: | Line 1: | ||
| + | =System restricted state= |
||
| ⚫ | |||
| + | =Application restricted state= |
||
| + | |||
| ⚫ | |||
| + | |||
| + | ==Definition== |
||
Application Restricted State is a term coined by [[User:Sheilav|Sheila]] to describe a particular OS state/environment required to perform some ASW tasks in the overnight process. To understand the need for this term, it is important to first understand that IBM i defines its own [https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/experience_web/wmrstate53.pdf Restricted State], which can be summarized as follows (from IBM's website): |
Application Restricted State is a term coined by [[User:Sheilav|Sheila]] to describe a particular OS state/environment required to perform some ASW tasks in the overnight process. To understand the need for this term, it is important to first understand that IBM i defines its own [https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/experience_web/wmrstate53.pdf Restricted State], which can be summarized as follows (from IBM's website): |
||
Many recovery procedures require that your system have no other activity on it. When no subsystems except the controlling subsystem are active on your system, it is in a ''restricted state''. |
Many recovery procedures require that your system have no other activity on it. When no subsystems except the controlling subsystem are active on your system, it is in a ''restricted state''. |
||
| + | This means that by IBM's definition of restricted state, only QCTL (i.e. the controlling subsystem) is up, with the subsystem itself being restricted as well. Sheila refers to this as '''system restricted state''' to differentiate it from application restricted state. |
||
| − | QCTL is the controlling subsystem being referred to (or less likely, QBASE, depending on what the system value QCTLSBSD is set to). |
||
| + | |||
| + | During the overnight process, one particular stage ([[Information Systems:EODUPD|EODUPD]]) requires all subsystems to be shut down (similar to system restricted state) except one: UP1480BS. This subsystem is needed to run ASW batch jobs. Additionally, for tasks in EODUPD, this subsystem is best |
||
[[Category: uniPHARM Dictionary]] |
[[Category: uniPHARM Dictionary]] |
||
Revision as of 12:39, 8 December 2016
System restricted state
Application restricted state
Note: This page should be validated for accuracy by Sheila. It was written based on Norwin's interpretation of her definition. Also, the topic of Restricted State might need its own page.
Definition
Application Restricted State is a term coined by Sheila to describe a particular OS state/environment required to perform some ASW tasks in the overnight process. To understand the need for this term, it is important to first understand that IBM i defines its own Restricted State, which can be summarized as follows (from IBM's website):
Many recovery procedures require that your system have no other activity on it. When no subsystems except the controlling subsystem are active on your system, it is in a restricted state.
This means that by IBM's definition of restricted state, only QCTL (i.e. the controlling subsystem) is up, with the subsystem itself being restricted as well. Sheila refers to this as system restricted state to differentiate it from application restricted state.
During the overnight process, one particular stage (EODUPD) requires all subsystems to be shut down (similar to system restricted state) except one: UP1480BS. This subsystem is needed to run ASW batch jobs. Additionally, for tasks in EODUPD, this subsystem is best