@doug_sas wrote: Hard to say what the problem was.   Sometimes copy/paste from web to SAS does not translate the characters correctly.   Maybe it will work if you hand-type it instead of copy/paste.     Hmmmmm, that's quite possible!   Actually, I'm setting up this server for users who all know SAS better than me.  So, I guess none of them would ask a question like this to me; they should know what a session ID is.  Nevertheless, I'm the system administrator and have to make it look like I know something, in case they have problems connecting to the server.  That's why I'm a bit curious...  🙂    I think nothing else I can do other than to open it to the users and see if it also works for them...   Thank you for your help!   Ray       ... View more

@doug_sas wrote: The remote session ID is 'host' but it is also a macro variable which SAS/CONNECT should be able to use to get the spawner host and the spawner port.   The format would be something like   %let <remote_session_id_variable>=<host_spawner_is_running_on> <port_spawner_is_listening_on>; signon <remote_session_id_variable> username='<your_user_name>' password='<your_password>';   In the original case, the <remote_session_id_variable> was 'host'. ...     I see!  Thank you for the explanation!   Then, did I do something wrong when I typed in your original code.  Why did I get the error:   ERROR: Invalid or unspecified remote session ID. Set OPTIONS REMOTE=session_id.   Did it think that "host" was an invalid session ID?   Does that mean why I did was set the session ID to host and then "options remote=session_id" does some kind of rename of the session id?   Thank you for your help!   Ray         ... View more

@doug_sas wrote: Go to the machine that has the spawner running. It should have SAS and be licensed for SAS/CONNECT. Start SAS Run the following code: %let host=localhost 7551; signon host user='<your_user_id>' pwd='<your_pwd_on_host>'; signoff;   This will start SAS and run it as a SAS/CONNECT client to the spawner on the same machine using the default CONNECT server port.     Thank you for this, @doug_sas !  I know so little about SAS that I never would have figured out the above!   I gave it a try and I got the following error message:   ERROR: Invalid or unspecified remote session ID. Set OPTIONS REMOTE=session_id.   I looked around for help on the Internet and it seems a "options remote=test1234;" (for example) is needed.  After I added that as a line right after the "%let" line, it did seem to work.  I got "NOTE:  Remote signon to HOST commencing...".     So, I guess it worked?  Requiring the "options remote..." is not something I need to worry about, is there?   Thanks a lot!  (I had to start the spawner manually; I'll need to figure out how to get it to start automatically as a service...but I have the test I needed, so I know what to look for now.)  As I said above, sorry for the delay in replying...other work got my attention the past few weeks.  Now, I'm back on it...   Ray     ... View more

@SASKiwi wrote: Typically the SAS/Connect server also has to be up and running. Not sure how you check that on linux as we run Windows, maybe ps -ef.   Thank you for your reply!  Sorry for the delay in responding, but I started off by looking into alexal's comment and that stumped me as I am unable to start the SAS Management Console.  I was stuck on that a little and then got distracted by a completely unrelated (i.e., non-SAS) problem.  I just got back to the SAS installation and still can't figure out what's wrong (some Java problem...) but maybe I'll post a new thread about it if I am unable to figure out what's wrong on my own.   Your post helped me realize that something has to be up and running.  Which pointed me in the right direction.  Indeed, it isn't, but I came across what it is called and, thus, the instructions on how to do it.  (i.e., the SAS/Connect Spawner, described here)  I'm working my way through those instructions now.   Thank you!   Ray     ... View more

  Hi @JuanS_OCS,   Thank you for your check list of things I should look into!  Between this reply and my replies to others in the conversation, I did solve my problem.  I wasn't replying in any particular order and was bouncing back and forth between trying things and read what suggestions all of you gave me.   @JuanS_OCS wrote: Hello @rwan1, forst of all, I must say that while installation in Ubuntu is possible, it is not officially supported by SAS; meaning, SAS can help you but cannot ensure you a solution. You can check the SAS Foundation 9.4 system requirements here: http://support.sas.com/documentation/installcenter/en/ikfdtnlaxsr/66396/PDF/default/sreq.pdf If you need a free edition, I would go for a closer one to a distro that is supported. Such as CentOs, since RedHat is supported, and CentOS is, well...., almost the same.       Yes, while I seem to have gotten it working, I will keep CentOS as an option if I encounter further issues down the road.  In this case, a license was purchased for the server version, so I probably want to do whatever I can to get this working before either going with a free edition and/or re-installing the OS.     That being said: First, the best way to qualify if your SAS foundation installation is correct, is to execute the SAS Installation Qualification (sasiq) and the SAS Operation Qualification (sasoq) Tools. There is no better way.       I was not aware of this program!  This was quite useful.  I ran it and out of 38,302 files, 56 failed the checksum.  I don't quite understand why they failed, though.  Many of them are "picklist" files...they seem to be files used to fill a pick list in a pull-down table.   But, as I said in my original message, I did have errors during the installation.  Two updates failed installing.  I will look into that later -- perhaps that is related to the failed checksums.     Second, indeed, if you just execute "sas", you will need X windows and a x window client/server. MobaXterm? Third, you can also run sas in simple CLI, with the -nodms parameter       I'm actually using an Ubuntu desktop machine to connect to the Ubuntu server.  So, I'm just using ssh.  The X windows worked as I has already enabled X11 port forwarding, etc.  But thank you for the -nodms parameter.  That did work as well!     SAS 9.4 uses its own JDK and JRE. If you peek into your SASHOME directory, you will see a SASPrivateJRE folder, which is exactly that, a private Java Runtime Environment. Additional Java instances might cause trouble in some cases and, then, you need to take additional actions.      Thank you for this!  As I mentioned to @SimonDawson, who replied after you, I was not aware of this.  It's good to know.  I did come across articles such as http://support.sas.com/kb/44/853.html.  The target audience is for a Windows-based installation, but the paths mentioned for Java are not within the SASHOME directory.  So, if neither you nor Simon said anything, I would have continued to believe that the Java being used was outside SASHOME.     All in all, the fact that you made an installation in Ubuntu, it might mean that not all the internal components you are installing,  are compiled 100% for your kernel ... THis might help you as well: http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf?locale=en#nameddest=http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/     Despite Ubuntu not being officially supported, thank you everyone for your help!  I'm actually not yet "done".  Besides the failure of the update and the failed checksums, the intention is for the user to connect to the server using the client version of SAS (i.e., via SAS/Connect).  I need to set that up next before I can breathe a sigh of relief.   But I feel somewhat hopeful that this will work out after seeing the program actually run.  (Perhaps I was overwhelmed by its size and the many modules!)   Thank you again, everyone!   Ray       ... View more

@SASKiwi wrote: As I understand it, SAS Display Manager on Unix needs to be run under an X-windows graphical terminal client. If you were running SAS under a character-based terminal client then it would fail, possibly with the symptoms you are seeing.    This link may help: https://documentation.sas.com/?docsetId=hostunx&docsetTarget=n044vvir3dlogtn1wpa6bqsjbslu.htm&docsetVersion=9.4&locale=en     Thank you for your prompt reply!  I have X-Windows working fine.  At the link above, I can indeed start up "xclock" on the server, which then creates a window on my computer remotely.   In fact, the installation program (SAS Deployment Wizard) is a graphical program and I installed SAS remotely.  But thank you for mentioning this!  At least it gives me an idea of the type of things I should consider.   Ray       ... View more

  Hi Simon,   @SimonDawson wrote: Ubuntu 18.04 is not a supported distribution of GNU/Linux. Just out of curiosity why have you select Ubuntu 18.04 for your deployment?    Oh.  I guess that's a bit of a long story.  The server where I have installed SAS has been in use for a couple of years for other purposes.  (i.e., analyses using other programs)  And, until now, the choice of Ubuntu has never caused me any problems.   That aside, I have personally used Debian for 10 years and then Ubuntu for another 10 years (i.e., total of 20 years, give or take...alas, I'm not a Java programmer, though).  Currently, I use Ubuntu as my desktop machine.  So, my choice of Ubuntu as the OS for the server in question was obvious.  (And many, many years ago, I did know someone who looked after a CentOS server and she did have some problems with rpm, etc.  Of course, that's just a bias because how these distributions are now has nothing to do how they were 10+ years ago...all of them have improved a lot over the years.)   So, in short, that is the reason why I'm installing it on an Ubuntu machine.  At the time we purchased the SAS license, I *was* aware that Ubuntu wasn't officially supported.  But, like I said, other analyses were happening by other users and it seemed a bit pre-emptive to disturb what already works for them to cater to SAS, which won't be used by every user.  I'd have to try first before deciding wiping the OS.   Just incase this is useful to others when you deploy the SAS software to a system the Java interpreter used by that SAS installation is unpacked from the SAS software depot into the SASHome. The OpenJDK deployed onto a host if its installed is not the JVM used by the SAS software. The Java used by the SAS software is deployed under the SASHome/SASPrivateJavaRuntimeEnvironment/9.4/jre directory.    Oh!  That is useful information...  Then I was perhaps barking up the wrong tree by dwelling on the Java installation.  Let me look into this further; I can even consider removing the system-installed Java as I think no one is using it.  But I have to check.  I can certainly uninstall it temporarily just to its effect.   Thank you for this!   For your case @rwan1 unless you have a very good reason for needing to stick on Ubuntu 18.04 I would strongly advice deploying the SAS software onto a supported operating system. The SAS testing teams only test the SAS software on supported distributions so who know what edge case quirk you are hitting.    I suppose I cannot rule out the possibility of wiping the system and installing CentOS for SAS.  Users who are using the system with other programs can be moved to another server, I guess.   I guess this is a last resort.  I do hope that there are other Ubuntu system administrators that have seen this.  This thread has other suggestions (thank you to all of you!) which I will try first.  Thank you!   Ray       ... View more