The simple answer would be to change the command line when used from within
an exec, so that you can tell where you've come from.
The user types "Submit jobname inputfile parms..." and the command does the
work from the command line.
Within another exec, use the command "Submit foobar jobname inputfile
parms...". Then within the exec, early in the processing, do:
Parse arg where .
If where = "foobar" then do
nested = "yes"
Parse arg . Jobname inputfile parms
End else do
nested = "no"
Parse arg jobname inputfile parms
End
Then just do a mass edit on your execs to change "Submit" to "Submit
foobar". Whatever you use as the key should be something that wouldn't be
used as the first parameter by a command-line user. You could make it
something like "$##&*$"; Anything the user isn't likely to type.
This is a low-tech solution but does address the need.
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OE-5-55 200 First Street SW
/( )\ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 12/27/07 4:20 AM, "Wakser, David" <[EMAIL PROTECTED]> wrote:
> Kris:
>
> In order to clarify things, I have just finished writing a
> "suite" of EXECs to handle compilations/assemblies and job JCL being
> sent to multiple VSE machines on multiple different physical machines.
> All of the EXECs that build JCL use a "common" submission EXEC.
>
> The submission EXEC is somewhat complicated, since I need to
> "override" certain JCL items and change them, to ensure return of the
> output to the user. The scenario is somewhat convoluted: the client's VM
> runs second-level to "our" VM. The VSEs are scattered; one also runs
> under "our" first-level VM, while others are on DIFFERENT CPUs running
> DIFFERENT VMs. I am using VSE's autoFTP feature to return output to the
> original CMS user, and I am doing that by modifying JCL during the
> submission process to ensure it contains the required parameters to make
> that happen.
>
> The "submission" EXEC can be invoked from an EXEC, but it can
> also be invoked on its own. In the submission EXEC, I need to know if I
> was invoked natively (either from the CMS command line or from FLIST - I
> don't differentiate), or called from another EXEC. This is necessary in
> order to decide whether or not to display certain messages.
>
> Does that explain my need a little better? For now, I am using
> the following to accomplish this:
>
> PARSE UPPER SOURCE . . . . . RXNAME .
> 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR X1'
> if X1 /= "SEND2VSE" & substr(X1,1,5) /= "FILEL" then exit
>
> SEND2VSE is the name of the submission EXEC. That is what is returned if
> the EXEC is accessed natively. If issued from FILELIST, then FILEL is
> returned. If neither of those is returned, I assume the submission EXEC
> was called by another EXEC (for example, the compilation exec) and I
> exit at this point.
>
> David Wakser
>
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Kris Buelens
> Sent: Thursday, December 27, 2007 4:16 AM
> To: [email protected]
> Subject: Re: Checking how invoked
>
> Sorry, unsafe again, for at least two reasons:
> - when you go to CMS SUBSET, XEDIT is still in the air, but hidden, so
> will be
> the message(s) sent with (E)MSG
> - from XEDIT, you invoke another fullscreen program (e.g. ISPF),
> yielding the same
> problems as with SUBSET
>
> The fact that FILELIST is XEDIT too, doesn't pose an extra problem:
> the messages will be displayed in FILELIST's msg area, as soon as
> XEDIT gets the chance.
>
> BTW, there still is a small error in the sample code, this code should
> run with ADDRESS COMMAND (if it were ADDRESS CMS, remain silent to
> avoid injuries). So
> 'SUBCOM XEDIT'
> xedit = (rc = 0)
> If xedit Then
> address Xedit 'COMMAND EMSG' ...
> Else
> Say ...
>
> I guess we should have asked from the beginning why David needed to
> know the caller of an exec, enabling a more precise answer, or even
> other, easier alternatives.
