It sounds like there is something wrong with the email config for the SAS Metadata Server. Talk your your email server admin about the settings you should be using: SMTP server hostname, port, any TLS and authentication requirements etc.   I would check the following: correct hostname correct port number any firewall config that is preventing your SAS metadata server from connecting to the SMTP server. whether the SMTP server supports unauthenticated connections and if not check the user id and password you are using for SMTP authentication. For more information on the various configuration options available look at the Reference Information for omaconfig.xml section of the SAS 9.4 Intelligence Platform: System Administration Guide. ... View more

  Since you mentioned that the SAS datasets are huge, I might also ask if you have considered whether this method of providing additional storage space will provide adequate performance for your SAS users? It would be well worth testing before rolling it out. If you haven't already seen them, I'd recommend reading the following papers (and the associated resources mentioned within them): SAS Global Forum Paper SAS6761-2016: Best Practices for Configuring Your I/O Subsystem for SAS®9 Applications by Tony Brown and Margaret Crevar. SAS Global Forum Paper SAS6201-2016: How to Maintain Happy SAS®9 Users by Margaret Crevar Of course another consideration is to see if your users can take advantage of general SAS programming techniques to reduce the storage footprint for their SAS tables (appropriate variable lengths, compress option, etc). ... View more

I would agree with @JuanS_OCS in that if the information you need is readily available in those Platform Process Manager / LSF files then I would choose that method. Pulling basic attributes out of metadata using the SAS Open Metadata Interface is reasonably straightforward, but once you have to start chasing object associations, if gets complex very quickly. The SAS metadata model is fine grained and rich but it's a very steep learning curve and I wouldn't underestimate the amount of time/effort required to go beyond simple queries. ... View more

It will, at least in part, be based on what you mean by "should not have login access over those SAS Servers". Is it one of the following, or something else?: Should not not be able to run any process on the server using their own operating system/domain/directory identity? If so then those SAS processes that normally run using their own identity might be configured to run using a service identity instead (e.g. SAS Token Authentication for SAS Workspace servers). Of course this also limits your ability to restrict access to operating system resources based on the requesting identity. You will have to rely more on metadata access controls instead. Can run SAS processes on the server using their own identity but are limited in their ability to directly access operating system and 3rd party commands/facilities. If this is the case then you could look into things like xcmd and lockdown. Should not have direct console, RDP, SSH access to the server using their own identity, but can run SAS processes on the server using their own identity and may/may not be limited via xcmd/lockdown etc. In this case you might look into using directory/operating system facilities, sshd_config options etc to limit direct login access. ... View more

I wrote a short presentation in 2007 about Metadata Reporting with SAS Software that included a couple of sample programs that use SAS proc metadata to query metadata, read the XML response into a SAS table, using the SAS XML Libname Engine (SXLE), that can then be used in SAS reports. That might help you get started. You might also notice the presentation included a couple of screenshots showing sample reports on jobs.   For more information on metadata reporting see the SAS documentation, specifically: SAS 9.4 Language Interfaces to Metadata SAS 9.4 Open Metadata Interface: Reference and Usage SAS 9.4 Metadata Model: Reference ... View more

In your example I would use option 1 as it can utilize an index on the city variable in dataset a (if such an index exists and would be beneficial). There are several articles on the differences between where and if and with more complex scenarios. A nice short one to get you started is SAS Usage Note 24286: When do I use a WHERE statement instead of an IF statement to subset a data set?   Personally I use where where I can and if if I have to 🙂 ... View more

Thanks Juan for mentioning Metacoda Plug-ins.   I might also add that the Metacoda ACT Reviewer is one of the plug-ins that is available free-of-charge. As well as interactively showing the objects to which ACTs are applied it can also be used to export an HTML report as documentation for ACTs - how they are defined, where they have been applied, and how they have been protected. ... View more

As long as Machine A and Machine B are either in the same Windows domain or are in domains that have a trust relationship, then you should be able to configure IWA. For more info on potential limitations have a look at the Integrated Windows Authentication section of the SAS 9.4 Intelligence Platform: Security Administration Guide. If the Windows side of things has been configured ok then some of the other common things that can prevent IWA logins working as expected include: Not configuring the SAS Workspace Server in metadata (using SAS Management Console) to support IWA (via Negotiate or Kerberos). Not restarting (or refreshing) the SAS Object Spawner after changing the SAS Workspace Server config in metadata. No registering appropriate SPNs if the SAS servers are accessed using machine aliases rather than their primary host names. When implementing IWA, it is well worth considering getting help from SAS Professional Services or a local SAS Partner. When IWA is operational it works very well, but making sure all the various platform components are configured correctly for IWA can tricky, time consuming and involve lots of troubleshooting. Getting help from someone that already has this experience can save you a lot of time. ... View more

Another benefit to registering tables in metadata, so that they can be used by metadata centric applications like SAS Data Integration Studio etc, is to be able to answer lineage questions - such as where is this table used downstream and where does it come from upstream. Features such as SAS DI Studio Impact Analysis, the BI Lineage Plug-in and the Relationship Reporting Tools all rely on metadata to be able to provide these valuable insights.   Of course once they are registered in metadata they need to be maintained in metadata (such as updating metadata when the table structure changes). For this reason, if you are not using metadata centric applications, and do not need the various benefits already mentioned in this thread, you may decide not to register them in metadata. For example some sites may have some free-for-all libraries for SAS Enterprise Guide users where the turnover in tables and table structures is so high that, given those tables might only be used by those EG users, the administrators avoid the overhead of maintaining metadata registrations for those tables. ... View more