topic Re: Poll: EG for programmers or not? in SAS Enterprise Guide

Poll: EG for programmers or not?

ChrisNZ — Thu, 12 Aug 2010 23:34:45 GMT

Hi,

I am unsure this is the right place for this, but I am just back from the SAS Forum in Sydney and am all wound up again. So I am curious to see what you guys think.

=>What on earth pushes sas to want programmers to use EG?

=>How can they believe that populations as different as end users and coders have similar needs and should use the same tool?

EG's code window is cramped, and it doesn't even have line numbers for goodness' sake! How am I supposed to efficiently fit my 1000- or 2000- lines programs in that tiny crippled space?

While it is very nice to be able to see a process flow, and EG does offer some pluses, it has many shortcomings over the DMS, which is not that great to start with.

To name some of the most obvious that came to mind, in no particular order (this might have marginally improved in the latest version of EG I haven't kept track):

-Data step debugger disabled (it should be overhauled instead)

-Either windows are way too small (especially table-browsing, code panes) due to more interface clutter, or impractical toggling of window size with ctrl-M

-Dataset-browsing pane: cannot run WHERE clauses or run SHOW command or hide/unhide variables or display one record at a time.

-Cannot toggle easily from 'Display Labels' to 'Display Column Names' (need to go to General Options) or change variable format

-Dataset Properties window is not resizeable and is tiny and does not indicate if dataset is sorted or what the index is or number of lines and columns or compression or date

-Cannot copy column names from properties/columns dialog (Drag'n'Drop would be even better)

-Library property does not indicate path

-No line numbering in code window

-Log window full of EG-related garbage: one-line statement submitted results in a 1-page log.

-Catalogs are hidden

-Cannot configure keys

-Server list pane not split explorer-like (libraries | tables)

-No access to OS (call system, x, %sysexec, pipes, named pipes) (so no MPconnect piping optimisation)

-and on and on

=>Why cripple an already limited coding interface? How can these shortcomings be seen as acceptable? Do sas Institute developpers use EG?

In the 2009 sasware ballot (I haven't looked at the 2010 one, nor have I bothered to check whether any of the requested features have been implemented), 3 of the top 4 *overall* items relate to application development and debugging:

1- assign line numbers to code seen in a log generated by a macro in order to correlate with any LINE:COL messages given at the bottom of a DATA Step

3- provide an option that enables you to turn off or on certain notes that are written to the SAS log; for example, notes about data set compression, invalid data, or invalid argument to a function

4- provide the functionality to stop a SAS process in interactive mode exactly as the ERRORABEND option stops a process in batch mode - immediately stop the process upon error, produce a log, and not terminate the session

How that kind of wishes fits with EG I can't imagine.

On the other hand, the DMS is outdated too, lacks many features users have requested for years (like the ballot's macro-line log-numbering/debugging), and also lacks tools other IDEs have had for many years, like good color coding, predictive typing, drag and drop debugging, source code management (both to retrieve older version of the code and to share code), etc.

So I agree the DMS needs to go, and why not a java applet connected to a server if that is the way sas wants things to go. But not an applet with even fewer features than the poor old DMS!

My opinion is that the "SAS Enterprise IDE" java interface is long overdue, that coders need it badly, and that sas is on the wrong track trying to push them to use EG. I might not be alone thinking that seeing that sas is still pushing many years later.

=>What do you think?

So 4 sets of questions here (including for sas). I am curious to see comments/reactions. Thanks.

Re: Poll: EG for programmers or not?

SASKiwi — Fri, 13 Aug 2010 00:21:03 GMT

I don't use EG much so I won't comment on editor differences between EG and DMS.

What I would like to say is that where I work, we continue to use full SAS on our desktops even though we primarily use a Windows SAS server. Why is this? One of the important reasons is that there is NO DR (Disaster Recovery) plan for our SAS server. If for any reason it is not available we retain the capability of running our business-critical processes from our desktops (after our data is restored on a file server) so at least we have some minimal DR/backup capability. All our programs are written with this flexibility in mind. I wonder how many SAS sites are in the same boat? If your SAS server has no DR or backup and you only use EG - tough, you have no alternative!

BTW I use DMS line numbers all the time as a very useful productivity aid.

Re: Poll: EG for programmers or not?

Doc_Duke — Fri, 13 Aug 2010 13:16:35 GMT

Chris,

Your "poll" reads more like a "rant."

I've never used the DMS editor and use the EG editor mostly for viewing. Having grown up in TSO and then UNIX, I became comfortable with external editors and never bothered to switch. I now use EMACS on both the Unix and the PC for primary editing. I run mostly in batch, even in the EG interface, due to large data volume.

EG 4.3 does seem to have lot of changes to help programmer productivity. With any luck we'll be able to get our hands on it in a week or so.

One of the features that I find really helpful in EGuide is the process flow. The ability to link things together and to run the process flows is a great benefit. We have about 20 SAS programmers in our shop (and another 40 statisticians), so the documentation that it provides can be very helpful. Both you and SASKiwi likely have good ways to document your work, but the a hand-off between the two of you might involve a fair learning curve on the process.

SASKiwi's challenge is really a local decision. Disaster recovery processes are in the realm of risk-based management decisions that, of necessity, also include a cost-benefit analysis.

Doc Muhlbaier
Duke

Re: Poll: EG for programmers or not?

SAS_Doctor — Fri, 13 Aug 2010 13:57:54 GMT

Rant or not he's right. All of the SAS editors are in need of upgrades. I just started in a new shop that uses EG 4.2 and the editor is not making SAS look good in the user base. They are hurting themselves by not making drastic changes. Programmers have been complainging about this for years. And programmers are the ones that sell the product for them. GET WITH IT SAS!!! Make it more like the Eclipse or visual studio type environment... Please.

Re: Poll: EG for programmers or not?

nrose — Fri, 13 Aug 2010 22:29:15 GMT

Hi,

I am a programmer, both SAS programmer and other high level computer languages.

I love SAS EG. I have a two screen set up, and this is a very efficient set up to make the most out of SAS EG. It sounds like you have picked out all the negatives of SAS EG, but since moving over (voluntarily), I have never looked back. Sure, it is buggy, it has shortcomings, but the improvement coming up for coders in SAS EG 4.3 look great. I work in a business environment where not everyone is experienced at using SAS. I have to work in the same environment as end users to make it easy to accomodate their needs rather than mine. As programmers, we have to stop living inside our high horse shell.

You have to put it in context - name me another statistical package that offers the features, flexibility and customisation (e.g. custom tasks) that SAS EG offers? And I am not sure why you are writing 1000 to 2000 line SAS programs? Sounds like you should be modulating your code a bit better - which is what EG encourages.

NIck

Re: Poll: EG for programmers or not?

ChrisNZ — Sat, 14 Aug 2010 04:08:03 GMT

Yeah, Duke, maybe it is a rant, but I feel strongly about it, and I made clear I was expressing my opinion and was asking for feedback.

The messenger (me) is not what matters here in any case, let's discuss the message.

The points you make about the message are valid, but limited:
- yes seeing the process flow very good, and the hand-over will be easier with EG
- yes the DMS is better than emacs or vi. But how good an environment is that? JimBaillie's Eclipse or visual studio environment examples are worlds ahead. How much productivity would you gain by having an efficient IDE?

My other points stand: EG lacks these useful, no, fundamental programming features, not to mention those available in modern IDEs

I am starting to have a feeling that *maybe* the difference between coders satisfied with EG and those not possibly satisfied might be down to the complexity of the code (please don't take this personally, it is just an hypothesis).

My n000-line code typically :
- merges several years of monthly detail tables in a view (deriving things like how many of x happens in the next y months after the current month),
- summarises the view,
- adds various bit of infomation,
- then *for each* line of the summary table:
- more data can optionally be retrieved,
- annotation data is created for each graph
- tooltip data is added for each graph
- a bunch of graphics are created in an html page with funny names for the pages and the individual image files, which also have to be derived before-hand.

All this is encapsulated and controlled by macros defining date spans, table versions and the such. The code is modular in the sense that i try to put each processing step (say graphA with its specific data transformations, axes and legend parameter definition, annotate and tooltip creation, then the final plots) in a macro, in turn called from higher-level macros.

But the whole reporting program is one whole, and cannot meaningfully be broken into independent bits. And as you can imagine, it takes time before it runs successfully.

If you know in advance what data you are going to process, what parameters you will delimit it with or break it down by, don't need macro code to process special cases, don't create annotations and the such, don't access the OS, don't need to debug complex data steps at times, don't care about combining steps to speed up the overall process, then EG might be workable or even better than the DMS.

In my case, EG would drive me mad (and halve and more my productivity) with all the hoops it would put in my way just to do extremely basic stuff like display only a couple of a dataset's variables with a where clause applied, or find where the hell my graphA macro is in the program, plus all the other things I mentionned.

Re: Poll: EG for programmers or not?

ChrisHemedinger — Sat, 14 Aug 2010 07:01:45 GMT

Chris,

It was good to meet you in person at the SAS Forum in Australia. I was glad for the opportunity to speak with you about your concerns, even though I realize that you have yet to decide to add SAS Enterprise Guide to your own personal SAS toolbox. The format of SAS Forum in Sydney did not allow me to show a demo. Did you take advantage of the hands-on EG 4.3 session provided by SAS Education during the conference?

I've had the chance to speak to hundreds of SAS users here in the region (and I'll visit many more in the coming week). Most are very excited about the new features that are coming in SAS Enterprise Guide, especially for programmers.

It is a different environment than what you are accustomed to, and I know from our previous discussions that you would prefer an Eclipse-based solution. However, that is not the direction that we're taking SAS Enterprise Guide, whose primary audience includes business analysts, as well as programmers and statisticians.

EG does support line numbers, of course, as well as many other standard program editor type features. You can explore these in the Tools->Editor Options and also the Editor macros/commands features. You can easily maximize the EG program window with Ctrl+M to increase your workspace.

You do present some valuable ideas for additional features that SAS programmers can use to be more productive, and I appreciate that. Please keep the constructive suggestions coming.

Still Down Under,
Chris

Re: Poll: EG for programmers or not?

ChrisHemedinger — Sat, 14 Aug 2010 07:13:37 GMT

Jim,

Check out this paper to see how the development team *has* made strides towards making EG more like Visual Studio, especially within the program editor:

http://support.sas.com/resources/papers/proceedings10/137-2010.pdf

Chris

Re: Poll: EG for programmers or not?

nrose — Sat, 14 Aug 2010 08:36:04 GMT

Sorry Chris,

It is hard to take your criticisms seriously when you consider what you describe a 'complex' program, and when you abstract your program into the steps you have, and not say that you can't modularize it. I hope your program is seperated into seperate SAS files, otherwise, go back to programming 101.

Do yourself a favour - learn how to use SAS EG, create a process flow for each of the steps in your program, and, within each process flow, build up your program using tasks or your own code, create an ordered list to run the program, and then see how easy it is to debug. You will find that being able to see your datafiles created for each step easy to keep track of, that the individual log windows for each step allows you to isolate errors, and if you ever have to go back to it in the future, how the visual representation of your program makes understanding it easier. And, if you know any .NET programming, create your own custom tasks, and see how user friendly your programs can become for others. It is precisely for serious programming, that users should adopt EG.

Nick

Re: Poll: EG for programmers or not?

ChrisNZ — Sat, 14 Aug 2010 09:19:38 GMT

Hi Chris,

Nice talking to you indeed. I spent less than 20 hours in SYD and had to leave early to be back in AKL on Friday, and I only managed to use Add-on for office and dataflux, so I still have to catch up on some of the upcoming EG features.

Do you think my hunch that EG is good if the processes involve fixed input data, few changing parameters, and a fixed sequence of procedures and sql?
And if the power of macros is required (either for variability/parameterisation or automation), if data steps are used (and all the efficiency that comes with them: multiple output datasets, hash tables, arrays, etc), or some other features like OS access or MP connect, then EG is very limiting.

Note that this does not describe the comfort of doing development-related things like checking the data in a table or looking up a catalog's contents.

Re: Poll: EG for programmers or not?

ChrisNZ — Sat, 14 Aug 2010 10:10:38 GMT

Hi nrose,

Thanks for your input. Don't be too hasty in judging me please, I know EG quite well actually (which why I can list what I think is not adapted to advanced developers compared to the DMS which I also know well), having been responsible for supporting the company's metadata server and the EG environment, users and data sources in a previous life. The program described does simple enough things (after all how complex can a single step get?), it is how all is linked together that makes the complexity. Each step is often short (though the merge statement alone would be 1k lines for 5 years' worth of data, and the merge data step over 20k lines if not coded via macro loops, think about it: loops are 60 observation months times 24 months to look at), but what the steps do/are is not always known in advance, depending on the data. Speed is also a major consideration for this kind of volume, and imposes choices where ease of development/simplicity is sacrificed. It would be *a lot* easier to develop and maintain each report separately, but it would take several hours instead of a few minutes to run them all.

Anyways, once again, let's try to stick to the points raised.

You are right, giving EG to statisticians who can then create processes without having to code is excellent.

This is a crowd different than developers who know all the tools sas offers, and have to create efficient applications. Typically, the latter will provide the statisticians with their cleansed, consolidated, coherent, easy-to-use EG data in fact.

2 crowds, 2 sets of skills, 2 tools. I don't expect said statisticians to write data steps, and I don't like developers to use a tool where many useful features are missing whereas they have been asking for extra ones for some time now. Message was edited by: Chris@NewZealand

Re: Poll: EG for programmers or not?

Peter_C — Sat, 14 Aug 2010 10:56:45 GMT

Hi Nick/Chris

in responses to the 4 questions
Q1=>What on earth pushes sas to want programmers to use EG?

my A1
it might be more manageable to build a new IDE than re-devevelop the old one.

Q2=>How can they believe that populations as different as end users and coders have similar needs and should use the same tool?

my A2
excel serves all sorts of people even through the transition to office 2007, so why should SAS Enterprise Guide (EG) not serve a diverse audience

Q3=>Why cripple an already limited coding interface? How can these shortcomings be seen as acceptable? Do sas Institute developpers use EG?
my A3
specifically that is what they are not doing, by creating EG as something new

Q4=>What do you think?

my A4
I hope my prejudices are not based on anything like a "first love" of my first SAS environments 😉 That was old SAS on a mainframe before display manager (DM). When new, DM came with its own particular difficulties (very much needing the "-altlog" feature to help discover where it had broken and destroyed my log 😉 but sadly that altlog option didn't turn up until SAS6 through which all the SAS software improved greatly. Switching to DM from my own contrived user-interface+batch-SAS came through time and the attraction of some of the peculiar benefits of that platform. For me now, switching to SAS Enterprise Guide (EG) has not been so quick nor eager - for a range of reasons.
For now "anything that gets the job done" is a satisfactory environment.
Highlighting one of Nick's points if you know any .NET programming, create your own custom tasks, and see how user friendly your programs can become for others. It is precisely for serious programming, that users should adopt. I was able to apply my base SAS knowledge to extend SAS DI studio for the benefit of others. With SAS/AF I was able to extend the effectiveness of SAS Display Manager for may benefit and the benefit of others. Even without SAS/AF, the SAS Explorer interface is able to be extended to be more effective for others.
So now it seems to step forward to the (no longer new) SAS Enterprise Guide world, I have to take some backward steps to learn .net (or maybe java? ) so that it cann achive the basics I expect of wizards in EG - like building an informat where I can set special missing values for dates = like "age not admitted" or "?" or 00/00/00 - which was my first ajor disappointment in EG - that the (weak) customising of code generated by wizards, left me back in a code window

so now it's back to class - to learn a nerw language - to re-establish my relationship with SAS development in the new environments - (remembering that just like we need batch to be available still, I think we can hope always to be able to run fat SAS clients for data step debugger

Re: Poll: EG for programmers or not?

twocanbazza — Sun, 15 Aug 2010 21:55:03 GMT

Hi Chris.

"and it doesn't even have line numbers for goodness' sake!"

ummmm yes it does, you can turn them on....

"-No access to OS (call system, x, %sysexec, pipes, named pipes)

Ummmm yes you do, this can be set, just happens to be set to off by default...

-Library property does not indicate path

Ummmm depends on how and where the library is assigned (why do you as a programmer need to know this anyway? I know I'll get some comments about this one 😉 )....

Don't get me wrong I agree with you in certain cases but some (above) of your rants relate to how your system has been set up and administered rather than the functionality of the tool. Learn the tool, look outside the old programmers mindset, just cause you could do it in old school SAS doesn't mean it is right.

There are a few issues relating to the quality of the GUI ie window re-sizing etc but SAS will get this right in future releases

Bring on 4.3

Cheers

Barry

Message was edited by: twocanbazza Message was edited by: twocanbazza

Re: Poll: EG for programmers or not?

ChrisHemedinger — Mon, 16 Aug 2010 02:06:15 GMT

Chris @ NZ,

None of the capabilities that you mention are inherently limited in SAS Enterprise Guide. We have many customers who use EG with Grid Computing (MP Connect), use parameters/prompts with programs, and access all of the power of the DATA step via their own programs.

I've published blog posts that describe how to enable system commands and view SAS catalogs using SAS Enterprise Guide; it requires just a few tweaks to get to these features, which aren't needed by everyone but that might be missed by long-time display manager users.

Chris @ SAS

Re: Poll: EG for programmers or not?

Robert_Bardos — Mon, 16 Aug 2010 05:45:48 GMT

quote on
... just cause you could do it in old school SAS doesn't mean it is right.
quote off

Similarly: just cause you can't do it anymore in new school SAS doesn't mean it is/was wrong or less productive.

Still loving the 3270 type editors where it's been just these last days that I brought a "wow, I didn't even think about such a possibility" expression on the face of one of our younger (than me) programmers. Later on I realized that his astonishment was due to the Windows based mindset he had come to adopt earlier in his career.

Robert

Re: Poll: EG for programmers or not?

Patrick — Mon, 16 Aug 2010 10:46:05 GMT

Hi Chris

What made me use EG as coding interface was the possibility to reset an environment simply by disconnecting/connecting to the server. No more closing everything only because there was some unbalanced quotation mark in the code.

Talking about EG 4.2:

I agree with you that EG still let's a few wishes open - others can be solved by undoing the default preferences (i.e. NOT to open a data set when added to the project).

There are also these little things like that I can't choose in a stacked window where the code window goes and where the log - and that I first have to run the code before stacking is possible. I sure prefer the old DMS in this regard. Also toggling between windows is rather cumbersome, there are no shortcuts (or they are not intuitive).

There are just still too many things which need too many clicks:
I.e. creating a new code node: Program is not such a good name. But I first have to open it this way (no prompt giving me the possibility right away to give a catchy name) and then go to the process flow tree, click carefully on the name - and then I can change it. A lot of people don't bother doing this and then get lost in Program to Program100.

I also agree with you that debugging capabilities are rather limited. I strongly hope that EG will get some inspiration from what has been done in SAS DIS 4.2.

Little annoying and missing things like this are many more in SAS EG (i.e. trying to save EG code in a PDS member) - which makes new releases always exciting.

But then look at all the advantages EG has to offer. I.e. if I analyse some data and want to deliver the result as Excel then I wouldn't even think about using "PC SAS".

I'm actually right now working for a customer where I try to convince them to use EG instead of PC SAS and rsubmit.
It's not that easy as people always see first what they loose. Still: I think overall EG is the better choice and I can't wait that EG 4.3 brings changes which make it even more attractive for coders.

Cheers
Patrick

Re: Poll: EG for programmers or not?

darrylovia — Mon, 16 Aug 2010 14:49:01 GMT

As an old school SAS programmer, when we went to EG i didn't like it. But after using it for about 3 years, it is starting to growing on me. Remember EG is just an interface to a server side installation of the SAS System.

Pluses
1) easy to make a stored process that other applications can use. .NET etc.
2) the point/click wizards generate code in the SAS log so I can see what the heck SAS GRAPH is doing 😉
3) you can still code old school with %includes and not use tasks or link code if you choose.

Cons
-1) OS commands are disabled no more X cmd ;(. But there are work arounds, ? Luckily it is possible to run external DLLs from SAS under Windows by using the SASCBTBL Attribute table and MODULE family of call routines and functions.
-2) Running batch needs to be done on the server, so getting the network adminstrators attention can be fun (not).
-3) DDE doesn't work. There is no way that I know of to code around this.

For me as a developer having the same tool as the user, gives me insite into what the user needs.

Darryl

Re: Poll: EG for programmers or not?

ChrisNZ — Tue, 17 Aug 2010 01:10:58 GMT

Hi everyone,

Good to see the discussion is getting more constructive.

I was afraid it would turn out to be like some Office 2007/2010 or Vista/W7 forum discussions where the proponents could only conclude: stop thinking/whining, get on with it, it is the future, move on. There is a fair share of that, but there are also good real-life comments; thanks all for the good points raised and experiences shared.

>excel serves all sorts of people even through the transition to office 2007, so why should SAS Enterprise Guide (EG) not serve a diverse audience

Yes, except excel has everything an excel wiz needs, and then people can use it as a photo holder if they want. Not so here. SAS didn't start with best-in-class IDE and added a GUI-for-end-users on top, they started with an end-user app, and are trying to gear it towards programmers.

> DDE doesn't work. There is no way that I know of to code around this.

Have you tried writing out a VB file?
Users then load an empty excel sheet that you always keep there and that just points to the VB file, and excel is your slave. I did this pre-office 2007 so users would load a CSV file from the sas web reports and excel would present them with a pivot table. Unsure about newer excel versions' behaviour.

> None of the capabilities that you mention are inherently limited in SAS Enterprise Guide.

It seems to me that many still are, Chris.
Some restrictions in my list seem to have been lifted, or there might be workarounds, but many also remain, and many others exist, as pointed out by Patrick or darrylovia for eg.

In any case, wide gaps exist compared to real IDEs (source code management and graphical debugging are my main 2) and compared to what users requested (cf sasware ballot 2009: macro line numbers, etc).

Simple things like a log summary at the end of a run (how many errors, warnings, of what type?) are also missing. One doesn't need this in simple EG projects as each step has its own log. But in my world, if a macro runs a bunch of steps 200 times, and some generate funny messages, it should be a lot easier to track down.

> you can still code old school with %includes and not use tasks or link code if you choose.

Yes, this is good when one has well-behaved, optimised code. Getting there in EG might be the pain.

I suppose my main issue is that I seldom use procedures (except for deriving stats), as the bulk of my work is data processing, and this is mostly done in data steps where I can get the efficiency of features like hash tables, arrays, funny merges, macros, multiples outputs, row delete or duplication, etc.

Incidentally, this is also what I was doing when I was feeding tables for my EG users in my previous life.
By then, the data was denormalised, clean, and complete and they could use SQL and procedures and build easy-to-follow EG processes.
Do you guys know where your EG tables come from?

And when I do use procedures these days (mostly to create graphs), they are always heavily customised, so no point-and-click here either.

I have learnt more good things EG *can* do, like using the MODULE* functions or packaging processes in .NET containers, and I reckon process legibility and ease of handover are important pluses. But so far, probably because of the type of work i do, it still seems that if I have to use EG some day to do what I am doing now, my karma, morale and productivity will take a huge hit. Please keep the comments coming, both for and against EG for programmers.

Re: Poll: EG for programmers or not?

darrylovia — Tue, 17 Aug 2010 13:17:33 GMT

Great thread.

The place where I consult only uses SAS Enterprise Guide 4.1 on the desk top and has 9.1.3 on the server side. SAS is used to get data from a variety of sources, Oracle DB, SQL Server, MS/Access, and a plethora of legacy flat files.

I mostly use SAS to create the SAS datamarts from those data sources. We use SAS EG for heavy data processing work and use the Code window for the vast majority of the processes.

Also, it is very convient for the non-programmer to have a link to the SAS Datamart, Oracle DB, and SQL Db and join away in a single application, versus toggling through TOAD, etc.

So with the same tool, I (the developer) uses SAS EG mostly for ETL work. While the operations research staff uses it to run analysis (statistical analysis, reporting, etc.). One cool feature is the use of macro parameters. With a simple drop down the analysts can run a variety of scenarios without coding a single peice of code.

As I mentioned before using the same interface as the end-users makes my life as a developer a bit easier.

Darryl

Re: Poll: EG for programmers or not?

Franco — Wed, 18 Aug 2010 04:07:33 GMT

The transition from SAS DMS to EG is not always easy, especially for Programmers/Developers who, through the years, have stretched the programming interface options and coding possibilities of SAS on the DMS environment (whether on Windows, Mainframe or Unix).

I know of some colleagues who still resist the passage to EG and insist on keeping a SAS/Desktop licence. For how long, who knows. The extra licensing cost will eventually work as a deterrent for them (and for the manager who pays the software bills). Some SAS sites do not use the DMS at all anymore, let alone SAS/CONNECT, so it's becoming a matter of 'adapting to EG or else' in many cases.

Having used SAS DMS for more than 15 years and EG for the last 3, I can relate to some of the challenges mentioned by Chris@NZ. I must say however, that I tend to use the DMS less and less, to the point that I spend most of my working day on EG. You get used to it. Like for every new software tool or interface, it requires adaptation and a mindset change.

For a start, Code Nodes in EG must preferably contain short chunks of SAS code instead of 1,000's of lines. The modular nature of EG allows for smooth code section sequencing, based on functional output. You can execute the lot or partially, at will. If you want the whole lot compiled into one big piece of code, EG does it for you under the 'File' -> 'Export All Code' option.

The lines on the Code Node Program Editor can be activated from the 'Tools' -> 'Options' -> 'SAS Programs' -> 'Editor Options' (button). However, no line-command editing 'a la ISPF' possble. Oh, well...

If you want to copy/paste a list of variables from a dataset, the quickest way is to do a 'Data' -> 'Dataset Attributes' an then pick them from either the resulting dataset or HTML outputs. Opening the SASHELP.VCOLUMN view is another option, but very slow to query (especially if your site has hundreds of libraries and datasets).

Library paths can be obtained by submitting 'libname [libref-name] list;'

The 'X' system command seems to work only when invoking .BAT files from specific server drives (using Drive letters local to the server, and not the UNC path notation). Execution level permissions must be allowed on such drive(s).

I haven't used EG 4.2 extensively yet (let alone 4.3), so I won't comment on the new features just yet. But I'm sure the goal is to make it as developer-friendly as possible. SAS's direction is clear: server-based solutions and very thin clients. So EG is here to stay and it will keep evolving. The same cannot be said about DMS on SAS/Desktop. So, I'd suggest the sooner you move from DMS to EG the better.