Distributed Processing Transcript

Distributed Processing
Transcript
Distributed Processing Transcript was developed by Michelle Buchecker. Additional contributions were
made by Christine Riddiough and Cheryl Doninger. Editing and production support was provided by the
Curriculum Development and Support Department.
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of
SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product
names are trademarks of their respective companies.
Distributed Processing Transcript
Copyright © 2008 SAS Institute Inc. Cary, NC, USA. All rights reserved. Printed in the United States of
America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
any form or by any means, electronic, mechanical, photocopying, or otherwise, without the prior written
permission of the publisher, SAS Institute Inc.
Book code E1211, course code RLSPCON4, prepared date 17Jul2008.
RLSPCON4_001
ISBN 978-1-59994-676-4
For Your Information
Table of Contents
Lecture Description ..................................................................................................................... iv
Prerequisites ................................................................................................................................. v
Distributed Processing................................................................................................... 1
1.
Basics of Distributed Processing ........................................................................................ 5
2.
Submitting Code to a Remote Machine ............................................................................ 21
3.
Examining Remote SAS Libraries.................................................................................... 29
4.
Redirecting the Output and the Log.................................................................................. 34
5.
Involving Multiple Machines............................................................................................ 42
iii
iv
For Your Information
Lecture Description
This is the third e-lecture of a four-lecture series on the basics of SAS/CONNECT software. This lecture
teaches you how to use SAS/CONNECT software to submit your SAS programs to execute on a remote
machine.
To learn more…
For information on other courses in the curriculum, contact the SAS Education
Division at 1-800-333-7660, or send e-mail to training@sas.com. You can also
find this information on the Web at support.sas.com/training/ as well as in the
Training Course Catalog.
For a list of other SAS books that relate to the topics covered in this
Course Notes, USA customers can contact our SAS Publishing Department at
1-800-727-3228 or send e-mail to sasbook@sas.com. Customers outside the
USA, please contact your local SAS office.
Also, see the Publications Catalog on the Web at support.sas.com/pubs for a
complete list of books and a convenient order form.
For Your Information
Prerequisites
Before listening to this lecture, you should be able to
• write DATA and PROC steps
• understand error messages in the SAS log and debug your program
• use a LIBNAME statement to access SAS data libraries
• log on to a remote SAS session through either a SAS spawner or a SAS script file.
v
vi
For Your Information
Basics of SAS/CONNECT®
Software Lecture Series
Welcome to the lecture series on the basics of SAS/CONNECT software.
For Your Information
vii
Basics of SAS/CONNECT Software Lecture Series
ƒ Connecting to a Remote Host
ƒ Accessing a Remote SAS Data Library
ƒ Distributed Processing
ƒ Transferring Data and Macro Variables
2
This series consists of four lectures that address connecting to a remote host, accessing a remote SAS data
library, distributed processing, and transferring data and macro variables. This is the third lecture in this
series, Distributed Processing. We encourage you to complete the other three lectures to get a full
understanding of the basics of SAS/CONNECT software.
viii
For Your Information
Demonstrations
3
This lecture series includes demonstrations of many lecture tasks. The code used in the demonstrations is
available as a handout under the Reference link in the left viewing pane. You can print the handout for
your reference at any time.
For Your Information
ix
Exercises
4
The lecture series also includes exercises for you to complete on your own environment. These exercises
are optional, but completing them will help you understand the topics presented. When you reach an
exercise slide, please pause the recording and minimize this window. A handout with the exercise steps is
available under the Reference link. We recommend that you print the exercise handout to have as a
reference when completing the exercises.
And now, it’s time to start lecture 3, Distributed Processing. I'll turn things over to your instructor for the
series, Michelle.
x
For Your Information
Distributed Processing
1.
Basics of Distributed Processing .................................................................................... 5
2.
Submitting Code to a Remote Machine ......................................................................... 21
3.
Examining Remote SAS Libraries.................................................................................. 29
4.
Redirecting the Output and the Log .............................................................................. 34
5.
Involving Multiple Machines........................................................................................... 42
2
Distributed Processing
1. Basics of Distributed Processing
3
Distributed Processing
Welcome to our next lecture, which is about distributed processing. I am your instructor, Michelle. In this
lecture we are going to take a look at...
4
Distributed Processing
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
2
distributed processing in more detail. We’ll start off by looking at the basics of distributed processing, and
then get into how to submit code to a remote machine. Next we’ll see how to look at the data on that
remote machine. When you submit code to a remote machine it is going to generate a log and output that
is not the same as your local log and outputs. So in this fourth lecture we’ll see how we can take control
and direct it wherever we like. And lastly we look at some scenarios that discuss when you are remote
submitting to more than one machine.
1. Basics of Distributed Processing
1.
Basics of Distributed Processing
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
3
Our first topic is the basics of distributed processing.
5
6
Distributed Processing
Objectives
„
Review compute services.
„
Define distributed processing.
„
Define synchronous execution.
4
In this section we’ll have a little review on what compute services and distributed processing are and also
define what is called synchronous execution.
1. Basics of Distributed Processing
7
Compute Services
Compute services enable you to move any or all segments of an
application to other processors to take advantage of hardware,
software, and data resources.
For example, using compute services, you can produce
text reports as a result of remote
processing on remote data.
Result
Data
Server
(Remote)
5
Client (Local)
Compute services allows you to take a piece of your code and move it to another machine for processing.
This lets you take advantage of hardware, like a more powerful machine, software that you may have
installed locally, and data.
So if we have a SAS session up and running on our local machine and sign on to our remote machine,...
8
Distributed Processing
Compute Services
Compute services enable you to move any or all segments of an
application to other processors to take advantage of hardware,
software, and data resources.
For example, using compute services, you can produce
text reports as a result of remote
processing on remote data.
Result
Data
Server
(Remote)
Request
6
Client (Local)
we can then request to have the program process on the remote machine.
1. Basics of Distributed Processing
Compute Services
Compute services enable you to move any or all segments of an
application to other processors to take advantage of hardware,
software, and data resources.
For example, using compute services, you can produce
text reports as a result of remote
processing on remote data.
Result
Data
SAS Program
Server
(Remote)
Request
7
Client (Local)
The remote machine executes that code, and by default,...
9
10
Distributed Processing
Compute Services
Compute services enable you to move any or all segments of an
application to other processors to take advantage of hardware,
software, and data resources.
For example, using compute services, you can produce
text reports as a result of remote
Report
processing on remote data.
Result
Data
Report
SAS Program
Server
(Remote)
8
Client (Local)
sends any reports generated back to our local machine’s Output window.
1. Basics of Distributed Processing
11
Distributed Processing
Distributed processing can be defined as
„
one process (a client or local host) requesting services or data from
another process (a server or remote host) executing on a different
machine
„
the distribution of computing resources to enable utilization of data
files, hardware resources, and software resources between different
computers
„
the division of applications into tasks to be performed on the most
appropriate machine, thereby maximizing all computing resources.
9
The definition of distributed processing is that one process, such as a local SAS session, is requesting
services from another process, like a remote SAS session, or if you are using parallel processing, the
second process can be a separate SAS session on your local machine. We do not discuss parallel
processing in this lecture. Our focus will be on nonparallel processing.
In addition to taking advantage of hardware, software, and data on that remote machine, you can also take
a divide-and-conquer approach by dividing the tasks to execute on the most appropriate machine.
For instance, let’s say we have company branches located throughout the country, each branch having the
data that only applies to them. If the data needs to be summarized before being brought together from the
different branches, you could remote submit the summary code to each branch, and then the summary is
performed on the same machine where the data resides, which is optimal for speed purposes.
12
Distributed Processing
Synchronous Execution
Synchronous execution is the process of executing code sequentially,
whether that execution occurs on a local machine or a remote machine.
Process
Swimming
Data
Synchronous Processing on One Machine
10
Earlier I used the term nonparallel. This is better known as synchronous execution. With synchronous
execution this means that you are executing the code sequentially on a local machine or a remote
machine.
For instance, if we need to process the swimming data, racquet data, and golf data, we submit the code to
process the swimming data first,...
1. Basics of Distributed Processing
Synchronous Execution
Synchronous execution is the process of executing code sequentially,
whether that execution occurs on a local machine or a remote machine.
Process
Swimming
Data
Process
Racquet
Data
Synchronous Processing on One Machine
11
and then after that has completed, the racquet data starts processing,...
13
14
Distributed Processing
Synchronous Execution
Synchronous execution is the process of executing code sequentially,
whether that execution occurs on a local machine or a remote machine.
Process
Swimming
Data
Process
Racquet
Data
Synchronous Processing on One Machine
Process
Golf
Data
12
and when that finishes, the golf data is processed.
1. Basics of Distributed Processing
Synchronous Execution
Synchronous execution is the process of executing code sequentially,
whether that execution occurs on a local machine or a remote machine.
Process
Swimming
Data
Process
Racquet
Data
Synchronous Processing on One Machine
Process
Golf
Data
13
Combine
Swimming/
Racquet/
Golf
Then the three data sets can be combined.
15
16
Distributed Processing
Synchronous Processing on One Machine
Assuming that a computer has three processors, during sequential
processing, only one processor is used.
14
With synchronous processing it doesn’t matter how many processors are on your machine. Only one of
those processors is used, unless it is a PROC that supports multi-threading. But that is part of Base SAS,
and we are focusing on SAS/CONNECT.
1. Basics of Distributed Processing
Synchronous Execution on Multiple Machines
Request
15
Client (Local)
So we can choose to send a request to the remote machine...
Server (Remote)
17
18
Distributed Processing
Synchronous Execution on Multiple Machines
Process
Swimming
Data
Wait
Process
Racquet
Data
16
Client (Local)
Server (Remote)
to process the swimming data followed by the racquet data. While that is happening, the local machines’
SAS session is just in a wait state.
1. Basics of Distributed Processing
Synchronous Execution on Multiple Machines
Process
Golf
Data
Combine
Swimming/
Racquet/
Golf
Result
Request
17
Client (Local)
Server (Remote)
After the processing on the remote machine is complete, then the local machine can start processing the
golf data and combine the three together.
19
20
Distributed Processing
SAS/SECURE Software
SAS/SECURE software
„
provides encryption of network data
„
supports several industry standard encryption algorithms
– RC2, RC4, DES, and TripleDES
„
must be on both client and server.
SAS/SECURE is a separately licensed product due to government
export restrictions and royalty tracking requirements.
18
When data is transferred across the network, it is not sent in secured mode. If this is important to you, you
can license SAS/SECURE software to encrypt the data when it goes across the network. This software
must be installed on both the local and remote machines. Due to U.S. government regulations, we cannot
embed this directly in the software for export reasons. The cost of this software is minimal.
2. Submitting Code to a Remote Machine
2.
Submitting Code to a Remote Machine
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
19
Our next topic is examining how to submit code to be processed on a remote machine.
21
22
Distributed Processing
Objectives
„
Identify benefits and considerations.
„
Submit code to a remote machine for processing.
20
Specifically we’ll take a look at the benefits of remote submit and what you need to take into account.
Then we’ll see how to do the remote submit.
2. Submitting Code to a Remote Machine
23
Compute Services Benefits and Considerations
Compute services are useful when
„
processing remote data files that
– are too large to transfer
– are frequently updated
– must remain on the remote platform for security reasons
„
the remote machine has necessary hardware or software resources
that the local machine does not have
„
a remote CPU is underutilized.
Compute services are less appropriate when
21
„
data files are small
„
a remote CPU is near 100% utilization.
When submitting code to be processed on a remote machine, you are using what is called compute
services. The benefit of compute services is moving the processing to the same machine where the data
resides. This is useful when the data is too large to transfer, is frequently updated and you want to get the
most current data, or you can’t transfer the data for security reasons.
Also compute services are useful to take advantage of software that is installed on the remote machine or
faster hardware that has an underutilized CPU.
It’s probably not a good idea to use compute services if your CPU is near 100% utilization or if your data
files are small. If you have small data files, then Remote Library Services may be a better technique.
24
Distributed Processing
Using Compute Services
Before you use compute services, a connection to the remote machine
must be established. You can either
„
sign on directly with a SIGNON statement
„
use the AUTOSIGNON option to specify to sign on when compute
services need to start a task on the remote machine.
The AUTOSIGNON option enables the local SAS session to
automatically invoke a new SAS session when a request is made.
General form of the AUTOSIGNON option:
OPTIONS
OPTIONSAUTOSIGNON;
AUTOSIGNON;
The default is NOAUTOSIGNON.
22
To use compute services, you must be signed on to the remote machine. This can be done with either a
SIGNON statement that we saw in an earlier lecture or with the AUTOSIGNON option.
The syntax for the AUTOSIGNON option is OPTIONS AUTOSIGNON;. When this option is turned on,
that means any time that you do a remote submit, if you are not already signed on to the remote machine,
this will make the request to sign on. The default is NOAUTOSIGNON.
2. Submitting Code to a Remote Machine
25
Using Compute Services
After a connection to a remote machine is established, you can
send code to execute on that machine by enclosing the code
in an RSUBMIT block.
General form of the RSUBMIT block:
RSUBMIT
RSUBMIT <remote-machine-name>;
<remote-machine-name>;
code
codeto
tobe
beprocessed
processedon
onthe
theremote
remotemachine
machine
ENDRSUBMIT;
ENDRSUBMIT;
23
To specify the code that you want processed on the remote machine, you will surround the code with what
is called an RSUBMIT block. To start the RSUBMIT block, you are going to start with an RSUBMIT
statement. The syntax of the RSUBMIT statement is the keyword RSUBMIT followed by the name of the
remote machine to submit the code to. The machine name is optional and is only really needed if you are
connected to more than one machine. If you are connected to more than one machine and leave off the
machine name in the RSUBMIT statement, then the most recently referenced machine is used.
After the RSUBMIT statement, you’ll write the code that you want to execute on the remote machine.
After that, you will close the RSUBMIT block with an ENDRSUBMIT statement.
26
Distributed Processing
Submitting to a Remote Computer
This demonstration illustrates submitting a program to the
remote machine to sort the orion.staff data set by
Salary and creating a listing report that subsets the data
where Salary is greater than $50,000.
24
In this demonstration, you will see how to submit code to the remote machine. The code will sort the
orion.staff data set by Salary and then create a listing report where Salary is greater than
$50,000. Please refer to your handout for the code being submitted.
In this program I am connecting to an MVS machine using a spawner. My %LET statement creates a
macro variable named MVS, and points to the MVS machine named sdcmvs and a spawner on that
machine named eduspwn.
Since I’m not using a script file, in my SIGNON statement I’m using the option of
USERID=_PROMPT_.
Next I’m starting an RSUBMIT block by saying rsubmit mvs. Since I’m only connected to one
machine, specifying the name of that machine in the RSUBMIT statement is optional.
I then have a LIBNAME statement for my MVS machine to process. If you are not familiar with MVS,
don’t worry about it. It is just whatever code you would normally write to execute on that machine. Next
is a PROC SORT and a PROC PRINT that I want to be executed on my remote machine.
That is all the code I want the remote machine to execute, so I’ll end my RSUBMIT block with an
ENDRSUBMIT statement. If there was any code after this statement, it would be processed by the local
machine.
2. Submitting Code to a Remote Machine
27
Let me go ahead and submit this program.
I’ll be prompted for my user ID and password. So this is what _prompt_ will do for me. So I’ll type those
in.
Notice that even though the PROC PRINT processing occurs on the remote machine, the output was sent
to my local Output window.
Let’s look at the log and scroll up. Notice the line number next to the RSUBMIT statement. That means it
is the 123rd line submitted to my local SAS session. But the LIBNAME statement has a 1 next to it,
because that is the first line of code that the remote session has executed.
28
Distributed Processing
Exercise – Using Compute Services
Connect to your remote machine and remote submit a PROC PRINT on
an existing SAS data set on the remote machine, or remote submit any
code that you may want to run on the remote machine.
Save your program.
25
In this exercise I’d like you to follow the instructions on the slide to use remote submit in your
environment. Save your program.
Please pause the recording while you complete the exercise.
3. Examining Remote SAS Libraries
3.
Examining Remote SAS Libraries
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
26
Welcome back. In this section, we are going to look at how to examine what is in the remote SAS data
library without using RLS.
29
30
Distributed Processing
Objectives
„
Display remote library references.
„
List remote SAS data sets.
27
Specifically you will learn how to display the remote library librefs and how to list the names of the
remote SAS data sets.
3. Examining Remote SAS Libraries
31
Displaying Remote Library References
To view remote library references, use the _ALL_ and LIST options in
the LIBNAME statement.
General form of the LIBNAME statement to list library information:
LIBNAME
LIBNAMElibref
libref || _ALL_
_ALL_ LIST;
LIST;
The value for libref is any valid library reference.
_ALL_ is all currently defined library references.
LIST prints to the SAS log a list of the attributes for SAS data libraries.
Items listed vary by operating system.
28
You are probably familiar with the LIBNAME statement. But what you might not know is that there is an
option in the LIBNAME statement called the LIST option. The LIST option lists the attributes for the
libref listed in the LIBNAME statement. You can specify a specific libref or use the keyword _ALL_ for
all librefs currently assigned.
32
Distributed Processing
Displaying Remote Librefs
This demonstration illustrates submitting a program
to the remote machine to display all currently defined
remote librefs.
29
So in this demo, you’ll see how the LIST option in the LIBNAME statement, when submitted to the
remote machine, displays a list of all currently defined remote librefs. This is useful, especially if there is
an autoexec file that assigns librefs you may not have realized. Please refer to your handout for the code.
In this demo, I am still connected to that same MVS session.
So inside my RSUBMIT block, I’m going to submit libname _all_ list; to get a listing of all
librefs assigned in my remote SAS session.
When I submit this program and check the log and scroll up, you’ll notice that all of the libref information
is MVS related. So I have a libref called Orion with MVS related information. There’s SASHELP,
SASUSER, and if I scroll down, you will see the WORK library on the MVS machine.
3. Examining Remote SAS Libraries
33
Exercise – Displaying Librefs
Remote submit a LIBNAME statement using the _ALL_ keyword
and the LIST option to identify the librefs that are assigned to your
remote SAS session.
30
For this exercise I’d like you to remote submit a LIBNAME statement using the _ALL_ keyword and the
LIST option to identify the librefs that are assigned to your remote SAS session. Pause the recording
during your exercise.
34
Distributed Processing
4.
Redirecting the Output and the Log
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
31
You may have noticed that although your code was submitted to your remote SAS session, the log from
that SAS session is integrated into your local log, and the output is sent to your local Output window. In
this section, we are going to see how to redirect both the log and the output to different locations, which is
easier for debugging purposes and control.
4. Redirecting the Output and the Log
Objectives
„
Redirect the output to a file on the local machine.
„
Redirect the output to a file on the remote machine.
„
Redirect the log to a file on the local machine.
„
Redirect the log to a file on the remote machine.
32
We can control this redirection for both the output and the log separately. So you will learn how to
redirect the output to a file on the local machine and how to redirect it to a file on the remote machine.
Ditto for the log. Then you can choose which works best for you.
35
36
Distributed Processing
Redirecting the Output and Log
Use the PRINTTO procedure to redirect the output and log.
General form of the PRINTTO procedure:
PROC
PROCPRINTTO
PRINTTO<options>;
<options>;
RUN;
RUN;
Options include the following:
33
PRINT=fileref | 'filename'
directs all procedure output to an external
file until redirected with another PROC PRINTTO
statement.
LOG=fileref | 'filename'
directs all log output to an external file until
redirected with another PROC PRINTTO
statement.
NEW
clears any information in a file and prepares the
file to receive output. If you do not use the NEW
option, the output is appended to the file.
To redirect either the log or the output, we are going to use a PROC PRINTTO step. The syntax is PROC
PRINTTO, with two Ts, and then some options followed by a RUN statement.
To redirect the output, you would use the PRINT= option, where you would type PRINT= and then either
a fileref that points to a file you previously defined with a FILENAME statement or you can specify the
name of the filename directly in quotation marks.
To redirect the log, use the LOG= option. Once again you can specify a fileref, or in quotation marks, the
name of the file.
By default, if there is already text in the file, the file will be appended to it. If you want to clear out any
existing text in the file, just use the NEW option in the PROC PRINTTO statement.
4. Redirecting the Output and the Log
37
Redirecting the Output and Log
If the PROC PRINTTO step is
„
outside the RSUBMIT block, the output is stored on a file on the
local machine
„
inside the RSUBMIT block, the output is stored on a file on the
remote machine.
34
Now if you use the PROC PRINTTO step outside of your RSUBMIT block, then that will write the files
to the local machine. If it is used inside an RSUBMIT block, then the files will be written to the remote
machine.
38
Distributed Processing
Redirecting the Output and Log Windows
After PROC PRINTTO is submitted, all output that normally appears
in the Output or Log window is redirected to the file specified.
To redirect output back to the Output and Log windows, submit the
following:
proc printto;
run;
35
Once you have submitted the PROC PRINTTO, all subsequent log text or output text will be written to
that file. It’s like a gate. By default, the log is sent to the Log window, but when you use PROC
PRINTTO, you are closing that gate and redirecting to the file specified by PROC PRINTTO. If you want
to close the gate and redirect the log back to the Log window, then you need to submit proc printto,
semicolon, run, semicolon. This will redirect both the log and the output back to their normal locations,
which are the Log and Output windows if you are in an interactive SAS session, or the log and list files if
you are running in a batch or non-interactive session.
4. Redirecting the Output and the Log
39
Redirecting Output to a File
This demonstration illustrates redirecting the output to a file
on the local machine.
36
So I’d like to redirect the output from my remote SAS session to a separate file on my local machine.
Maybe I’d like to e-mail this report to someone or put it on a Web page. Once again the code can be found
in your handout.
In this next demo, I am writing a PROC PRINTTO step with a PRINT= option outside of my RSUBMIT
block. Which means any output which would normally get sent to my local output window is being
redirected to c:\temp\orionout.txt. Remember the NEW option says that if there is any text already in that
file to delete what is there. Without the NEW option, an append will take place.
Inside my RSUBMIT block I have the same code that we saw submitted earlier.
Following the ENDRSUBMIT, I have a PROC PRINTTO; which says redirect any future output back to
the local output window.
And for the first time we are seeing a SIGNOFF statement. I no longer need to be connected to the remote
machine, so I will sign off and that will close my remote SAS session and gracefully log me off of my
remote machine.
Let me clear my Log and Output windows. Then submit the code.
If I check the Log window, you will see the remote SAS session written to the log since I didn’t have a
LOG= option in the PROC PRINTTO.
40
Distributed Processing
If I now bring up my Windows Explorer window and navigate to C:\temp, you’ll notice I have a file
called orionout.txt. If I double-click on that, it opens it up in Notepad, and I see my report.
So this is a nice way to take control over your logs and your output.
4. Redirecting the Output and the Log
41
Exercise – Redirecting Log and Output
Based on the program you saved earlier that remote submitted
a PROC PRINT, modify the program to do the following:
„
Direct the output to a file on your local machine named
c:\temp\rsubmit_out.txt
„
Direct the log to a file on your local machine named
c:\temp\rsubmit_log.txt
After you have completed that, if possible, repeat the exercise but have
the files created on your remote machine following the file-naming
convention of your remote machine.
37
For this exercise follow the instructions on the slide to send your remote log and output to separate files
on your local machine. If you have permissions to create files on the remote machine, repeat the exercise
and store the files on the remote. Pause as usual while you complete the exercise.
42
Distributed Processing
5.
Involving Multiple Machines
Distributed Processing
1. Basics of Distributed Processing
2. Submitting Code to a Remote Machine
3. Examining Remote SAS Libraries
4. Redirecting the Output and the Log
5. Involving Multiple Machines
38
Up to this point, we have focused the discussion on connecting to only one remote machine. In the last
section for this lecture, we are going to see an additional scenario.
5. Involving Multiple Machines
Objectives
„
Use a remote/server machine as a client/local machine.
„
Create nested RSUBMIT blocks.
39
The scenario we are going to look at is a leap-frog-like approach where we are going to use the local
machine to connect to a remote machine, which will then connect to a different machine, and therefore,
we will need nested RSUBMIT blocks.
43
44
Distributed Processing
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Data
40
Client (Local)
So let’s say you are working on your local machine and that machine can connect to Machine A. But the
data you need is really on Machine B.
5. Involving Multiple Machines
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Data
41
Client (Local)
No connection to machine B
And your machine has no way to connect to Machine B. Maybe it is on a different network, or can only
be accessed by Machine A and no other machine.
45
46
Distributed Processing
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Data
Server
(Remote)
Sign on A
42
Client (Local)
So the first step is to sign on to Machine A in the same way as we always have. So your machine is
considered the local machine for this connection...
5. Involving Multiple Machines
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Data
Server
(Remote)
Sign on A
43
Client (Local)
and Machine A is considered the remote machine for this connection. Remember that when using an
RSUBMIT block, we can have code instructions process on the remote machine.
47
48
Distributed Processing
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Data
Server (Remote)
Sign on B
Sign on A
44
Client (Local)
What we are going to put in that code are instructions to connect to Machine B. Because these
instructions say ”connect from Machine A to Machine B,” that means for this connection...
5. Involving Multiple Machines
Using a Remote Machine to Connect to Another Machine
Machine B
Data
Machine A
Server
(Remote)
Data
Server (Remote)
Client (Local)
Sign on B
Sign on A
45
Client (Local)
Machine A becomes the local and Machine B becomes the remote.
49
50
Distributed Processing
Skeleton Code
filename rlink '!sasroot\connect\saslink\tcpunx.scr';
options remote=bcom1;
signon; /* Connect to Machine A */
rsubmit bcom1;
%let mvs=sdcmvs eduspwn;
signon mvs userid=myid pw=mypw;
/* Connect from A to Machine B */
rsubmit mvs;
/* Code to be processed by Machine B */
endrsubmit;
signoff;
/* Code to be processed by Machine A */
endrsubmit;
46
signoff;
So let’s take a look at the code necessary to make this happen. In this case I’m going to sign on from my
local machine to a UNIX machine using a script file. Then, in an RSUBMIT block, I’m going to have that
UNIX machine sign on to an MVS machine using a spawner.
The FILENAME statement points to the script file to connect to the UNIX machine, and the OPTIONS
statement identifies the name of the UNIX machine as bcom1. We then sign on to bcom1 and issue an
RSUBMIT statement. The first statement inside the RSUBMIT block is naming the MVS machine and
the spawner on that machine. Then you see a SIGNON statement to sign on to the MVS machine. Now
remember that this code is inside an RSUBMIT block, which means that the UNIX machine is the one
making the connection request. Whatever machine is making the request is considered the local machine
for that connection.
After the connection is established, then we can have an RSUBMIT block to send code to the remote
machine. Notice, at this point we have nested RSUBMIT statements. The outer RSUBMIT contains code
that we want Machine A, in our case the UNIX machine, to process. And the inner RSUBMIT contains
code that we want Machine B, our MVS machine, to process. After the ENDRSUBMIT for the inner
RSUBMIT, you would sign off from machine B and then have additional code that you want Machine A
to process. Then close that RSUBMIT block and sign off Machine A.
5. Involving Multiple Machines
Credits
Distributed Processing was developed by M. Michelle Buchecker.
Additional contributions were made by Chris Riddiough and Cheryl
Doninger.
47
This concludes the SAS e-Lecture on distributed processing. I hope you have found the material in this
lecture to be helpful in your work tasks.
51
52
Distributed Processing
Comments?
We would like to hear what you think.
„
Do you have any comments about this lecture?
„
Did you find the information in this lecture useful?
„
What other e-lectures would you like to see SAS develop
in the future?
Please e-mail your comments to
EDULectures@sas.com
48
If you have any comments about this lecture or e-lectures in general, we would appreciate receiving your
input. You can use the e-mail address listed here to provide that feedback. Thank you for your time.
5. Involving Multiple Machines
Copyright
SAS and all other SAS Institute Inc. product or service names are
registered trademarks or trademarks of SAS Institute Inc. in the
USA and other countries.
® indicates USA registration. Other brand and product names are
trademarks of their respective companies.
Copyright © 2008 by SAS Institute Inc., Cary, NC 27513, USA.
All rights reserved.
49
53
54
Distributed Processing