Lindy Mayfield wrote:
There is a small technical detail I have been curious about concerning
IKJCT441.
If I use the CALL *(module) method from a Rexx (or CLIST) exec, does it
make sense to design the module to only work with an exec, or can it be
more generic and realize how it is being called and function
appropriately?
For example, if executed in a batch job or called directly from TSO it
would read from and write to a file. If called from a Rexx exec it
would set variables.
One reason might be to take an existing program and have it also
interact with an exec and set variables. Or the same with a new
program.
If this is valid, what would be a good way for the program to know how
it is being called? I've been looking at some dumps but haven't found
anything yet. Like something interesting at R0.
Thanks,
Lindy
The LE folks have supplied a callable service, CEE3INF,
in z/OS 1.8 which returns some information on the current
environment. _But_ the values are not intuitive in some
cases (in particular, "batch" may not mean what you
think). Might be worth a look at.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Check out the Trainer's Friend Store to purchase z/OS <==
==> application developer toolkits. Sample code in four <==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==> http://www.trainersfriend.com/TTFStore/index.html <==
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
