About Tom

Tom · ‎11-10-2025

Just use some other tool to find the location of the second uppercase letter. Such as the VERIFY() function. NOTE: remember to include the period in the format specification, or else your input statement will just read the single byte from column 25. data split_names; input name $25.; datalines; JohnDoe SrinivasPavan KishoreKumar ChandrasekaRao Ghandi ; data want; set split_names; loc = verify(substr(name,2),'abcdefghijklmnopqrstuvwzy'); if loc then last=substr(name,loc+1); first=substr(name,1,length(name)-lengthn(last)); run; proc print; var name loc first last; run; Obs name loc first last 1 JohnDoe 4 John Doe 2 SrinivasPavan 8 Srinivas Pavan 3 KishoreKumar 7 Kishore Kumar 4 ChandrasekaRao 11 Chandraseka Rao 5 Ghandi 6 Ghandi

Tom · ‎11-08-2025

You can read it using the ZIP fileref engine. Either directly in the INFILE statement. infile 'filezipped.zip' zip member='file_0001.txt' ; Or by first creating a FILEREF . filename file1 zip 'filezipped.zip' member='file_0001.txt' ; and then using the fileref in the INFILE statement infile file1 ; You could also use the fileref in other places where you might have used a physical filename. Such as PROC IMPORT. proc import file=file1 .....; You could also make a fileref that does not specify which member of the ZIP file to read. filename zipfile zip 'filezipped.zip' ; That is the same as pointing a fileref at a directory . In the INFILE statement you can then select which member you want using the normal old fashion SAS syntax: infile zipfile('file_0001.txt') ;

Tom · ‎11-08-2025

If you want to keep N digits for any magnitude number then first use LOG10() to figure out the magnitude of the number. Then you can adjust the factor your multiple/divide by in that formula. So if you set the macro variable NDIGITS to represent the number of digits you want to keep the formula could be: factor = 10 ** (floor(log10(X))-(&ndigits-1)); X_round=round(X/factor)*factor; Example; %let ndigits=3; data test; input n; log=floor(log10(n)); factor = 10 ** (log-(&ndigits-1)); n_round=round(n/factor)*factor; cards; 345123456 34512345 3451234 345123 34512 3451 345.1 34.51 3.451 .3451 .03451 .003451 ; proc print; format n best20.3 n_round comma20.6 ; run; Note you can skip the multiplication and division and just let the ROUND() function do it for you by using the optional second argument. n_round=round(n,10 ** (floor(log10(n))-(&ndigits-1)));

Tom · ‎11-06-2025

OPEN_ED-1047 is a Single Byte encoding. So you don't need to worry about multi-byte characters or using KSUBSTR(). You can use KCVT() to convert the ASCII string generated by COLLATE into the equivalent OPEN_ED-10247 string. do i=1 to length(string); char = char(string,i); if verify(char,kcvt(collate(32,126),'latin1','OPEN_ED-1047')) then do; put i= char= $hex2. ; end; end;

Tom · ‎11-05-2025

Because 1.00 is the MAX of the DIFF.

Tom · ‎11-04-2025

Kind of looks to me like the articles you linked are talking about converting the FORMAT catalog into a DATASET and storing that. So basically use PROC FORMAT to convert your format(s) into a control datasets. proc format lib=work.formats cntlout=caslib.formats noprint; run; So if you can figure out how to convert caslib in-memory dataset into disk files that persist and then load them back into memory then the only additional step you need to do in the new session is convert the dataset back into a format catalog. proc format lib=work.formats cntlin=caslib.formats noprint; run; I suspect that the need to have the formats in CAS formats is for things like Dashboards that might not use the compute server to run code. Some of the other articles are talking about how the system admin can configure the system so that some particular format catalogs are automatically loaded when you start a new session.

Tom · ‎11-02-2025

Step 1 makes no sense. If you just started a new SAS session there is no WORK.FORMATS catalog yet. Step 2 make no sense to me since you never defined any libref name CASFORMATS. (Perhaps I don't understand VIYA? Are CAS library names allowed to be more than 8 bytes long? Where are you telling CAS that you want a library named CASFormats? I can see where you defined the library named CASuser in your first two statements, but do not see anything similar that might have defined CASFormats.

Tom · ‎10-31-2025

If you are querying data that is using a single byte encoding (such as LATIN1) and running SAS using UTF-8 encoding then some characters could go from using one byte to using two or more bytes. Which could cause the same string of bytes to grow in length. What are the different SAS sessions using for the value of the SAS system option ENCODING? You can run this simple statement to see the setting in the SAS log. %put %sysfunc(getoption(encoding));

Tom · ‎10-30-2025

If you are new to SAS you probably forgot to end the statement with semicolon. Or end the step with RUN statement (or QUIT statement, depending on the step being run). Or perhaps you have submitted code that has unbalanced quotes or unbalanced parentheses and SAS is waiting for you to finish telling it what to run. What interface are you using to submit the code to SAS? Are you using SAS/Studio or Enterprise Guide as your interface to submit code to some separate SAS server? Or are you running SAS itself interactively. Either on your Windows PC or if running Unix then using X-Windows server.

Tom · ‎10-29-2025

The %GLOBAL statement makes a symbol (usually called a macro variable) in the GLOBAL symbol table and has nothing to do with actual variables. There is no such thing as a "global variable" in SAS. A variable can only exist in a dataset. The macro processor executes while the program text is being read in and before it is passed to the actual SAS language processor. So placing a %GLOBAL statement in the middle of a data step will just confuse the humans reading the code. The %GLOBAL statement will be executed by the macro processor before the SAS language processor has finished figuring out how to build the DATA step, and so definitely before the DATA step can run. So just place the %GLOBAL statement before the DATA statement so it is clearer to the humans reading the code. If you want the data step to set the a value into a macro variable use the CALL SYMPUTX() method. So this code if run today would put the string 29OCT2025 into a GLOBAL macro variable named QSTART. data _null_; call symputx('qstart',put(intnx('quarter',date(),-1),date9.,'G'); run; To then use that to generate the WHERE statement in your later code you would need to add something to convert that string into an actual date value. For example you could use it to generate a date literal. where sampdate ge "&q_start"d ;

Tom · ‎10-28-2025

@_zeta_ wrote: I was able to replicate the case, It works! ;*%mend;*);*';*";**/; run; Now, we want to replicate this for all users that use SAS Studio, I can't do that in workspace autoexec.sas code because It should be place at the beginning of the user's code, may be exist another place to do that? You cannot fix user generated unbalanced quotes (or unbalanced macro defintions) in the autoexec.sas file. The problem hasn't happened yet when the autoexec file executes.

Tom · ‎10-27-2025

Note: It is dangerous to replace a dataset when making changes, especially when you are not sure the code is going to work. For example if you ran your posted data step twice the second run would fail. 178 DATA INFORCE_SEP2025 (rename=(LOB=FLOB)); 179 SET INFORCE_SEP2025; 180 format lob $FLOB.; 181 where newren eq 'N'; 182 RUN; NOTE: There were 0 observations read from the data set WORK.INFORCE_SEP2025. WHERE newren='N'; NOTE: The data set WORK.INFORCE_SEP2025 has 0 observations and 2 variables. NOTE: DATA statement used (Total process time): real time 0.01 seconds cpu time 0.00 seconds 183 184 DATA INFORCE_SEP2025 (rename=(LOB=FLOB)); 185 SET INFORCE_SEP2025; 186 format lob $FLOB.; 187 where newren eq 'N'; 188 RUN; NOTE: Variable lob is uninitialized. WARNING: Variable LOB cannot be renamed to FLOB because FLOB already exists. NOTE: There were 0 observations read from the data set WORK.INFORCE_SEP2025. WHERE newren='N'; NOTE: The data set WORK.INFORCE_SEP2025 has 0 observations and 3 variables. NOTE: DATA statement used (Total process time): real time 0.01 seconds cpu time 0.00 seconds If you want to use the format to CHANGE THE VALUES then perhaps you want something like this instead? DATA INFORCE_SEP2025_modifed; SET INFORCE_SEP2025; where newren eq 'N'; FLOB= put(lob,$FLOB.); drop lob; RUN;

Tom · ‎10-27-2025

Thanks for this. But this comment in the example test program is backwards. infile mypipe truncover; /* Read from the pipe, truncate long lines */ The lines themselves are not truncated by the TRUNCOVER option. In fact the effect is just the opposite. The TRUNCOVER option allows the reading of lines that have fewer bytes than the INPUT statement requested.

Tom · ‎10-27-2025

If you really must read in data from XLSX files that you then what to combine with other datasets then you must put in a step to confirm that the structure (variable names, types, lengths) of the datasets are compatible. Either a step that it just checks the structure and reports the differences so you know why the process failed. Or something that is smart enough to modify the structure to make it compatible.

Tom · ‎10-26-2025

I would assume it is because the coder that made the plot decided it looked better when the frequencies are in ascending order. Note that whoever made the code that makes that PLOT did so some 30 years after the table output was coded.

Online Status	Offline
Date Last Visited	Saturday