No, these are the ones.There are potentially more daemons (mbatchd, eauth, krbrenewd, ...) but they are started by the daemons listed by the lsf_daemons command.   I can imagine you would like to also monitor the Process Manager daemon processes (eg. jfd, fod). For us this can be done through the jstartup service:   # /etc/init.d/jstartup status fod (pid 23831) is running... jfd (pid 23833) is running...   If you have Redhat I do recommend to do this from systemd, using the systemctl commands. The LSF hostsetup command takes care of provisioning the services.   -- Jan ... View more

After several minutes of staring at your code wondering what could be wrong it struck me:   %do i=1% to 5; is probably a typo for for this intended code:   %do i=1 to 5; The percent sign after the 1 probably yields the message you get, although I didn't test that.   Hope this helps, -- Jan. ... View more

No need for a loop. How about this?     id_zero = cats(substr("00000000", 1, 8-length(id)), id);     Hope this helps, -- Jan. ... View more

What operating system are you on? We are on Linux and have seen the same. We decided to configure all the PM logfiles in the logrotate facility. This works a treat. We rotate the files daily but logrotate can also rotate based on file size. Deleting old files is also done by logrotate. Other older logfiles (we use 60 days) are removed daily with a command in cron: @daily find /your/logs/are/here -mtime +60 -delete This can be refined to limit the excursion into subdirectories and use name patterns, file types etc.   We do it for a wide range of log files but it is totally possible to do it just for the jfd file.   Obviously on Windows this would be handled differently.   Hope this helps, -- Jan.     ... View more

I first felt disappointment but then saw some hope. You say you paused and resumed the server. I'd rather stop and start instead. Just to make absolutely sure the underlying tables are released.   Anyways it is always a good idea to involve SAS tech support.   Hope this helps, -- Jan. ... View more

The real limit is imposed by your main system resources memory, cpu and IO. Whenever you run out of one your system is overtasked. When that happens depends not on LSF but on the usage characteristics of whatever is running on your system and how you tune things. You will have to measure and learn in order to determine ow many concurrent jobs your system can run.   I have learned that no two systems are alike in this respect. I am always pleased with how LSF allows one to adapt easily.   In our case we have a mix of batch jobs and workspace servers. Workspace server (for SAS EG, Studio, Enterprise Miner, ...) are the big unknowns. Some people go wild all day, others start a session, run a small query and go into meetings for the rest of the day without signing off. But also the batch jobs can range from steamrolling our servers to sitting idle for hours waiting for Teradata to complete some big in-database voodoo. So we needed months to figure out what happens and where the limits are. In fact we are now resting at a 1:6 ratio between #CPU and the number of job slots on each host in the grid.   So the best advice I can give is measure, learn, experiment and adjust. No system is the same.   Hope this helps, -- Jan. ... View more

Good luck with finding your data back; it's always your best bet.   I just figured out another way I couldn't possibly recommend:   Shut down your metadata server, make a backup of the repository manager data in <SASConfig>/Lev1/SASMeta/MetadataServer/rposmgr. Then use a SAS Base session to edit the table RPOSCTRL table in that location. Delete the record that refers to the lost repository. Restart the metadata server and hope for the best. A Metadata Analyse&Repair would be in order as a first step when (if) your server comes back to live.   Regards, -- Jan. ... View more

Here's my 2 cents worth. I have once ran into similar issues (with project repositories) and had to save the cake by using drastic measures. Drastic enough that I shouldissue warnings and dislaimers and tell you not to do this. And then you're on your own. So make backups! And then some more. And if the damage is such that metadata backups from management console don't work, make backups of your file systems while the server is stopped. Have a solid contingency plan. This is all assuming there is no chance of undoing the work of those (hopefully ex-)colleagues of yours that deleted the physical files of your repository.   Then use a datastep and the metadata_delobj() function on A0000001.A5C0JUSF (did I read that correctly?) to eliminate the occurrence of that wrecked repos. Then restart your server and see what's left.   There are other ways like creating a new repository, backing up the files (they are SAS datasets). Then remove the repos again and dive into those tables. Find the references to the now deleted repos and edit them into references to the lost repos. Now stick those datasets in the location that was deleted in the first place. Now you may be able to start the server and get rid of this repos once and for all. I recommend to not ever to use it.   I expect some flame from fellow admins and rightfully so. But desperate times call for desperate measures. And if someone has a way of getting things back on track without this then so much the better.   Good luck!   Regards, -- Jan. ... View more

Looking at session_id=2, pd_device has time=11. But that value is only provided in a later observation whith pd_load and time=11. Your code would not achieve that. You use the term "retain"but that only allows for values to be carried foreward and not backward. Probably your way out is to do a double pass. First make a set of replacement values and then merge that with the original data.   I can't find time to do that exercise for you. Maybe you find it a challenge yourself?     Hope this helps, -- Jan. ... View more