About Tom

PaigeMiller

@ballardw I hadn't thought about what a use could be for code like "N=%left(&sam)", but if you are right, or if you are wrong, I think there is probably a better way to handle it. It is a constant struggle to get people to explain the big picture of what they are trying to do, they only want to talk about the specific coding problem they have, they don't want to get into the big picture. This particular request seems like it is an instance of the XY Problem.

SASKiwi

You are missing a semicolon on your LIBNAME statement.

Kurt_Bremser

Your macro creates this: data ...; length ...: infile file1; input ...; infile file2; input ...; infile file3; input ...; /* and so on */ run; So, in every iteration of the DATA step, a record is read from each file; as soon as one of the INPUTs tries to read past EOF, the step terminates, regardless of records still present in other files. The shortest file determines the number of records read. See example 5 in the documentation of the INFILE Statement for how to read multiple files in one step.

Tom

Just some comments on the example SAS code you posted. If you want to set a macro variable you don't need to run a data step; %let imsid=; You almost never want to use the extremely ancient MISSOVER option or the merely ancient CALL SYMPUT() method. Instead use the modern TRUNCVOER option and the CALL SYMPUTX() method. The only reason to use MISSOVER is if you want INPUT to ignore text at the end of line that is too short for the informat width being used. The only reason to use CALL SYMPUT() is if you want the generated macro variable to have leading and/or trailing spaces. The reasons that example would work using those ancient options/methods is 1) Because you are reading from a card deck the data lines will contain 80 characters even when the number of non blank characters is less than the 14 bytes you are reading. 2) Your usage of the IMSID macro variable most not mind the extra 10 spaces that you stored into the value by using CALL SYMPUT() with a character variable defined to store 14 bytes. Of course you could also use the ancient NAMED INPUT style of reading data. /* Initialize IMSID macro variable */ %let imsid= ; /* Read IMSID from SETUP */ data _null_; infile setup ; input @'IMSID=' imsid :$4.; call symputx('imsid',imsid); run;

arorata

Hi @dxiao2017, I agree with you. @Tom and @Ksharp have already shown the way. Kind regards,

Rick_SAS

If your question is answered, please close this thread. If you have additional questions, please let us know how we can help.

LinusH

If the tables are already sorted by Custid, use @Kurt_Bremsers suggestion. Otherwise SQL FULL JOIN is a simple query. proc sql; create table want as select coalesce(aa.CustId, bb.Custid) as CustId, coalesce(aa.Y, bb.Y) as Y from aa full join bb on aa.CustId = bb.CustId ; quit;

dxiao2017

Thanks a lot, Tom! So the where condition works on the intermediate results.

Tom

To see why you got that message turn the MPRINT option before running the macro. You should see that you generated lines like: IF est = "est" THEN flg_est = 1; Which to the data step compiler means you want to compare the value of the variable named EST to the string literal "est". Just add quotes around the value in your macro code: IF "&sheet." = "est" THEN flg_est = 1; So that it generates this SAS code: IF "est" = "est" THEN flg_est = 1

dxiao2017

Hi today I somehow suddenly found that I had a wrong impression about outobs=num in proc sql, and found outobs=num in fact works for create table, the code and log are as follows: proc sql outobs=3; create table test as select * from sashelp.class; describe table test; quit; 69 proc sql outobs=3; 70 create table test as 71 select * from sashelp.class; WARNING: Statement terminated early due to OUTOBS=3 option. NOTE: Table WORK.TEST created, with 3 rows and 5 columns.

Ksharp

Or maybe you want to show this ? proc format; picture fmt low-high='%Hh %Mm %Ss'(datatype=time) ; run; data have; input TSP_DEB TSP_MOF datetime25.6 ; informat TSP_DEB TSP_MOF datetime25.6; format TSP_DEB TSP_MOF datetime25.6 ; diff=TSP_MOF-TSP_DEB; format diff fmt.; datalines ; 24SEP2025:15:13:35.000000 24SEP2025:15:21:00.000000 ; proc print;run;

arorata

Hi Ksharp, Thanks for the program. It works. If I could I would mark this too as a solution. Appreciate the help. Kind regards,

Wilbram-SAS

A hotfix is now available for SAS Enterprise Guide 8.6 that includes a new configuration option to specify the default encoding to use, which should resolve this issue. A list of the fixes provided by this hotfix (P5A001) can be found here. After applying the hotfix, which can be done using Check for Updates inside SAS Enterprise Guide, a new DefaultEncoding setting can be specified in the SEGuide.exe.config. file. More information about this setting can be found in the SAS Support Knowledge Base entry KB0042772.

FreelanceReinh

Hello @RJY9, Glad to see that Tom's solution worked for you. Then it would be fair and help later readers if you marked his helpful reply as the accepted solution, not your own "thank you" post. Could you please change that? It's very easy: Select his post as the solution after clicking "Not the Solution" in the option menu (see icon below) of the current solution.

Rick_SAS

This is all conjecture, but I think you'll find that the predictions from both models are essentially equivalent. It is also likely the differences between the predicted values from these models are smaller than the errors in the data. Recall that the parameter estimates are the solution of a maximum likelihood optimization. When we optimize a function, we iterate until some criteria are met. If you add the ITPRINT option to the MODEL statement, you can compare the optimization path used by the old and new version of SAS. My guess is that you will see a very similar path, with minor differences explained by the newer chips on the new server.

Online Status	Offline
Date Last Visited	yesterday