BookmarkSubscribeRSS Feed
Renganathan
Calcite | Level 5
This question is pertaining to the communication between SAS EG client / Metadata server. This is more for my understanding. Let us consider that we are developing a project in SAS Enterprose Guide which accesses a dataset in a permanent library (let us call this library reference as ABC and exists in a UNIX server). The libref has already been defined in Metadata server using Management Console. After the completion of development, we take the package of the EG project; then we are heading to schedule the package in CRON using SAS command in UNIX server. When we generate the package of the project in EG, a META library reference is created (for ABC) in the code generated by EG as below. libname ABC meta repname='Foundation' liburi="SASLibrary?* [@Name='My_Library_Reference'][DeployedComponent/ServerContext[@Name='SASMeta']]"; I understand 'My_Library_Reference' is the description of the library reference 'ABC' (given at the time of creation). Note: Development/Production areas are defined in different physical servers. And the complete suite of BI/DI SAS products have been installed in the UNIX servers side. And the GRID functionality as well. Now when the SAS command starts to be executed (via CRON tab), first it has to communicate to the Meta data server in order to process the above libname statement. The libname statement contains just the label (SASMeta) of the server. It does not have any IP address / port number. In this case, how the program will execute successfully by communicating with the Metadata server ? (Do we need to alter the code in the package before placing in the prod area ?) After the program is able to communicate with the Meta server (for the libname processing), then the code has to be executed in GRID environment. What if the work space server is in a different machine than the one which is invoking the program ? I examined the code; and it does not seems to have any sort of indicators that it needs to be run in a GRID environment. How all the above are achieved ? And similarly how the code acquires the knowledge that it has to speak with the Object Spawner ? Can you please help me to understand the events happing behind the screen when the program is getting executed ? Thanks, Renganathan M.
4 REPLIES 4
ChrisHemedinger
Community Manager

Hi @Renganathan,

 

When running in batch, you need to specify a series of META* options that tell the SAS session how to find the metadata server.  METASERVER, METAPORT, METAUSER, and METAPASS are for the connection info and credentials.  These can be specified on the SAS command, in a config file, or in a separate METAPROFILE file. See more details here.

 

Moving this to the admin board -- folks there might have further ideas for you.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
SASKiwi
PROC Star

One option to have your SMC-defined SAS LIBNAMES to be available automatically in all environments, is to assign them all using the native engine option instead of the metadata one.

 

If you then also pre-assign them, then it doesn't matter what SAS environment you run your programs in: EG, SAS/Studio, batch and so on then the LIBNAMES will be defined at start-up without any extra configuring. We use this approach ourselves and it works like a charm.

 

Renganathan
Calcite | Level 5
Thanks SASKiwi!! Actually I would like to migrate the code generated by EG to production, where EG will not be installed; but the promoted code will be scheduled in CRON. I would need to understand how things will work behind the scenes to achieve the job. Thanks!!
SASKiwi
PROC Star

We work in a similar fashion. We develop code in EG and then schedule this to run in batch mode on our SAS server using LSF. We are reliant on our SMC-defined libraries to be available identically in EG and batch. This works with pre-assigned native-engine libraries and there is no setup difference between EG and batch - our code is identical.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 4 replies
  • 1508 views
  • 0 likes
  • 3 in conversation