Joined: 26 Apr 2004 Posts: 4650 Location: Raleigh, NC, USA
Pretty easy, actually.
First of all, all of these would require that your REXX exec run within a TSO/E address space. In addition, for ISPEXEC, you need to also have an ISPF session started. And for ISREDIT, an ISPF Edit or View Session has to be active.
Address TSO is, well, TSO. This would be the default anyway. This allows you to use TSO commands in your exec.
Address ISPEXEC is for ISPF Services. This would be used in any ISPF dialog execs you might create.
Joined: 01 Sep 2006 Posts: 2083 Location: Silicon Valley
The REXX language has powerful grouping and logic constructs, and many built-in functions. But it needs help to do I/O and other system things.
One of the strengths of REXX is that you can extend it (more or less) to invoke functions of other products. One way that you do that is by indicating which command processor will handle particular commands, through the use of the ADDRESS statement.
Depending on the work you want to perform, you will want to route some commands to TSO and others to ISPF. If you route a TSO command to ISPF or an ISPF command to TSO, you will get an error.
In addition to the ones already listed, I think there are also others, including TCPIP, IPCS, DB2, IMS operator, z/OS console, Unix services, etc... Plus you can write your own, or buy vendor products with their own host command environments.