OVERVIEW OF THE SAS GRID

Transcription

1 OVERVIEW OF THE SAS GRID

2 Host Caroline Scottow

3 Presenter Peter Hobart

4 MANAGING THE WEBINAR In Listen Mode Control bar opened with the white arrow in the orange box

5 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. OVERVIEW

6 PLATFORM FOR SAS BUSINESS ANALYTICS The platform for SAS Business Analytics is enterprise software with components that exist on multiple machines throughout the organization

7 SAS GRID MANAGER MULTIPLE WAYS TO LEVERAGE GRID Products Workload Management Enterprise Scheduling Parallelized Processing Any SAS programs SAS Data Integration SAS Web Report Studio SAS Marketing Automation SAS Marketing Optimization SAS Enterprise Miner SAS Enterprise Guide SAS Add-in for Microsoft Office SAS Workspace Server SAS Stored Process Server SAS OLAP Server SAS Stored Processes SAS Risk Dimensions JMP Genomics SAS Demand Forecasting for Retail SAS for Customer Experience Analytics

8 SAS ENTERPRISE GUIDE Enterprise Guide is an easy to use tool for investigating your data It can also create and launch Stored Processes

9 SAS DATA INTEGRATION STUDIO SAS Data Integration Studio is used to design the Extract Transform and Load (ETL) and ELT processes that prepare data for analysis

10 SAS MANAGEMENT CONSOLE SAS Management Console is the administration client for the SAS platform Users, servers and permissions are defined here

11 SAS METADATA SERVER The metadata server is the central point of contact for the SAS platform Every sign-on and transaction contacts the metadata server, which stores and retrieves metadata (information about information)

12 STORED PROCESS SERVER The Stored Process Server executes prebuilt tasks on demand, and delivers the results to a client

13 WORKSPACE SERVER The workspace server does the heavy lifting in the SAS platform, like running code for ETL processes It can also pass work to the SAS Grid instead of running it directly

14 FITTING IT TOGETHER Clients Servers

15 GRID CONTROL SERVER The grid control server controls work sent to the grid

16 GRID NODE(S) A Grid Node is a machine which runs SAS code, controlled by the grid manager

17 GRID MONITORING Grid Monitoring services watch Grid activity for control, reporting and auditing

18 FITTING IT TOGETHER - ADDING GRID Clients Servers Grid

19 SHARED FILE SYSTEM Each grid session must be able to access the same items via the same path - LSF Config files - LSF Binaries for UNIX/Linux - Deployed jobs - SASGSUB work directory - SASUSER directories - High Availability Must be fast e.g. 3 nodes each with 16 cores, 3x16x100 = 4.8 Gigabytes/second

20 SHARED FILE SYSTEM POSSIBLE TOPOLOGIES Permanent SAS data SAS Binaries SAS DATA always on shared storage Permanent SAS data SAS Binaries Node 1 Node 2 Node 3 Node 1 Node 2 Node 3 SAS WORK SAS WORK SAS WORK SAS WORK SAS WORK on Local Storage SAS WORK on Shared Storage

21 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. GRID UTILISATION

22 HIERARCHY OF GRID UTILISATION 1. No Grid 2. Grid available 3. Grid used 4. Grid fully exploited

23 1: NO GRID The only algorithm available for load balancing is Cost. A client is sent to the server which has the most units free to be "spent" on a connection

24 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 0 Current Spend 0 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 0 Current Spend 55

25 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 0 Current Spend 0 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 0 Current Spend 55

26 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 1 Current Spend 100 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 0 Current Spend 55

27 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 1 Current Spend 100 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 0 Current Spend 55

28 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 1 Current Spend 100 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 1 Current Spend 155

29 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 0 Current Spend 150 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 2 Current Spend 200 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 1 Current Spend 155

30 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 1 Current Spend 250 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 2 Current Spend 200 Workspace Server 3 Total Spend 300 Startup cost 50 Cost per client 100 Current Clients 1 Current Spend 155

31 NO GRID: LOAD BALANCING IS COST - BASED Workspace Server 1 Total Spend 1500 Startup cost 150 Cost per client 100 Current Clients 1 Current Spend 250 Workspace Server 2 Total Spend 1000 Startup cost 0 Cost per client 100 Current Clients 1 Current Spend 200 Workspace Server 3 Total Spend 300 Startup cost 55 Cost per client 100 Current Clients 2 Current Spend 255

32 2: GRID USED FOR LOAD - BALANCING The grid monitoring service knows how busy each server is The jobs are sent to the quietest workspace server (But not to the grid)

33 3: USING GRID SESSIONS If 5 lines of code are added, the workspace server passes the job to the grid, Jobs are queued and released based on The current workload on each grid node User - defined Policies

34 3: USING GRID SESSIONS 5 LINES OF CODE Enable the grid Sign on to the grid Submit work to a grid session End the submission Sign off from the grid

35 GRID ENABLEMENT STATEMENTS Original code

36 WITH GRID, BALANCING IS BASED ON WORKLOAD Grid We are now at stage 3 (of a possible 4)

37 WITH GRID, BALANCING IS BASED ON WORKLOAD Grid We are now at stage 3 (of a possible 4)

38 WITH GRID, BALANCING IS BASED ON WORKLOAD Grid We are now at stage 3 (of a possible 4)

39 WITH GRID, BALANCING IS BASED ON WORKLOAD Grid We are now at stage 3 (of a possible 4)

40 WITH GRID, BALANCING IS BASED ON WORKLOAD Grid We are now at stage 3 (of a possible 4)

41 WITH ONE ADDITIONAL STEP, WORKLOADS ARE PARALLELISED Grid We are now at stage 4 (of a possible 4)

42 SAS GRID SYNTAX PARALLEL PROCESSING Code can be refactored manually or by using SAS code analysis tools This is covered later in the presentation %let rc=%sysfunc(grdsvc_enable(_all_, resource=sasapp)); signon session1; rsubmit session1 wait=yes; /* session1 code to be remote submitted */ endrsubmit; signon session2; rsubmit session2 wait=no; /* session2 code to be remote submitted */ endrsubmit; signon session3; rsubmit session3 wait=no; /* session3 code to be remote submitted */ endrsubmit; signon session4; rsubmit session4 wait=no; /* session4 code to be remote submitted */ endrsubmit; waitfor _all_ session1 session2 session3 session4; signoff _all_; Session 1 Session 2 Session 3 Session 4

43 WITH JOB MODS, GRID USAGE IS MAXIMISED Grid Parallel Execution

44 HIERARCHY OF GRID UTILISATION 1. No Grid Workspace server load balancing is cost based 2. Grid available Workspace servers are load balanced by the grid 3. Grid used Jobs run on the grid via queues Enhanced monitoring and control Enhanced resilience Enhanced scalability 4. Grid fully exploited Jobs can run in parallel on multiple grid nodes

45 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. QUEUES

46 OVERVIEW OF GRID QUEUES QUEUE PARAMETERS INCLUDE: Priority Pre-emption Niceness Fair share Host constraints Resource lists Static indices Dynamic indices Parameters can be Time / Date - based

47 OVERVIEW OF GRID QUEUES

48 OVERVIEW OF GRID QUEUES Picture a Cinema

49 OVERVIEW OF GRID QUEUES QUEUES When you arrive at the cinema you may have to wait in line before getting in. This is a multiplex : it is showing different films in different rooms at the same time

50 OVERVIEW OF GRID QUEUES SEATS In each room there are a limited number of seats This number can vary from room to room You can change the number of seats, but that does not change the size of the room

51 OVERVIEW OF GRID QUEUES CHARACTERISTICS AND CAPABILITIES Each room has a certain number of static attributes - For example: Dolby sound 3D projection The fabric of the seats The color of the walls

52 OVERVIEW OF GRID QUEUES STATE OF THE ROOM The room also has a certain number of changing parameters: Temperature Amount of Popcorn on the floor Noise level

53 OVERVIEW OF GRID QUEUES WHAT DOES THIS HAVE TO DO WITH GRID USAGE? Your grid is like our cinema in many ways. The lines are the Queues The rooms are the Hosts The seats in each room are the Slots The fixed attributes of the rooms are the Static Resources The variable attributes are the Dynamic Resources, or Indices

54 OVERVIEW OF GRID QUEUES HOSTS AND JOB SLOTS When all the seats (Slots) are taken, a room (Host) is considered full (Closed) No-one else will be sent to that room But if someone walks out, someone else can take their place By default 1 CPU core = 1 job slot

55 OVERVIEW OF GRID QUEUES QUEUES, PRIORITY, AND JOBS There can be more than one Queue Think of a VIP line. People waiting in the VIP line get called before the others (because they are in a higher priority queue) But not everyone can go into the VIP line Typically, people (Jobs) will fill up the queues in the order in which they arrive That is the default, and called First-Come-First-Serve (FCFS) The administrator can move people within and between queues

56 OVERVIEW OF GRID QUEUES PRE-EMPTION AND FAIRSHARE SCHEDULING People can not only pass you, but walk into a room, pull someone out of their seat, and take their place! This is called Preemption Preempted people can resume their watching later, when a seat opens up in the same room If the VIP line (queue) always has someone in it, the regular people might never get in. You can enable FairShare Scheduling to counter that For example, 1 regular for every 5 VIPs If someone gets into the line, and saves 20 spots for his family and friends, it s not fair. It s allowed, but fair share will re-order the line to interleave these jobs with others

57 SAS GRID MANAGER WORKLOAD MANAGEMENT HOST A Applications SAS Grid Manager Normal Queue HOST B HOST C

58 SAS GRID MANAGER WORKLOAD MANAGEMENT HOST A High Priority Queue Applications SAS Grid Manager Normal Queue HOST B Night Queue HOST C

59 POLICIES STANDARD QUEUES Name Normal Priority Description The default queue for all jobs Higher priority queue and pre-emptive of normal Night Releases jobs only between 18:00 and 06:00 Idle Short Rerun Runs jobs only when grid load is low High priority but jobs with >15 minutes runtime will terminate "Catches" failed jobs and re-runs

60 POLICIES POSSIBLE ADDITIONAL QUEUES Name Description Analytics Default Departmental Queue: high priority 08:00-18:00 Batch Default Departmental Queue: high priority 18:00-08:00 FSA jobs High priority, Pre-emptive, Low Niceness, Limited access RerunHi "Catches" critical failed jobs and reruns at higher priority Performance Test High priority, pre-emptive, constrained to 3 active slots

61 POLICIES SUGGESTED ADDITIONAL POLICIES Name Description Max job slots Can be set at User / User Group / Host / Queue / Grid level(s) Threshold e.g. Host closed if CPU % usage > 80% Alerts e.g. If a threshold exceeded then send mail ESUB RESOURCES HOSTS Fair Share Conditional logic e.g. "If Peter submits a job to the priority queue between 09:00 and 11:00 on a Friday then move the job to the NORMAL queue ELSE move to the NIGHT queue" Job requires specified items e.g. O/S, available memory Limit Queue to specified Grid Nodes Ratio between e.g. Priority and Normal jobs executed

62 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. QUEUE ROUTING OPTIONS

63 IMPLEMENTATION SENDING JOBS TO THE REQUIRED QUEUE Methods (in increasing precedence) Notes Specify a queue in the submitted SAS code Y Y Can be overridden by the methods below Within a SAS server context, specify "queue=" on the grid server metadata object Y Y May need to create multiple contexts Use a Grid Options Set N Y Route user to a queue based on level and client used Create an ESUB script Y Y Allows complex logic, requires scripting ability

64 SENDING JOBS TO THE REQUIRED QUEUE 1. SPECIFYING A QUEUE IN THE SUBMITTED SAS CODE The header for submitted code can contain multiple options. Example syntax is shown here. %let jnvar=weeklyreport; %let jovar=queue=priority; %let rc=%sysfunc(grdsvc_enable(_all_, server=sasapp; jobname=jnvar; jobopts=jovar)); signon session1;

65 SENDING JOBS TO THE REQUIRED QUEUE 2. USING SERVER CONTEXTS Define a new server context in SAS Management Console

66 SENDING JOBS TO THE REQUIRED QUEUE 2. USING SERVER CONTEXTS Within the server context add a Grid Server with the required options Add other servers as required Workspace Stored Process etc.

67 SENDING JOBS TO THE REQUIRED QUEUE 2. USING SERVER CONTEXTS Set metadata permissions to route users to the appropriate server context The context's grid server properties will request the appropriate queue

68 SENDING JOBS TO THE REQUIRED QUEUE 3. USING GRID OPTIONS SETS Define the required grid options Associate these with combinations of user / group /client A single grid context can route to many queues

69 SENDING JOBS TO THE REQUIRED QUEUE 3. USING GRID OPTIONS SETS Grid options sets can also be specified in code %let rc=%sysfunc(grdsvc_enable(_all_, "server=sasapp; gridoptset='gridsetone'")); signon session1;

70 SENDING JOBS TO THE REQUIRED QUEUE 4. USING ESUBS if [ "$USER" = "peter" ]; esubs are scripts which modify the job header before execution esubs can contain complex logic then echo 'LSB_SUB_QUEUE = "priority" ' > $LSB_SUB_MODIFY_FILE fi exit 0

71 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. ADMINISTRATION TOOLS

72 GRID ADMINISTRATION OPTIONS RTM ("Report Track Monitor") SAS Management Console grid plugin Direct alteration of configuration text files in a text editor

73 GRID ADMINISTRATION RTM RTM is the preferred tool for SAS grid administration Intuitive point and click tool Ability to save configuration snapshots and easily revert to any snapshot Extensive reporting / auditing capabilities Browser - based client ~99% of all admin tasks can be performed by RTM

74 GRID ADMINISTRATION RTM RTM has two levels of access User can view, alter, kill jobs Administrator can view, alter grid properties (e.g. queue priority) Note: in SAS 9.4 M3, the functionality of RTM has been incorporated into SAS Environment Manager

75 GRID ADMINISTRATION THE GRID ADMINISTRATOR ROLE Typically 1 grid administrator for multiple SAS environments Role can be assigned to: Grid Administrator Infrastructure / IT SAS Administrator(s) Advantages / disadvantages to each approach Lev1 SAS Admin Lev2 SAS Admin Lev3 SAS Admin

76 GRID ADMINISTRATION SAS MANAGEMENT CONSOLE GRID PLUG-IN Can perform many grid admin tasks View status Suspend / resume jobs Move jobs to another queue Cannot change global grid settings Cannot define new queues

77 GRID ADMINISTRATION EDITING CONFIGURATION FILES / COMMAND LINE All admin tasks can be performed by this approach Begin Queue QUEUE_NAME = night DESCRIPTION = used for jobs running at night ADMINISTRATORS = sasadmin usergroup1 PRIORITY = 40 DISPATCH_WINDOW = (18:00-07:30) RUN_WINDOW = (18:00 08:00) RES_REQ = select[(ut<0.7 && mem>1024)] HOSTS = all ~sash04 End Queue

78 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM DASHBOARD

79 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM COMPUTE NODES

80 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM - QUEUES

81 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM CONFIGURATION OF QUEUES

82 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM CONFIGURATION OF QUEUES

83 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM CONFIGURATION OF QUEUES

84 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM CONFIGURATION OF QUEUES

85 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM REPORTS

86 SAS GRID MANAGER WORKLOAD MANAGEMENT RTM REPORTS

87 SAS GRID MANAGER WORKLOAD MANAGEMENT PLATFORM PROCESS MANAGER SCHEDULING Any SAS Program SAS Data Integration Studio Scheduling SAS Web Report Studio SAS Marketing Automation SAS Marketing Optimization C o p yr i g ht 2013, S A S I nstitute Inc. A l l r i g hts r eser v ed.

88 SAS GRID MANAGER SAS MANAGEMENT CONSOLE Administration Scheduling Flow design Events Job Status Time File Existence Sub-flows

89 SAS GRID MANAGER HIGH AVAILABILITY Resilience SAS Applications Critical SAS Servers C o p yr i g ht 2013, S A S I nstitute Inc. A l l r i g hts r eser v ed.

90 SAS GRID MANAGER HIGH AVAILABILITY OF SAS APPLICATIONS HOST A Applications SAS Grid Manager normal queue sas_rerun queue HOST B HOST C

91 SAS GRID MANAGER HIGH AVAILABILITY OF SAS APPLICATIONS HOST A Applications SAS Grid Manager normal queue sas_rerun queue HOST B HOST C

92 SAS GRID MANAGER HIGH AVAILABILITY OF CRITICAL SAS SERVERS Grid Node 1 Grid Node 2 Grid Node 3 Grid Control Grid Control Metadata Metadata Active Passive Active Active Shared/Clustered File System

93 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. MULTI-TENANCY AND GRID PARTITIONING

94 Lev3 Lev2 Lev1 SHARING THE GRID MULTI - TENANCY ON A SINGLE GRID Dept1 Dept2 Dept3 Slaves L1D1Queue L1D2Queue L1D3Queue L2D1Queue L2D2Queue L2D3Queue L3D1Queue L3D2Queue L3D3Queue Master

95 MULTI TENANCY Production Queue Performance Test Queue Production can use 2 hosts / 32 cores PT can use only 1 host / 16 cores Consider making this a time - dependent setting

96 MULTI TENANCY Production Queue Performance Test Queue Production can use 3 hosts / 48 cores PT can use 3 hosts / 48 cores but has lower priority, higher niceness Consider making Production pre-emptive of PT

97 MULTI TENANCY Production Queue Performance Test Queue Production can use all 3 hosts / 48 cores PT can use only 1 host / 16 cores

98 MULTI TENANCY SHARED EVERYTHING Queue 2 Queue 1 Both queues can use all cores but Queue 1 has a smaller limit on the number of jobs it can run

99 MULTI TENANCY FAIR SHARE RATIOS Queue 1 Queues with fair share of 4:1 Queue 2

100 MULTI TENANCY RESOURCE TAGS Queue 1 Requires "ORACLE" Resources: "ORACLE" Resources: "ORACLE" "GRAPH" Resources: "GRAPH"

101 MULTI TENANCY HOST STATUS Node 1 Slots : 16 Slots free: 2 Status : OPEN Node 2 Slots : 16 Slots free: 4 Status : OPEN Node 3 Slots : 16 Slots free: 0 Status : CLOSED

102 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. YARN INTEGRATION

103 YARN INTEGRATION YARN (Yet Another Resource Negotiator) is the Hadoop resource manager The SAS Grid can use YARN as an alternative to LSF for allocating resources YARN enables policies to be set in relation to other Hadoop workload LSF policies (queues etc.) will no longer be applied Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

104 YARN INTEGRATION HOW YARN MANAGES RESOURCES In response to a resource request by an application master, YARN allocates a number of containers A container has a number of vcores and an amount of memory The application master then submits this approved allocation along with the programs it wants to run to the assigned node managers which run the programs As one application completes and frees resources, YARN will assign these to the next waiting application Although YARN is allocating resources it is not necessarily constraining resources An application can use more (or less) than its allocation YARN tracks resources it has granted to an application, not resources actually used by an application YARN launches jobs is if applications are using their assigned resources Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

105 YARN INTEGRATION MONITORING Resources can be monitored at Queues can be monitored at Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

106 YARN INTEGRATION RESOURCES YARN is configured to manage a subset of the hardware resources Memory vcores / Cores Queue assignment The balance of the resources are managed by the OS alone Each Hadoop vendor has different recommendations on YARN configuration best practice You can then adjust settings from this starting point Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

107 YARN INTEGRATION POLICIES yarn.nodemanager.resource.memory-mb Amount of physical memory on each node in MB that can be allocated for containers Setting this too low can leave memory unused Too high can starve processes not managed by YARN yarn.nodemanager.resource.cpu-vcores Number of virtual cores on each node that can be allocated for containers A container must have at least one vcore to run Therefore the number of vcores limits the number of contasiners that can run The number can be much higher or lower than the number of physical cores With YARN a multi-threaded container can use unlimited cores even of only assigned one vcore Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

108 Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d. MIGRATING CODE TO THE SAS GRID

109 CODE MIGRATION CONSIDERATIONS Typically running code on grid requires no more alterations than a similar non - grid platform Factors: Where is the code being run? Base SAS SAS Client e.g. Enterprise Guide How is the code run? Interactive sessions Batch? Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

110 MIGRATION CHANGE IN TOPOLOGY MOVING FROM BASE SAS TO A SAS CLIENT Local PC Windows Server Windows Linux Mainframe Local PC Windows Server Windows Linux Mainframe EG Project Code SAS Connect Code Code IOM Code Data Data Data SAS SAS SAS Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

111 CODE MIGRATION CODE CHANGES REQUIRED From.. Interactive session Batch Base SAS Grid wrapper statements must be added No changes needed Metadata credentials must be supplied SAS Client e.g. SAS Enterprise Guide SAS Data Integration Studio SAS Studio No changes needed Grid wrapper statements are inserted automatically by the SAS client Metadata credentials are supplied by the SAS client No changes needed Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

112 CODE MIGRATION MINIMISING CHANGES IN CODE File paths Replicate existing file paths (if possible). If the OS has changed e.g. from Windows to Linux then paths will need to be reassigned Be aware of different "new line" spec in text files (CR/LF in windows, just LF in Linux) SAS Code will assume the correct line terminator for the platform but files may have been migrated incorrectly SAS option TERMSTR= can be used to read e.g. Windows files on Linux Libraries Assign libraries in metadata with the same names as existing code Consider pre-assigning libraries Credentials SAS clients will provide credentials At the OS a user may act as "themself" or as a system account "sassrv" depending on system design Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

113 CODE MIGRATION CODE READINESS FOR MIGRATION Item "Good" code "Bad" code Libraries File paths Parameters Passwords Already assigned in metadata Assigned once at the top the code Assigned as macro variables Use relative paths Many hard coded references throughout the code Documentation Good commenting describing code and any dependencies on other code No documentation. Treated as a "black box" SQL Views Data Step views Macros All source code is available if required May require recompilation depending on platform changes e.g. new OS. Source code is unavailable. Worst case: SAS macros compiled with the NOSOURCE option Other Actions conform to current policies WORK library implicitly referenced Actions not compliant WORK library explicitly referenced Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.

114 CODE MIGRATION OPTIMISING CODE FOR GRID Consider refactoring for parallelism The SAS code analysis task can perform refactoring for you Be aware of temporary file locations / dependencies when running in parallel Consider using the USER libname assignment as a "hack" Copyr i g ht 2012, SAS Ins titut e Inc. All rights res er ve d.