Answer to question 16

These questions were not difficult after all. You probably already know that a LOGOFF/LOGON sequence is overkill compared to an IPL CMS, which in turn is overkill compared to HX or HI. You learned the advantages of the HI during the lesson.

But maybe it is good to review what happens in the different cases, and what the possible consequences are :

HI This is an immediate CMS command that instructs the REXX interpreter to stop executing the currently active procedure(s). The program stack gets cleared, REXX releases all the storage it acquired, and you return to where you were when you launched the procedure(s). Whether files opened by the procedure(s) are closed depends on several factors (e.g. there is a difference between regular CMS minidisks and SFS files) and we will discuss this in more detail in Lesson 4.
The main advantage is that the environment from which you invoked your procedure is not destroyed. For example, if you called the procedure while in XEDIT session, and you had not saved a file, then you will come back to XEDIT and don't loose the changes to your file.
It almost is as if you issued an exit statement in your procedure.

HX This kills any active process in CMS. Thus, your procedure(s) are killed, the stack is cleared. But, also your other active environments are killed (XEDIT for example, and you may lose updates to your file). Even more, CMS tries to clear all 'user' data in the private storage. This means that for example your privately EXECLOADed procedures or NUCXLOADed modules are also removed from storage if they had the USER attribute (thus not the ones with SYSTEM attribute, nor the ones in shared segments).

IPL CMS In this case it is rather obvious that you kill your complete operating system. CP clears your complete virtual storage and re-loads your CMS. You loose anything that was ongoing in your CMS session and thus also accesses to minidisks or temporary disks.
But the configuration of your virtual machine is not changed (that's CPs' business). Thus, the LINKs to minidisks, or the DEFINED temporary disks or virtual disks are not lost. You can re-access these disks once CMS is up again.

LOGOFF Do we really have to explain this ??? One thing is certain: setting up a virtual machine at LOGON means quite a lot of work for the system.
We've seen VM systems that run some tool to automatically FORCE users that seem to do nothing during a certain interval. The reasons to do so can be:

to reduce resource consumption
for security, hence to not leave unattended terminals logged on...

Allow us to say that, in our opinion, this is neither very useful nor good for the system, unless you're sure that the user has left his office for a very long period...
A user that is idle will consume almost no resources. His pages will be paged out after a while ; there will of course be neither CPU consumption nor I/O activity. Only one or a couple of pages defining the user (the VMDBK or VM definition blocks) may remain in real storage.
If security is a concern, then even that can now be solved by using the FORCE DISCONNECT command, so that the user terminal is just disconnected, but the user machine is still intact.

Use the backward navigation button to return to the lesson.

HI	This is an immediate CMS command that instructs the REXX interpreter to stop executing the currently active procedure(s). The program stack gets cleared, REXX releases all the storage it acquired, and you return to where you were when you launched the procedure(s). Whether files opened by the procedure(s) are closed depends on several factors (e.g. there is a difference between regular CMS minidisks and SFS files) and we will discuss this in more detail in Lesson 4. The main advantage is that the environment from which you invoked your procedure is not destroyed. For example, if you called the procedure while in XEDIT session, and you had not saved a file, then you will come back to XEDIT and don't loose the changes to your file. It almost is as if you issued an `exit` statement in your procedure.
HX	This kills any active process in CMS. Thus, your procedure(s) are killed, the stack is cleared. But, also your other active environments are killed (XEDIT for example, and you may lose updates to your file). Even more, CMS tries to clear all 'user' data in the private storage. This means that for example your privately `EXECLOAD`ed procedures or `NUCXLOAD`ed modules are also removed from storage if they had the USER attribute (thus not the ones with SYSTEM attribute, nor the ones in shared segments).
IPL CMS	In this case it is rather obvious that you kill your complete operating system. CP clears your complete virtual storage and re-loads your CMS. You loose anything that was ongoing in your CMS session and thus also accesses to minidisks or temporary disks. But the configuration of your virtual machine is not changed (that's CPs' business). Thus, the `LINK`s to minidisks, or the `DEFINED` temporary disks or virtual disks are not lost. You can re-access these disks once CMS is up again.
LOGOFF	Do we really have to explain this ??? One thing is certain: setting up a virtual machine at `LOGON` means quite a lot of work for the system. We've seen VM systems that run some tool to automatically `FORCE` users that seem to do nothing during a certain interval. The reasons to do so can be: to reduce resource consumption for security, hence to not leave unattended terminals logged on... Allow us to say that, in our opinion, this is neither very useful nor good for the system, unless you're sure that the user has left his office for a very long period... A user that is idle will consume almost no resources. His pages will be paged out after a while ; there will of course be neither CPU consumption nor I/O activity. Only one or a couple of pages defining the user (the VMDBK or VM definition blocks) may remain in real storage. If security is a concern, then even that can now be solved by using the `FORCE DISCONNECT` command, so that the user terminal is just disconnected, but the user machine is still intact.