- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hi All:
I have a little problem and I'm hoping someone will be able to figure out the ins and outs of it.
I run a job on a z/OS mainframe via a Spawner and SAS/Connect. The batch job runs for a long time and the
Connect session times out before the job has completed. I have requested that the timeout interval be increased
but that is not likely. I have also tuned the job to the max so it runs as quickly as I can make it.
From what I can see, the job completes the DATA step that it is in - which is to read a very large VSAM dataset
and select a number of records, and stores this in a catalogued SAS dataset on the mainframe. It look like this
is where the job dies because a subsequent DATA step does not get run. I would like to know if there is a way
to get the subsequent step to run (ie: get the job to run to the end) before it dies?
Basically, I would like to be able to submit the job via remote submit through the Spawner and then go about
my business and wait for the job to complete, even if the connection times out. Then I can sign on to the mainframe
and download the file knowing it was created successfully.
Any help would be much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
OS2,
I don't recall all the requirements however 14 years ago and prior, I would store the code on the mainframe and remote submit the mainframe code through a mainframe session. Then, if the PC connection to the Mainframe was lost, the Mainframe job was still running. The last time I ran similar code, I had the code stored on the PC, uploaded the code to a mainframe library, then used the remote mainframe session to submit the uploaded code. The PC SAS administrators were happy because I would log out of my PC SAS session when I left for home. The mainframe SAS job ran all night because there were no governors in place on how long a mainframe SAS session could be up and running.
Back then it was possible to use the PC SAS session to open a mainframe SAS session so that I had a PC Session and a Mainframe session running simutaneously.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
That is very like what I am doing - the actual SAS code lives on the mainframe and I just run a Connect session to "kick it off".
The problem is that as soon as the mainframe SAS program ends a data step, it tries to communicate back to the local session,
and since the communication has timed out at they point, the attempt is unsuccessful and the program ends. My difficulty
is finding a way to get the mainframe job to run to the end.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I tried the following in PC SAS, but it did not work. Please give me a sample PC SAS program that runs a mainframe job. Thanks. -- Warren
%let cs2=mvsw.sysplex.bns; /* macro cs2 points to site 2 */
signon cs2.spaw820 user=_prompt_; /* command to connect to cs2 */
rsubmit;
x " SUBMIT VQ487.VQ3.PRG(CONTENT)";
endrsubmit;
signoff cs2.spaw820; /* command to disconnect cs2 */
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hey Warren:
What you are using looks very familiar - you wouldn't be working at a large Canadian bank would you? A red one?
I think I'm the person who installed the spawner there....
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
You are right, are you Bruce? Please give me a sample program. Thanks. -- Warren
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Warren:
Not Bruce, but I know him - I'm no longer with bns.... (as is he).
Your code looks mostly correct - what error message are you getting? It may have something to do with the quoted string you are submitting to the
internal reader. I may have to do with the way the Spawner is started on the mainframe. Also - what version of SAS are you running (on the mainframe)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I don't get an error. I even added the quotes as follows.
x " SUBMIT 'VQ487.VQ3.PRG(CONTENT)' "
I'm running 8.2 on the mainframe, but I can also easily change it to 9.2 by using the following.
//STEP1 EXEC SAS9
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Warren:
Replace the "X" command in your code with this:
tso sas input('''VQ487.VQ3.PRG(CONTENT)''');
the "sas" is the name of the sas exec on your z/OS system - which, if I remember is actually just "sas" unless \
someone has changed it from what I remember. Let me know what happens - if this won't work there is a very
complicated fix.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
This doesn't work. I got no error messages, but I also could not find any evidence that the program was submitted for mainframe execution.
Below is my PC SAS code. Please advise. Thanks. -- Warren
%let cs2=mvsw.sysplex.bns; /* macro cs2 points to site 2 */
signon cs2.spaw820 user=_prompt_; /* command to connect to cs2 */
rsubmit;
tso sas input("VQ487.VQ3.PRG(CONTENT)");
endrsubmit;
signoff cs2.spaw820; /* command to disconnect cs2 */
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I'd really want this to work so that eventually, I can schedule mainframe jobs using PC SAS. Thanks. -- Warren
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Warren:
There is another method that works but it does not use the Spawner - we use it here all the time.
I will look up the details.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Warren:
It looks like you have the same problem as I do. The Spawner is not "authorized" on the z/OS box to
issue commands - such as a TSO SUBMIT or a "X" command - which is really the same thing. If you
have access to the Spawner log you should be able to see this (or know someone who has access...).
The fix is quite complicated because you need to change the script that the Spawner runs (it is a task
that is really run in UNIX on the z/OS box). SAS and IBM provide a download of the new command that
you can run via the Spawner so that it is "authorized" to do the submit. Not sure how you would go about
getting this changed because it took me 18 months just to get the Spawner up and running in the first place.
Another option is the use FTP to get the file from your local session to the mainframe and submit it to the
interal reader, but this may also not work (it doesn't work for me here) also.
I suggest that you check the Spawner log first to see what the error is forst and proceed from there.
You would happen to be the Warren that went on the Year 2000 COBOL programming course a long
time ago at the DELL building at Cummer and the 404 are you?
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
No, I don't remember going to the Year 2000 COBOL programming course, even though I was using COBOL at that time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Warren,
Damn - thought you might be someone I know back in the day.
Anyhow - what you need to do is connect to the mainframe using the "old" - non spawner way and then you can submit
batch jobs to the system at will. I'm assuming that you have SAS on your desktop (laptop?) correct? Then you need to do....
%let a=%ip.address.of.mainframe%;
filename rlink 'c:\sas\source\scripts\tsocmsip.scr'; *or wherever the scripts are*;
%let remote=a;
options remote=&remote comamid= tcp set=tcpnt3270 1;
signon;
You need the IP of the mainframe box you want to connect to and the location of the script file which is somewhere on your
PC in the SAS installation. This will do a TN3270 connection to the mainframe which is slower than using the Spawner and
you need to use your TSO credentials to sign on. Also - you can only have 1 session open at a time. And you may need to
customize the script to suit your own environment (I don't have mine any more but I do have the TSO sign on code....)
Give it a try and let me know what happens.