Help with running Catalog Programs in SAS EG.

[DanielP91]

My work has several ‘panel’ programs that currently need to be run from BASE SAS. The specific program I am trying to run contains a list of FRAME and SCL types. I have been delegated a project where those panel programs need to be run on SAS EG for user accessibility (we are trying to move users away from BASE SAS). The code below is what I use to call the catalog program in SAS EG.

Libname essplib "E:\Users\Daniel Paredes\Mydata";

proc display catalog=essplib.Pan01.Main.Frame;

run;

When I run the code above, I get the error below.

ERROR: Cannot allocate window.

NOTE: Cannot open entry AF.AFGO for write access - catalog SASUSER.PROFILE is opened for read access.

Any help or suggestions I can get with this would be greatly appreciated. 

[Patrick]

Ooops.... You're migrating from a single server local environment (PC SAS) with a windowing system (SAS Display Manager) sitting directly on the local SAS server to a client-server architecture. 

I've seen a "PC SAS" based application using SAS AF the last time like 20 years ago. There is no migration path because both technology and architecture are so different. I fear for whatever requirements you have to address a full re-design and re-build will be required.

[AlanC]

Patrick is correct. SCL/AF is last century. It is a way to bring up a Window display in the old SAS DMS editor. It is old, old school SAS.

EG is a C#/.NET application. You can create dialogues in it using custom EG tasks. They are simply C# code implementing a few interfaces. Chris Hemendinger has numerous examples.

However, I suggest just pulling the parameters out of a window and putting them into some macro vars at the top of the code. Not worth building a UI part unless it is very complex.

[Patrick]

And to add to what @AlanC wrote:

To come-up with something future-proof you also don't use EG as beginning with Viya 4.x there isn't any EG anymore but just SAS Studio.

[andreas_lds]

@Patrick pointed it out already: migrating old stuff to Enterprise Guide or Stored Process is not wise, because both environments don't exist in the recent version of SAS Viya any more.

[AlanC]

A lot of customers don't use Viya and have no plans to do so. If Viya is part of their path, agreed, but it may not be. 

[Kurt_Bremser]

---

@andreas_lds wrote:

@Patrick pointed it out already: migrating old stuff to Enterprise Guide or Stored Process is not wise, because both environments don't exist in the recent version of SAS Viya any more.

---

Which means that Viya is completely useless for a VERY large part of SAS customers, including my former employer.

[andreas_lds]

---

@Kurt_Bremser wrote:

---

@andreas_lds wrote:

@Patrick pointed it out already: migrating old stuff to Enterprise Guide or Stored Process is not wise, because both environments don't exist in the recent version of SAS Viya any more.

---

Which means that Viya is completely useless for a VERY large part of SAS customers, including my former employer.

---

Sad, but true.

[DanielP91]

@andreas_lds @Kurt_Bremser @AlanC @Patrick 

Hi All, 

Appreciate your advice and all your suggestions. Unfortunately, my company has no plans to use Viya so that won't be an option. It seems like the best solution would probably be to re-build those programs. Would I re-build/design those programs in EG as that is the application we currently use? How would you recommend I build those panel programs? Could I possibly create a Stored Process, and deploy it in a web app? 

Trying to find the most efficient way forward before I tackle this project. 

Thanks. 

[AlanC]

It depends on complexity. .NET is the best, IMO, because it supports very rich window controls, is what EG is written in, and you can create custom EG tasks. I have built very complex controls in EG using C#. Your skills and needs may be different.

[Kurt_Bremser]

If you have the necessary prerequisites to develop and run stored processes (client/server setup, metadata and web application server), then you should go this way. Users will only need a browser to access the STPs.

[SASKiwi]

@AllanBowe has a solution for converting legacy SAS/AF applications.

Worth checking out if you want to save yourself some effort. I'll let him supply the details...

[Patrick]

---

@andreas_lds wrote:

---

@Kurt_Bremser wrote:

---

@andreas_lds wrote:

@Patrick pointed it out already: migrating old stuff to Enterprise Guide or Stored Process is not wise, because both environments don't exist in the recent version of SAS Viya any more.

---

Which means that Viya is completely useless for a VERY large part of SAS customers, including my former employer.

---

Sad, but true.

---

I don't really want to sidetrap the OP's question but just can't let these comments stand without reply. 

Yes, I agree that getting a Viya version on a level where it's a full replacement of SAS 9.x certainly took/takes SAS a "bit" longer than anyone would have wished for. But SAS Viya is getting there and it's the future of SAS and for this reason I believe anyone designing new applications under SAS 9.x needs to consider the migration path to SAS Viya to not create technical debt. 

[AllanBowe]

Thanks @SASKiwi for the tag.

Indeed there IS a migration path for AF / SCL and it is - SAS Powered Web Apps.  Whilst @AlanC is right, it's not worth it if you can just create some parameterised jobs, I would put forward that it's really not that hard - especially if you use a framework, such as the one my team have built, namely SASjs.

Using this (open source) approach you can build a web app using traditional Base SAS and deploy it to both SAS 9 EBI (with Stored Processes) and SAS Viya (Jobs) with next-to-zero additional effort.

To re-iterate that once again - you can build an app with SASjs and have it run on ANY platform, be that traditional Base SAS, SAS 9, or SAS Viya.

I'd be happy to provide free advice, we have a bunch of seed apps to speed this process up:  https://github.com/search?q=topic%3Asasjs-app+org%3Asasjs+fork%3Atrue

You can also engage our team to just fix it for you:  https://sasapps.io. We're damned fast when it comes to building web apps on SAS because that is literally, all we do!  Right now we're just wrapping up a major AF/SCL modernisation for a government customer.