SAS/SECURE was a product that included encryption libraries and SAS encryption/hashing/TLS modules. The SAS encryption/hashing/TLS modules are still there, but now use operating system libraries instead of SAS shipped encryption libraries.   For AES encryption, SAS encryption modules previously used Crypto-C MicroEdition libraries but now use Bcrypt (on Windows), OpenSSL (on Linux/UNIX), and still use ISPF on z/OS.   For TLS encryption, SAS encryption modules previously used OpenSSL libraries shipped with SAS/SECURE on Linux/UNIX and z/OS (SAS on Windows has always used SChannel). Now TLS on Linux/UNIX will use the operating system OpenSSL libraries (versions 1.0.1, 1.0.2, 1.1.1, or 3.0.x) and on z/OS will be using the z/OS GSK subsystem. ... View more

The lsf.conf file and the ego.conf file have parameters for the list of master hosts (LSF_MASTER_LIST & EGO_MASTER_LIST). The value of these variables is a space separated list of host names in order of priority.   If the dead master machine is the only host listed by these variables, LSF does not know what to do.   For example, if you have EGO_MASTER_LIST="myhost1.mydomain.com" then when myhost1 goes down, LSF does not know who to make the master. If, on the other hand, EGO_MASTER_LIST="myhost1.mydomain.com myhost2.mydomain.com", when myhost1 goes down, myhost2 becomes the master. ... View more

With MobaXterm, I set it up to launch its own X server and let it set the DISPLAY environment variable in the terminal session.   The display environment variable should end up being something like "DISPLAY=localhost:10.0" ... View more

You would need to determine if the installation directory is on a mounted file system from an external device or on a local device. Shared directories would be the same externally mounted file system on all machines and result in the same path to SAS modules on every machine.   An easy way to check is to copy a file to the installation directory and see if that file is present in the same location on all machines. ... View more

If the same installation directory is shared between the metadata server machine, the mid-tier machine, and all of the grid machines, you would only need to install the hotfix once.   If the grid machines all share the same installation directory, but the metadata server and mid-tier have their own local (non-shared)  installation directory, then you would need to install it three times - once on the grid manager, once on the metadata server, and once on the mid-tier machine.   If all machines have their own local (non-shared) installation directory, you would need to install the hotfix on every machine. ... View more

Adding onto what Greg said, the new computer server pod will try to instantiate a sas-programming-environment container. Due to the size of the container, it takes a long time to download the container to a node if it is not already present. The error you are seeing may be because the creation of the container is longer than the compute service is willing to wait (usually 60 seconds).   To get around this problem, the sas-prepull service will make sure sas-programming-environment containers are pre-downloaded to all nodes that have the "workload.sas.com/class=compute" label on the Kubernetes node.   So you can either keep retrying the context in SAS/Studio until the container is fully downloaded to a node or label the node so that the sas-prepull service will put the container on the node for you. ... View more

Everything depends on where the data is stored and how you are accessing it. The following three methods should produce the same results:   1) HostA performs a SIGNON to HostB and then runs a LIBNAME statement using the REMOTE engine with SERVERNAME=HostB, it should be accessing data at the path specified on HostB's filesystem. This would look like (running on HostA)   SIGNON HostB;   LIBNAME myLib REMOTE '/path/to/data' server=HostB;   PROC CONTENTS DATA=mylib.mydata;   RUN;   2) HostA performs a SIGNON to HostB and then RSUBMITs code to HostB to run a LIBNAME statement using the BASE engine to the same path.   SIGNON HostB;   RSUBMIT HostB;     LIBNAME myLib 'path/to/data';     PROC CONTENTS DATA mylib.mydata;     RUN;   ENDRSUBMIT;   3) Running SAS on HostB to run a LIBNAME statement using the BASE engine to the same path:   LIBNAME myLib 'path/to/data';   PROC CONTENTS DATA mylib.mydata;   RUN;   (Of course #1 is the only one that will allow you to get data from HostB back to HostA)   It would be helpful if you at least provided some pseudo code as to what you are doing and the results you are seeing. Getting totally different data set information means you are not accessing the same data for some reason. ... View more

What help do you need?   Have you configured SASGSUB (SAS Grid Manager Client Utility) using the SAS Deployment Wizard? This must be done so that SASGSUB knows how to communicate with the grid.   Have you tried to run SASGSUB from its configured location (/<config-dir>/<LevX>/Applications/SASGridManagerClientUtility/9.4/sasgusb)? This will tell you if it is configured properly. Have you looked at the Submitting Batch SAS Jobs to the Grid section of the Grid Computing in SAS® 9.4 book? It is a good overview of SASGSUB. ... View more

Flow Manager uses LSF to run the jobs in a flow. If a job in a flow is available to be run, it is submitted to LSF to run. LSF determines how many jobs can run and where to run them.   If your flows are all pending, I would look at LSF's status to see why they are pending. It could be your license has expired or all execution hosts are full with long running jobs from flows or there are jobs from other sources that are executing causing the flow jobs to wait their turn. ... View more

It is difficult to say what the code means when you do not know what command was being executed. As Greg said, 1 & 2 could be SAS return codes for 'warnings in SAS execution' and 'errors in SAS execution' respectively. 255 could be that the job was killed for some reason. Maybe the user terminated the job while it was running. 231 is usually the value returned when the job returned a 999 exit code (return codes have to fit in one byte so 999=0x3E7 but since there is only one byte for return codes it ends up as 0xE7 = 231) If a grid job executes the command 'sasgrid' and returns a return code greater than 2, a log will be stored in <config>/<LevX>/<AppServer>/GridServer/Logs that may provide more information.   You need to look at each job individually to see what command was executed, where it was executed (in case jobs on a certain host all fail), when it was executed, and how it ended (was it killed by the user?). ... View more

What was missing? 'bhist -u all -T <date/time info>' provides most of you want. There is also bacct. Having something like RTM or SAS Environment Manager Server's time-series data collection really help in this area. ... View more

Have you tried bhist with the -T option? ... View more