About polarjud

polarjud

Worked like a charm. Thanks, so much, Cynthia.

polarjud

The code below produces a report in Arial Narrow, as desired, in the HTML results window, but in Helvetica in the RTF file. So perplexing. Why are my instructions being overridden by some random default? data SimpleTest; input treatment trainingMonths_LO; cards; 1 13 0 12 1 10 0 3 ; run; ods rtf file='S:\projects\HPOG_2.0_Eval\Analysis\04 Outputs\LTIR\JunkTest.rtf'; proc report data=SimpleTest style(report)=[fontfamily="'Arial Narrow'"] style(header)=[fontfamily="'Arial Narrow'"] style(column)=[fontfamily="'Arial Narrow'"]; column treatment (Mean Std),trainingMonths_LO; define treatment/group; define trainingMonths_LO/format=6.2; title 'Months of training'; run; ods rtf close;

polarjud · ‎07-06-2021

My format catalogs are stored on the remote server. Is there some easy way to create copies of them in the work library at the start of a job?

polarjud · ‎07-06-2021

All of them, but I figured out the issue. It was a bad format search option.

polarjud · ‎07-06-2021

Okay, I figured out the issue. It was a bad format search. Thanks for the help, Kurt!

polarjud · ‎07-06-2021

Well, that ran at normal speed. Strange. data class; set sashelp.class; run; NOTE: There were 19 observations read from the data set SASHELP.CLASS. NOTE: The data set WORK.CLASS has 19 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 0.01 seconds cpu time 0.01 seconds

polarjud · ‎07-06-2021

Programs that were running fine and now taking hours to run. The problem is restricted to data steps. My processing is local after the first step when I retrieve a permanent data step via a VPN connection to a central file server. All subsequent data steps are in the work directory which is mapped to the C drive in my laptop. Datasteps that were taking 0.04 seconds of real time and 0.06 seconds of CPU time are now taking 5+ minutes of real time and 8+seconds of CPU time. Something is clearly interfering. If it were anti-malware or actual malware, it would probably impact both data steps and procedure calls. So I am thinking that SAS is trying to communicate with the remote file server even though it was not asked to do so. Any way to check out this theory? Other solutions? The files involved are small, and the temporary SAS datasets appear to be of reasonable size. No sign of exhausting virtual drive space. Running SAS 9.4 TS Level 1M6. X64_10Pro platform.

polarjud · ‎04-12-2019

Thanks, but I already did all of that. There is no way to prevent the error from occasionally occurring. Interactively, I can recover from the error. Is there nothing to do in a batch job to force execution to resume just as it does in interactive mode?

polarjud · ‎04-11-2019

I am running a simulation of GLIMMIX on a multi-level dataset that I create. Periodically, one of the populations I generate will cause GLIMMIX to spasm. It cannot get convergence. Should be no bid deal. I want to disregard that draw (by examining the ods ConvergenceStatus) and move onto the next draw. However, once this error has been activated, nothing else works. Every datastep and procedure fails to execute. I should say that this happens only in batch mode. Interactively, I can continue with the next draw, but the program is too intensive to run interactively. I guess the batch session permanently enters some sort of safe mode after encountering this error. Is there some way that I can force the system out of this mode and return to executing the next loop of my program? The error code is: 1012 The GLIMMIX procedure failed to obtain post-processing information.

polarjud · ‎04-24-2018

Even with no missing data, they do not match because of rounding. MIXED rounds more than MEANS. But as for the desired behavior in the case of missing outcome data, I think you are missing the point of predictive margins. They are supposed to present estimates on a well defined population.

polarjud · ‎04-24-2018

I found the first problem in both GLM and MIXED. The second one may only impact MIXED. Not sure. It is extremely easy to reproduce. Let Y be some outcome variable with some missing data. Let D1 and D2 be binary indicators for population domains of interest (no missing data). Let X be a binary or continuous covariate (no missing data). Let Z be a categorical variable labeling clusters (no missing data). Proc Mixed data=; Class D1 D2 Z; Model Y = D1 D2 D1*D2 X/solution; Random intercept/subject=Z; LSMEANS D1 D2 D1*D2/E; run; proc means data= means; var X; run; You will immediately see that the means used by LMEANS to estimate predictive margins are different from those produced by proc means.

polarjud · ‎04-24-2018

I think I found two undesirable features in LSMEANS. First, it is calculating the means of the covariates on the set of cases where the outcome is not missing. For predictive margins, we really want the means on the set of cases where none of the covariates are missing. As it is, LSMEANS is projecting to an uninteresting population. Second, LSMEANS is rounding the population-wide averages of the covariates before taking their inner product with the beta coefficients. (Or it is rounding the beta coefficients. Maybe both?) This can cause the LSMEAN for the reference group to be different than the empirical mean for the reference group. This makes for awkward presentations.

polarjud · ‎02-27-2014

I figured out the first question. With the positional syntax, there should be 6 coefficients, but SAS assumes that if you name less than 6 then however many at the end are missing, they are all put =0. Would be really nice if the documentation of this was improved. So 0 0 1 -1 is the same as 0 0 1 -1 0 0 and 0 1 0 0 -1 is the same as 0 1 0 0 -1 0

polarjud · ‎02-27-2014

9.3 TS Level 1M1

polarjud · ‎02-27-2014

Well, I just tested the code. Should have done that first. It does work. So I guess my questions are: 1) Why in the positional syntax are 5 values needed if B is listed first and just 4 if A is listed first? 2) Why does the nonpositional syntax depend on position?

Online Status	Offline
Date Last Visited	3 weeks ago

Re: Arial narrow font in RTF

Arial narrow font in RTF

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Sudden slowness in data steps while procedures run at normal speed

Re: Recovering from a bad population draw in a simulation macro

Recovering from a bad population draw in a simulation macro

Re: Bugs in LSMEANS

Re: Arial narrow font in RTF

Re: Arial narrow font in RTF

Re: Sudden slowness in data steps while procedures run at normal speed

Re: check if macro variable is null

Re: Turning off all output in large simulation jobs

Arial narrow font in RTF

Re: Error in SAS documentation of syntax for shared estimate statement

Re: Arial narrow font in RTF

Arial narrow font in RTF

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Re: Sudden slowness in data steps while procedures run at normal speed

Sudden slowness in data steps while procedures run at normal speed

Re: Recovering from a bad population draw in a simulation macro

Recovering from a bad population draw in a simulation macro

Re: Bugs in LSMEANS

Re: Bugs in LSMEANS

Bugs in LSMEANS

Re: Error in SAS documentation of syntax for shared estimate statement

Re: Error in SAS documentation of syntax for shared estimate statement

Re: Error in SAS documentation of syntax for shared estimate statement