Re: Checking how invoked

[Dale R. Smith]

Of course the easiest way to tell if you have been invoked while XEDIT is
 
active, is to issue the "SUBCOM XEDIT" command, for example:
   'SUBCOM XEDIT'
   xedit = (rc = 0)
   If xedit Then 
  'COMMAND EMSG' ...
   Else
  Say ...

Unfortunately, invoking an Exec from FILELIST will indicate that XEDIT is
 
active, since FILELIST creates an XEDIT environment to display the files.


-- 
Dale R. Smith

"Nobody believes the official spokesman ... but everybody trusts an
unidentified source."
- Ron Nessen

Re: Checking how invoked

[Alan Altmark]

On Wednesday, 12/26/2007 at 05:29 EST, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> Here is the resultant value of lvl if invoking from filelist:
> 
> s CMS COMMAND FILELIST EXEC * fl CMS

Whether you use REXXVARS, DMSCALLR, or LASTCMD in NUCON, you do it with 
knowledge of what you are getting.  If you need to (reliably) know if your 
progam was invoked from the Ready; prompt or some other environment, then 
DMSCALLR is the way to go.

The REXXVARS 's' record returns PARSE SOURCE (from the selected level), so 
it has the same issues.  If the information in PARSE SOURCE is sufficient 
for your needs, then by all means use it.

DMSINXED is used if you want to know "Should I use EMSG or SAY?" (it uses 
DMSCALLR under the covers).

Alan Altmark
z/VM Development
IBM Endicott

Larry J Brown is out of the office.

[Larry J Brown]

I will be out of the office starting  12/26/2007 and will not return until
01/02/2008.

I will respond to your message when I return.


This e-mail is intended only for its addressee and may contain information
that is privileged, confidential, or otherwise protected from disclosure.  If
you have received this communication in error, please notify us immediately by
e-mailing [EMAIL PROTECTED]; then delete the original message.

Re: Checking how invoked

[Schuh, Richard]

Here is the resultant value of lvl if invoking from filelist:

s CMS COMMAND FILELIST EXEC * fl CMS  


Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 2:23 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

Oh no Richard, unsafe.  You can only see if see REXX exec is active.
What if one starts the exec from within FILELIST for example, or when
typing CMS in FILELIST top go to CMS subset, your PIPE will find the
FILELIST EXEC, and FILELIST than has nothing to do with the start of the
exec.
DMSCALLR is the official API, not easy, but checking a few levels deep
and you know for sure how you were started.

2007/12/26, Schuh, Richard <[EMAIL PROTECTED]>:
> 'PIPE rexxvars 1 | take 1 | strlit append // | var lvl'
> if lvl = // then (command line)
> Else (EXEC/XEDIT/etc.)
>
> In the else case, lvl will be the source line.
>
>
>
> Regards,
> Richard Schuh
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Wakser, David
> Sent: Wednesday, December 26, 2007 12:45 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> Kris:
>
> The problem, even with DMSCALLR, is that it returns the same 
> value whether the EXEC was entered on the command line, or from 
> another EXEC. I need to differentiate between calls from another EXEC 
> an invocation from the command line. Is there a way?
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Kris Buelens
> Sent: Wednesday, December 26, 2007 1:33 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> With PASRE SOURCE, you can only see a difference between called
> - as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
> - some other means: like CMS commandline or another exec using 'EXEC 
> myexec'
> There is the DMSCALLR CSL routine that can provide much more 
> information about who called me, but I don't know it by heart: so HELP

> ROUTINES DMSCALLR
>
> 2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> > Thanks, John. That was it.
> >
> > David Wakser
> >
> > -Original Message-
> > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]

> > On Behalf Of Romanowski, John (OFT)
> > Sent: Wednesday, December 26, 2007 1:10 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Checking how invoked
> >
> > parse source
> > help rexx parse
> >
>
>
>

Re: Checking how invoked

[Kris Buelens]

Oh no Richard, unsafe.  You can only see if see REXX exec is active.
What if one starts the exec from within FILELIST for example, or when
typing CMS in FILELIST top go to CMS subset, your PIPE will find the
FILELIST EXEC, and FILELIST than has nothing to do with the start of
the exec.
DMSCALLR is the official API, not easy, but checking a few levels deep
and you know for sure how you were started.

2007/12/26, Schuh, Richard <[EMAIL PROTECTED]>:
> 'PIPE rexxvars 1 | take 1 | strlit append // | var lvl'
> if lvl = // then (command line)
> Else (EXEC/XEDIT/etc.)
>
> In the else case, lvl will be the source line.
>
>
>
> Regards,
> Richard Schuh
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Wakser, David
> Sent: Wednesday, December 26, 2007 12:45 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> Kris:
>
> The problem, even with DMSCALLR, is that it returns the same
> value whether the EXEC was entered on the command line, or from another
> EXEC. I need to differentiate between calls from another EXEC an
> invocation from the command line. Is there a way?
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Kris Buelens
> Sent: Wednesday, December 26, 2007 1:33 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> With PASRE SOURCE, you can only see a difference between called
> - as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
> - some other means: like CMS commandline or another exec using 'EXEC
> myexec'
> There is the DMSCALLR CSL routine that can provide much more information
> about who called me, but I don't know it by heart: so HELP ROUTINES
> DMSCALLR
>
> 2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> > Thanks, John. That was it.
> >
> > David Wakser
> >
> > -Original Message-
> > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> > On Behalf Of Romanowski, John (OFT)
> > Sent: Wednesday, December 26, 2007 1:10 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Checking how invoked
> >
> > parse source
> > help rexx parse
> >
>
>
>

Re: Checking how invoked

[Wakser, David]

I'll try that.



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 4:17 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


On second thought, you might want to change that pipe slightly so as to
pickup only the first word from the command line. ie.
'PIPE STORAGE 740 8 | SPECS W1 1 | XLATE 1-* UPPER | VAR ABC'
 
 

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 3:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Thanks - that seems to work for me! It would seem that there
would be a (somewhat) more straightforward method, but if they don't
change the offset, I'm fine!
 
Thanks to all who responded.
 
David Wakser 



From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 3:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Not so bad.. here is something I use, I think it works
everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .

 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC'

 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'

 
NOTE: You want to get the command line from x'740' not 2A0 as I
may have indicated. 

 

Java and OSA GUI

[Edward M. Martin]

  

Hello Everyone,

 

 I am taking some time to learn more and understand less.

 

 OSA/SF on z/VM 5.3 indicates that there is a GUI that will use port
2000.

 

 I am finding that I have JAVA 1.4.1_01 and 1.5.0_11 but I do not
have the JavaHelp files.

 JH.JAR.

 

 Does IBM have a recommended spot to download the proper JAVA files?

 

Ed Martin

330-588-4723

ext 40441

 

Re: Checking how invoked

[Huegel, Thomas]

On second thought, you might want to change that pipe slightly so as to
pickup only the first word from the command line. ie.
'PIPE STORAGE 740 8 | SPECS W1 1 | XLATE 1-* UPPER | VAR ABC'
 
 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 3:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Thanks - that seems to work for me! It would seem that there would be a
(somewhat) more straightforward method, but if they don't change the offset,
I'm fine!
 
Thanks to all who responded.
 
David Wakser 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 3:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Not so bad.. here is something I use, I think it works everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .
 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC' 
 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'   
 
NOTE: You want to get the command line from x'740' not 2A0 as I may have
indicated. 

 

Re: Checking how invoked

[Schuh, Richard]

'PIPE rexxvars 1 | take 1 | strlit append // | var lvl'
if lvl = // then (command line)
Else (EXEC/XEDIT/etc.)

In the else case, lvl will be the source line. 



Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:45 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

Kris:

The problem, even with DMSCALLR, is that it returns the same
value whether the EXEC was entered on the command line, or from another
EXEC. I need to differentiate between calls from another EXEC an
invocation from the command line. Is there a way?

David Wakser 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more information
about who called me, but I don't know it by heart: so HELP ROUTINES
DMSCALLR

2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> Thanks, John. That was it.
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, December 26, 2007 1:10 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> parse source
> help rexx parse
>



--
Kris Buelens,
IBM Belgium, VM customer support

Re: Checking how invoked

[Wakser, David]

I agree - but are you suggesting another method
 
David Wakser



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 26, 2007 3:58 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Ah, but it is better to use a defined and documented programming
interface than it is to screen scrape.
 

Regards, 
Richard Schuh 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 12:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Not so bad.. here is something I use, I think it works everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .
 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC' 
 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'   
 
NOTE: You want to get the command line from x'740' not 2A0 as I may have
indicated. 

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked



Ugh! I would hate to do it that way from a very simple EXEC!

 

David Wakser

 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 1:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

 

In the CMS NUCLEUS at offset 2A0 you can find the name of the
last command (typed at the console) issued, and at 2B0 is the name of
the last EXEC procedure... 

If that helps any. 

Re: Checking how invoked

[Wakser, David]

Thanks - that seems to work for me! It would seem that there would be a
(somewhat) more straightforward method, but if they don't change the
offset, I'm fine!
 
Thanks to all who responded.
 
David Wakser 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 3:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Not so bad.. here is something I use, I think it works everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .
 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC' 
 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'   
 
NOTE: You want to get the command line from x'740' not 2A0 as I may have
indicated. 

 

Re: Checking how invoked

[Harding, Mike]

Not pretty, nor documented per se, and offsets could change, but -
   depth=c2d(Storage(d2x(c2d(storage(674,4))+28),4)) 
Is the depth of the svc stack.  It will be 2 if the encompassing exec is
called from the command line, higher otherwise. 


Mike Harding
EDS VM National Capability
134 El Portal Place
Clayton, Ca.  USA  94517-1742

* phone: +01-925-672-4403
*  Fax: +01-925-672-4403
* mailto:[EMAIL PROTECTED]   * 
(personal)
Note:  For 2007, I am off on Fridays with even Julian dates and Mondays
with odd ones.


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:45 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

Kris:

The problem, even with DMSCALLR, is that it returns the same
value whether the EXEC was entered on the command line, or from another
EXEC. I need to differentiate between calls from another EXEC an
invocation from the command line. Is there a way?

David Wakser 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more information
about who called me, but I don't know it by heart: so HELP ROUTINES
DMSCALLR

2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> Thanks, John. That was it.
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, December 26, 2007 1:10 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> parse source
> help rexx parse
>



--
Kris Buelens,
IBM Belgium, VM customer support

Re: Checking how invoked

[Schuh, Richard]

Ah, but it is better to use a defined and documented programming
interface than it is to screen scrape.
 

Regards, 
Richard Schuh 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 12:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Not so bad.. here is something I use, I think it works everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .
 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC' 
 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'   
 
NOTE: You want to get the command line from x'740' not 2A0 as I may have
indicated. 

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked



Ugh! I would hate to do it that way from a very simple EXEC!

 

David Wakser

 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 1:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

 

In the CMS NUCLEUS at offset 2A0 you can find the name of the
last command (typed at the console) issued, and at 2B0 is the name of
the last EXEC procedure... 

If that helps any. 

Re: Checking how invoked

[Huegel, Thomas]

Not so bad.. here is something I use, I think it works everytime..
 PARSE UPPER SOURCE . . . . . RXNAME .
 'PIPE STORAGE 740 8 | XLATE 1-* UPPER | VAR ABC' 
 IF ABC = STRIP(RXNAME) THEN SAY ' ENTERED ON COMMAND LINE'   
 
NOTE: You want to get the command line from x'740' not 2A0 as I may have
indicated. 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked



Ugh! I would hate to do it that way from a very simple EXEC!

 

David Wakser

 

 


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 1:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

 

In the CMS NUCLEUS at offset 2A0 you can find the name of the last command
(typed at the console) issued, and at 2B0 is the name of the last EXEC
procedure... 

If that helps any. 

Re: Checking how invoked

[Wakser, David]

Kris:

The problem, even with DMSCALLR, is that it returns the same
value whether the EXEC was entered on the command line, or from another
EXEC. I need to differentiate between calls from another EXEC an
invocation from the command line. Is there a way?

David Wakser 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more information
about who called me, but I don't know it by heart: so HELP ROUTINES
DMSCALLR

2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> Thanks, John. That was it.
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, December 26, 2007 1:10 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> parse source
> help rexx parse
>



--
Kris Buelens,
IBM Belgium, VM customer support

Re: Checking how invoked

[Schuh, Richard]

It appears that the HELP to DMSCALLR is slightly outdated. It has this
usage note:

 

 2.   To determine if your program was called from within XEDIT, you
must 
  look at each command name until you find one that is not EXEC or
CMS.   
  If the command name is XEDIT, then the program was called from an
exec  
  or XEDIT macro. 

There is another CSL call, DMSINXED, that seems to me to be simpler than
the suggested loop. R does it do something entirely different?



Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 10:33 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more information
about who called me, but I don't know it by heart: so HELP ROUTINES
DMSCALLR

2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> Thanks, John. That was it.
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, December 26, 2007 1:10 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> parse source
> help rexx parse
>



--
Kris Buelens,
IBM Belgium, VM customer support

Re: Checking how invoked

[Wakser, David]

Ugh! I would hate to do it that way from a very simple EXEC!

 

David Wakser

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 26, 2007 1:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

 

In the CMS NUCLEUS at offset 2A0 you can find the name of the last
command (typed at the console) issued, and at 2B0 is the name of the
last EXEC procedure... 

If that helps any. 

Re: Checking how invoked

[Huegel, Thomas]

In the CMS NUCLEUS at offset 2A0 you can find the name of the last command
(typed at the console) issued, and at 2B0 is the name of the last EXEC
procedure... 
If that helps any.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked


Kris:

Yes, I just finished testing PARSE SOURCE - there is no
difference between invocation from the command line to invocation from
another EXEC. I'll try DMSCALLR.

David Wakser

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more
information about who called me, but I don't know it by heart: so HELP
ROUTINES DMSCALLR

Re: Checking how invoked

[Wakser, David]

Kris:

Yes, I just finished testing PARSE SOURCE - there is no
difference between invocation from the command line to invocation from
another EXEC. I'll try DMSCALLR.

David Wakser

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 26, 2007 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC
myexec'
There is the DMSCALLR CSL routine that can provide much more
information about who called me, but I don't know it by heart: so HELP
ROUTINES DMSCALLR

Re: Checking how invoked

[Kris Buelens]

With PASRE SOURCE, you can only see a difference between called
- as REXX subroutine or REXX function: CALL myexec  or xyz=myexec()
- some other means: like CMS commandline or another exec using 'EXEC myexec'
There is the DMSCALLR CSL routine that can provide much more
information about who called me, but I don't know it by heart: so HELP
ROUTINES DMSCALLR

2007/12/26, Wakser, David <[EMAIL PROTECTED]>:
> Thanks, John. That was it.
>
> David Wakser
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, December 26, 2007 1:10 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Checking how invoked
>
> parse source
> help rexx parse
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: FTP Append

[Schuh, Richard]

The results are coming in and they seem unanimous. Whenever I detect a
file for the center in question having zero records (many occurrences)
it is invariably corrupted. There have been only two occurrences of zero
record files from one of the other centers. Those two files were not
corrupted. There must be something happening because of timing or some
other factor.
 
I tried TRACERTE to the MVS systems at each of the centers. In each
case, there were 8 hops. The difference is in time. The center where
there is no failure had almost instantaneous response while there are
noticeable delays when checking the path to the problem center. 
 
This leaves me with two questions:
 
1. Why am I seeing any instances of zero record files, especially when
there had been thousands of records in some of them in earlier checks? 
2. Why is this OK for one set of files, but not another?
 
Actually, there is a third question: Which component(s) do I open the
PMR(s) against? 
 

Regards, 
Richard Schuh 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Walter
Sent: Thursday, December 06, 2007 11:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: FTP Append



Good diagnostic technique! 

It's unclear to me if the monitoring is done from z/VM, or on the PCs in
the centers   

If it's done a z/VM, then you're only looking at one side of the
equation.  Can you develop a monitor that runs on the PCs to see what
*they* see every minute?   

Extra credit will be given if that monitor is also run on the PC
immediately before and after each FTP event so that what arrives on z/VM
can be compared with what was on the PC _just before_, and _just after_
every FTP event. 

My apologies if the thoughts in this have already been tried.  In an
apparent attempt to maintain some privacy around what's being done,
sometimes the posts have sometimes been difficult to interpret. 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates. 



"Schuh, Richard" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System"  

12/06/2007 01:38 PM 
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU 
cc
Subject
Re: FTP Append






I  created a routine that checks the number of records in the files from
the center in question once per minute and reports any that change to or
from zero records. It has given surprising results. One time when there
was a corruption, it reported 0 records immediately before and + records
after. On other occasions, it has recorded similar changes without there
being any corruption. Conversely, there have been 2 cases of corruption
with no indications that the corrupted file was ever empty. I have since
changed the routine to monitor the files from all centers in an effort
to see if these state changes are normal. If I see them from the other
centers, I will have to conclude that they, while strange, are normal. 

Back in 2004, I posted an item about files disappearing from SFS when
FTP was appending to them
(http://listserv.uark.edu/scripts/wa.exe?A2=ind0405&L=IBMVM&P=R29292&D=0
&H=0&I=-3&O=T&T=0&m=49139
 ). There was only one response and the
problem went away without ever having been correctly diagnosed and
fixed. This problem seems to be very much the same as the 2004 post
because we did note that the files that disappeared were first reported
as being empty. This time, the problem, if it is related, is more
persistent than before, happening once every few days instead of once
every 3.5 years:-( 

The question is, what is causing this, something in SFS or is it being
done by TCPIP? How can I make the determination? 

Regards,
Richard Schuh 

Original post in the current thread. 

Date: Wed, 28 Nov 2007 14:12:04 -0800 

Reply-To: The IBM z/VM Operating System <[log in to unmask]
 > 

Sender:   The IBM z/VM Operating System <[log in to unmask]
 > 

From: "Schuh, Richard" <[log in to unmask]
 > 

Subject:  FTP Append 

Content-Type: multipart/alternative; 

We have been using FTP to append to daily files from our centers around
the world for eight years now. The way that we have been doing it is
that data is accumulated by a PC at each center. When a threshold is
reached, the PC initiates an FTP session with our VM system and appends
the data to a file whose name and type reflect the location of the
originating system, the typ

Re: Checking how invoked

[Wakser, David]

Thanks, John. That was it.

David Wakser

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Romanowski, John (OFT)
Sent: Wednesday, December 26, 2007 1:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Checking how invoked

parse source
help rexx parse

Re: Checking how invoked

[Fran Hensler]

Parse Source
 
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years
 [EMAIL PROTECTED] +1.724.738.2153
"Yes, Virginia, there is a Slippery Rock"
 
On Wed, 26 Dec 2007 10:58:25 -0700 Wakser, David said:
>All:
>
>   I cannot recall: how does one check, in a Rexx EXEC, whether the
>EXEC was invoked from the CMS command line or from another EXEC?
>
>   Thanks, in advance.
>
>David Wakser

Re: Checking how invoked

[Romanowski, John (OFT)]

parse source
help rexx parse



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments.  Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


-Original Message-

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Wakser, David
Sent: Wednesday, December 26, 2007 12:58 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Checking how invoked

All:

I cannot recall: how does one check, in a Rexx EXEC, whether the
EXEC was invoked from the CMS command line or from another EXEC?

Thanks, in advance.

David Wakser

Checking how invoked

[Wakser, David]

All:

I cannot recall: how does one check, in a Rexx EXEC, whether the
EXEC was invoked from the CMS command line or from another EXEC?

Thanks, in advance.

David Wakser

Re: Offline Devices

[Schuh, Richard]

Mary Ann,
 
Thanks for the tip. In the frenzy of activity, I never thought to look
at SYSTEM CONFIG parameters. It looks like not_accepted really is the
way to go.
 

Regards, 
Richard Schuh 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mary Anne Matyaz
Sent: Tuesday, December 25, 2007 6:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Offline Devices


Richard, 
You can make them not accepted and then use the set devices accepted
command to bring them online without an ipl, as long as you have enabled
the set devices accepted command in system config. 
MA


On Dec 24, 2007 2:53 PM, Schuh, Richard <[EMAIL PROTECTED]> wrote:


NotAccepted will not work for me as I must access individual
devices
every now and then. NotAccepted would require an IPL to make the
device
available. IPL is a four-letter word around here, especially
during the
holiday season.


Regards,
Richard Schuh



-Original Message-
From: The IBM z/VM Operating System [mailto:
IBMVM@LISTSERV.UARK.EDU  ] On
Behalf Of Mark Wheeler
Sent: Monday, December 24, 2007 11:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Offline Devices

Richard, 

I had a similar requirement and defined the device ranges that I
wanted
to "block" as "NotAccepted" in my SYSTEM CONFIG's "Device"
statement.

Best regards,

Mark L. Wheeler 
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel:  (651) 733-4355, Fax:  (651) 736-7689 mlwheeler at mmm.com

"I have this theory that if one person can go out of their way
to show 
compassion then it will start a chain reaction of the same.
People will
never know how far a little kindness can go." Rachel Joy Scott





"Schuh, Richard"

< [EMAIL PROTECTED]>

Sent by: The IBM
To
z/VM OperatingIBMVM@LISTSERV.UARK.EDU

System 
cc
<[EMAIL PROTECTED]

ARK.EDU>
Subject
  Offline Devices 



12/24/2007 12:26

PM





Please respond to

  The IBM z/VM

Operating System

< [EMAIL PROTECTED]  

ARK.EDU>









Recently, we have had some problems with a ficon card. The path
was
varied off from all devices and the chpid varied offline. The
chpid was 
then taken offline at the HSM and the part replaced. When the
chpid was
brought back online at the HSM, the ensuing device
reconfiguration
interrupt apparently caused all 4096 devices to be brought
online.
Unfortunately, only 365 of the devices were online when the
hardware 
activity started. The remaining devices are in the
Devices_offline list
in the SYSTEM CONFIG file and are not supposed to be online to
VM. In
this particular case, only the one path out of four was affected
by the 
hardware problem.



I cannot put the devices in an ignore list because it is
sometimes
necessary to make one of them available to VM. From the
description, it
does not appear that making them not_sensed would help. In fact,
it 
would probably make the occasional need to make a device
available more
complicated. Is there any way to have the devices stay offline
in a
situation like this?





Regards,
Richard Schuh

Re: Offline Devices

[Schuh, Richard]

Yes, there was a change in the state of the channel, it failed while the
system was running. This caused a bit of havoc as the OPERATOR console
and any other that issued any silly command like VARY PATH or VARY CHPID
to hang. They were only freed by someone taking the CHPID off at the
HMC. The second change of state occurred when IBM replaced a ficon card
and returned the hardware. I presume that the proper return path was
followed. I cannot be sure since the data center is over 1000 miles
away. In any event, all 4K devices were sensed and made ONLINE to the
system. 
 
The changing of state like that is not an every day occurrence. However,
if the z9-z/VM system is to be a near-non-stop system, then it must
withstand the possibilities of what may happen during normal operation.
That includes the failure and replacement of a redundant part. In this
case, there are four paths to the devices, so the failure and
replacement of one of them falls into that category. And the component
it was successfully replaced. It is just that the devices that were
supposed to be offline were not following the repair.
 
I would also suppose that making the path available via the HMC would
cause a Configuration Change machine check that notifies CP that the
change has occurred, and further, CP handles the interrupt in a
reasonable manner.
 
Regards, 
Richard Schuh 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Neubert, Kevin (DIS)
Sent: Monday, December 24, 2007 12:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Offline Devices



Do you mean HMC?  If so it appears to me this was caused by changing the
state of the channel path via the HMC/SE while the OS was running-not
recommended as the OS will not be notified.

 

Regards,

 

Kevin

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Monday, December 24, 2007 10:27 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Offline Devices

 

Recently, we have had some problems with a ficon card. The path was
varied off from all devices and the chpid varied offline. The chpid was
then taken offline at the HSM and the part replaced. When the chpid was
brought back online at the HSM, the ensuing device reconfiguration
interrupt apparently caused all 4096 devices to be brought online.
Unfortunately, only 365 of the devices were online when the hardware
activity started. The remaining devices are in the Devices_offline list
in the SYSTEM CONFIG file and are not supposed to be online to VM. In
this particular case, only the one path out of four was affected by the
hardware problem. 


I cannot put the devices in an ignore list because it is sometimes
necessary to make one of them available to VM. From the description, it
does not appear that making them not_sensed would help. In fact, it
would probably make the occasional need to make a device available more
complicated. Is there any way to have the devices stay offline in a
situation like this? 

 

Regards,
Richard Schuh 

 

Re: Offline Devices

[Schuh, Richard]

I used something similar when I saw what had transpired. 


Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Wheeler
Sent: Monday, December 24, 2007 1:11 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Offline Devices

Richard,

Here's what I used to use, from a svm that ran this (and other things)
every 15 minutes. The range of "normal" DASD device addresses are
specified, and it proceeds to vary all others offline.

/* DASDOFF EXEC

   Vary all DASD that VM is not using offline to avoid conflicts with
   z/OS activities.

*/

VM_DASD_addrs = '1000-10FF 1100-11FF 1910-1917'

'PIPE(name DASDOFF endchar ?)|',
   'CP Q DASD ALL |',
   'SPLIT , |',
   'STRIP |',
   'PICK W3 /== /OFFLINE/ |',
   'PICK W3 /== /SUBCHOFF/ |',
'L: NOT LOOKUP 6.4 6.4 |',
   'CONS |',
   'SPECS /VARY OFF/ 1 6.4 NW |',
   'CP |',
   'CONS',
'?',
   'CP Q' VM_DASD_addrs '|',
   'SPLIT , |',
   'STRIP |',
'L:'

Best regards,
  Mark



 

 "Schuh, Richard"

 <[EMAIL PROTECTED]>

 Sent by: The IBM
To 
 z/VM OperatingIBMVM@LISTSERV.UARK.EDU

 System
cc 
 <[EMAIL PROTECTED]

 ARK.EDU>
Subject 
   Offline Devices

 

 12/24/2007 12:26

 PM

 

 

 Please respond to

   The IBM z/VM

 Operating System

 <[EMAIL PROTECTED]

 ARK.EDU>

 

 





Recently, we have had some problems with a ficon card. The path was
varied off from all devices and the chpid varied offline. The chpid was
then taken offline at the HSM and the part replaced. When the chpid was
brought back online at the HSM, the ensuing device reconfiguration
interrupt apparently caused all 4096 devices to be brought online.
Unfortunately, only 365 of the devices were online when the hardware
activity started. The remaining devices are in the Devices_offline list
in the SYSTEM CONFIG file and are not supposed to be online to VM. In
this particular case, only the one path out of four was affected by the
hardware problem.



I cannot put the devices in an ignore list because it is sometimes
necessary to make one of them available to VM. From the description, it
does not appear that making them not_sensed would help. In fact, it
would probably make the occasional need to make a device available more
complicated. Is there any way to have the devices stay offline in a
situation like this?





Regards,
Richard Schuh

Re: SLAC VM Batch System availability ?

[Thomas Kern]

Two of the mods were new Diagnose functions, one of which was to get and/
or
set the account number. Neither might be needed in a current z/VM system,

but both might be good to have in a VM/370 R6 system.

/Tom Kern

Re: SLAC VM Batch System availability ?

[David Boyes]

I faintly remember the CP mods for the LARS system were primarily to
increase the size of some of the spooled file size fields in some
control blocks in VM/SP and XA. I suspect that you might not need them
on a modern system, or that it would now be possible to modify the LARS
code to not need them. 

Re: SLAC VM Batch System availability ?

[Shedlock, George]

Tom,

If all else fails, you might try
http://www.slac.stanford.edu/comp/vm/backarch-ann.html .


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Wednesday, December 26, 2007 8:46 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

If you do find a Sysprog or User's guide, I would like to get a copy. 
The last time I implemented the LARS/Purdue system, I had to plow
through all of the source code to see how it was working. It has been a
long time since then so I don't think I will remember any of the details
of the inner workings.

/Tom Kern

Shedlock, George wrote:
> As I recall, the Lars system was comprised of 10-12 separate files on 
> tape. One (maybe more) of the files was a complete systems programming

> and user guide. These were in a printed manual format (script?). Brain

> cells are fuzzy this morning.
>  
> 
> 
> George Shedlock Jr
> AEGON Information Technology
> AEGON USA
> 502-560-3541
> 
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Thomas Kern
> Sent: Wednesday, December 26, 2007 7:48 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SLAC VM Batch System availability ?
> 
> Not of the LARS/Purdue system. The copy Dave Jones supplied looks 
> complete. I don't remember there ever being any documentation except 
> for the source and the one end-user help file.
> 
> /Tom Kern
> 
> Shedlock, George wrote:
>> Tom,
>> The one I have is probably the LARS/Purdue system. If Dave Jones 
>> already supplied a copy of it, do you still need another copy?
>>
>>
>> George Shedlock Jr
>> AEGON Information Technology
>> AEGON USA
>> 502-560-3541
>>
>> -Original Message-
>> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
>> On Behalf Of Thomas Kern
>> Sent: Wednesday, December 26, 2007 7:41 AM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: Re: SLAC VM Batch System availability ?
>>
>> There are two (I think different) Batch Systems that were available 
>> at
> 
>> different times. One is the LARS/Purdue Batch system. Dave Jones has 
>> already supplied that. The other was from SLAC and was meant for the 
>> High Energy Physics crowd. Both required mods to CP, and SLAC may 
>> have
> 
>> had mods to CMS as well. I am interested in BOTH.
>>
>> /Tom Kern
>>
>> Shedlock, George wrote:
>>> Tom,
>>>
>>> Are you referring to the old CMS Batch system that appeared on one 
>>> of
> 
>>> the old VM Workshop tapes? From what I remember, it required several

>>> mods to both CP and CMS modules in order to function properly. I 
>>> believe I have a copy hanging around . Somewhere. I'll look at
>> home.
>>> George Shedlock Jr
>>> AEGON Information Technology
>>> AEGON USA
>>> 502-560-3541
>>>
>>> -Original Message-
>>> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]

>>> On Behalf Of Thomas Kern
>>> Sent: Tuesday, December 25, 2007 12:38 PM
>>> To: IBMVM@LISTSERV.UARK.EDU
>>> Subject: SLAC VM Batch System availability ?
>>>
>>> Does anyone know if the old SLAC VM Batch System is still available 
>>> from somewhere? Anyone have a copy collecting dust?
>>>
>>> /Tom Kern
>>>
> 

Re: SLAC VM Batch System availability ?

[Thomas Kern]

If you do find a Sysprog or User's guide, I would like to get a copy. 
The last time I implemented the LARS/Purdue system, I had to plow 
through all of the source code to see how it was working. It has been a 
long time since then so I don't think I will remember any of the details 
of the inner workings.


/Tom Kern

Shedlock, George wrote:

As I recall, the Lars system was comprised of 10-12 separate files on
tape. One (maybe more) of the files was a complete systems programming
and user guide. These were in a printed manual format (script?). Brain
cells are fuzzy this morning.
 



George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Wednesday, December 26, 2007 7:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

Not of the LARS/Purdue system. The copy Dave Jones supplied looks
complete. I don't remember there ever being any documentation except for
the source and the one end-user help file.

/Tom Kern

Shedlock, George wrote:

Tom,
The one I have is probably the LARS/Purdue system. If Dave Jones 
already supplied a copy of it, do you still need another copy?



George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
On Behalf Of Thomas Kern

Sent: Wednesday, December 26, 2007 7:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

There are two (I think different) Batch Systems that were available at


different times. One is the LARS/Purdue Batch system. Dave Jones has 
already supplied that. The other was from SLAC and was meant for the 
High Energy Physics crowd. Both required mods to CP, and SLAC may have



had mods to CMS as well. I am interested in BOTH.

/Tom Kern

Shedlock, George wrote:

Tom,

Are you referring to the old CMS Batch system that appeared on one of


the old VM Workshop tapes? From what I remember, it required several 
mods to both CP and CMS modules in order to function properly. I 
believe I have a copy hanging around . Somewhere. I'll look at

home.

George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
On Behalf Of Thomas Kern

Sent: Tuesday, December 25, 2007 12:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SLAC VM Batch System availability ?

Does anyone know if the old SLAC VM Batch System is still available 
from somewhere? Anyone have a copy collecting dust?


/Tom Kern

Re: SLAC VM Batch System availability ?

[Shedlock, George]

As I recall, the Lars system was comprised of 10-12 separate files on
tape. One (maybe more) of the files was a complete systems programming
and user guide. These were in a printed manual format (script?). Brain
cells are fuzzy this morning.
 


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Wednesday, December 26, 2007 7:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

Not of the LARS/Purdue system. The copy Dave Jones supplied looks
complete. I don't remember there ever being any documentation except for
the source and the one end-user help file.

/Tom Kern

Shedlock, George wrote:
> Tom,
> The one I have is probably the LARS/Purdue system. If Dave Jones 
> already supplied a copy of it, do you still need another copy?
> 
> 
> George Shedlock Jr
> AEGON Information Technology
> AEGON USA
> 502-560-3541
> 
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Thomas Kern
> Sent: Wednesday, December 26, 2007 7:41 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SLAC VM Batch System availability ?
> 
> There are two (I think different) Batch Systems that were available at

> different times. One is the LARS/Purdue Batch system. Dave Jones has 
> already supplied that. The other was from SLAC and was meant for the 
> High Energy Physics crowd. Both required mods to CP, and SLAC may have

> had mods to CMS as well. I am interested in BOTH.
> 
> /Tom Kern
> 
> Shedlock, George wrote:
>> Tom,
>>
>> Are you referring to the old CMS Batch system that appeared on one of

>> the old VM Workshop tapes? From what I remember, it required several 
>> mods to both CP and CMS modules in order to function properly. I 
>> believe I have a copy hanging around . Somewhere. I'll look at
> home.
>>
>> George Shedlock Jr
>> AEGON Information Technology
>> AEGON USA
>> 502-560-3541
>>
>> -Original Message-
>> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
>> On Behalf Of Thomas Kern
>> Sent: Tuesday, December 25, 2007 12:38 PM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: SLAC VM Batch System availability ?
>>
>> Does anyone know if the old SLAC VM Batch System is still available 
>> from somewhere? Anyone have a copy collecting dust?
>>
>> /Tom Kern
>>
> 

Re: SLAC VM Batch System availability ?

[Thomas Kern]

Not of the LARS/Purdue system. The copy Dave Jones supplied looks 
complete. I don't remember there ever being any documentation except for 
the source and the one end-user help file.


/Tom Kern

Shedlock, George wrote:
Tom, 
The one I have is probably the LARS/Purdue system. If Dave Jones already

supplied a copy of it, do you still need another copy?


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Wednesday, December 26, 2007 7:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

There are two (I think different) Batch Systems that were available at
different times. One is the LARS/Purdue Batch system. Dave Jones has
already supplied that. The other was from SLAC and was meant for the
High Energy Physics crowd. Both required mods to CP, and SLAC may have
had mods to CMS as well. I am interested in BOTH.

/Tom Kern

Shedlock, George wrote:

Tom,

Are you referring to the old CMS Batch system that appeared on one of 
the old VM Workshop tapes? From what I remember, it required several 
mods to both CP and CMS modules in order to function properly. I 
believe I have a copy hanging around . Somewhere. I'll look at

home.


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
On Behalf Of Thomas Kern

Sent: Tuesday, December 25, 2007 12:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SLAC VM Batch System availability ?

Does anyone know if the old SLAC VM Batch System is still available 
from somewhere? Anyone have a copy collecting dust?


/Tom Kern

Re: SLAC VM Batch System availability ?

[Shedlock, George]

Tom, 
The one I have is probably the LARS/Purdue system. If Dave Jones already
supplied a copy of it, do you still need another copy?


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Wednesday, December 26, 2007 7:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SLAC VM Batch System availability ?

There are two (I think different) Batch Systems that were available at
different times. One is the LARS/Purdue Batch system. Dave Jones has
already supplied that. The other was from SLAC and was meant for the
High Energy Physics crowd. Both required mods to CP, and SLAC may have
had mods to CMS as well. I am interested in BOTH.

/Tom Kern

Shedlock, George wrote:
> Tom,
> 
> Are you referring to the old CMS Batch system that appeared on one of 
> the old VM Workshop tapes? From what I remember, it required several 
> mods to both CP and CMS modules in order to function properly. I 
> believe I have a copy hanging around . Somewhere. I'll look at
home.
> 
> 
> George Shedlock Jr
> AEGON Information Technology
> AEGON USA
> 502-560-3541
> 
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Thomas Kern
> Sent: Tuesday, December 25, 2007 12:38 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: SLAC VM Batch System availability ?
> 
> Does anyone know if the old SLAC VM Batch System is still available 
> from somewhere? Anyone have a copy collecting dust?
> 
> /Tom Kern
> 

Re: SLAC VM Batch System availability ?

[Thomas Kern]

There are two (I think different) Batch Systems that were available at 
different times. One is the LARS/Purdue Batch system. Dave Jones has 
already supplied that. The other was from SLAC and was meant for the 
High Energy Physics crowd. Both required mods to CP, and SLAC may have 
had mods to CMS as well. I am interested in BOTH.


/Tom Kern

Shedlock, George wrote:

Tom,

Are you referring to the old CMS Batch system that appeared on one of
the old VM Workshop tapes? From what I remember, it required several
mods to both CP and CMS modules in order to function properly. I believe
I have a copy hanging around . Somewhere. I'll look at home. 



George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Tuesday, December 25, 2007 12:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SLAC VM Batch System availability ?

Does anyone know if the old SLAC VM Batch System is still available from
somewhere? Anyone have a copy collecting dust?

/Tom Kern

Re: SLAC VM Batch System availability ?

[Shedlock, George]

Tom,

Are you referring to the old CMS Batch system that appeared on one of
the old VM Workshop tapes? From what I remember, it required several
mods to both CP and CMS modules in order to function properly. I believe
I have a copy hanging around . Somewhere. I'll look at home. 


George Shedlock Jr
AEGON Information Technology
AEGON USA
502-560-3541

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Tuesday, December 25, 2007 12:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SLAC VM Batch System availability ?

Does anyone know if the old SLAC VM Batch System is still available from
somewhere? Anyone have a copy collecting dust?

/Tom Kern