Using Unicodes in a data step for Proc report

[mmohotsi]

Good day

I have a data set with multiple parameters each parameter  with its own specification that I want to reflect on a report using proc report. Other parameter has only ONE specification whilst others have a range between two extremes. How do I show the specifications for the parameters in a data set for reporting using proc report? The code I used is as below: 

proc format;
value $LessThan
"LE" = "(*ESC*){unicode 2264}";

value $GreaterThan
"GE" = "(*ESC*){unicode 2265}";
run;

%Let Spec_Determ1 = 10;
%Let Lower_Spec_Determ2 = 15;
%Let Upper_Spec_Determ2 = 25;

Data dataset2;
set challenge;
format Specification $40.;
if Determ = 'Determ1' then do;Specification =catx(" ",put("LE", $LessThan.),&Spec_Determ1); end; else
if Determ = 'Determ2' then do;Specification =catx(" ",put("GE", $GreaterThan.),&Lower_Spec_Determ2,'to',put("LE",$LessThan.),&Upper_Spec_Determ2); end;
run;

proc report datadata=dataset2;
columns Determ Specification Result;
run;

[Quentin]

Can you show the results from your current code, and describe what is wrong with the results?

If you can make a small example dataset, with CARDS statement, that will make it easier for people to help you.

I'm surprised you're using macro variables to store the limits.  Assuming each parameter has it's own limits, I would think it would be easier to store the limits as variables in the dataset (LowerLimit and UpperLimit).  If you have the limits in the dataset, it should be straight forward to generate the specification text, either as a variable in the dataset or using a PROC REPORT compute block.

[yosiahds]

Hi @mmohotsi,

Thank you for attaching the data set, that made it easy to reproduce. I ran your code against it, and the good news is that your Unicode approach is correct. Three smaller things keep the Specification column from showing:

1. The values of Determ end with a tab character. Because of it, Determ = 'Determ1' is never true and Specification stays blank. This often happens when data comes from Excel or a tab-delimited file.

2. The length of 40 is too short for Determ2.
The text (*ESC*){unicode 2265} takes 21 characters by itself, so the range for Determ2 needs 52. The log shows "WARNING: In a call to the CATX function, the buffer allocated for the result was not long enough..." and CATX returns a blank value.

3. A small typo in PROC REPORT.
proc report datadata=dataset2 should be data=dataset2.

Here is your program with these three points corrected. I kept your formats as they are:

PROC FORMAT;
  VALUE $lessthan    "LE" = "(*ESC*){unicode 2264}";
  VALUE $greaterthan "GE" = "(*ESC*){unicode 2265}";
RUN;

%LET spec_determ1       = 10;
%LET lower_spec_determ2 = 15;
%LET upper_spec_determ2 = 25;

DATA dataset2_spec;
  SET work.dataset2;
  LENGTH specification $100;
  /* The values of determ end with a tab, so remove control characters first */
  determ = COMPRESS(determ, , "c");
       IF determ = "Determ1" THEN specification = CATX(" ", PUT("LE", $lessthan.) , &spec_determ1.);
  ELSE IF determ = "Determ2" THEN specification = CATX(" ", PUT("GE", $greaterthan.), &lower_spec_determ2.
                                                    , "to", PUT("LE", $lessthan.), &upper_spec_determ2.);
RUN;

PROC REPORT DATA=dataset2_spec;
  COLUMNS determ specification result;
  DEFINE determ        / DISPLAY "Determination";
  DEFINE specification / DISPLAY "Specification";
  DEFINE result        / DISPLAY "Result";
RUN;

ODS PDF FILE="/<PATH>/dataset2_spec.pdf";

PROC REPORT DATA=dataset2_spec;
  COLUMNS determ specification result;
RUN;

ODS PDF CLOSE;

With this, Determ1 shows "≤ 10" and Determ2 shows "≥ 15 to ≤ 25".

The symbols appear in ODS output such as HTML, RTF, PDF or Excel. In the data set itself and in the plain listing output you will still see the text (*ESC*){unicode 2264}, which is expected.

I hope this helps. 

Best regards,
Yosia

---

P.S. A tip for problems like this one: step through the DATA step in a debugger and watch the variables. Here you would see Specification still blank after the IF statement, which points straight at the comparison. SAS Studio and Enterprise Guide both have a DATA step debugger. If you prefer VS Code, I wrote an extension called DataStep Studio that adds a DATA step debugger and a macro debugger there: https://datastep-studio.pages.dev (disclosure: I am the author).

[mmohotsi · Accepted solution]

Good day yosiahds

Thank you for this response.

This is the solution to my problem. I think the length was the major problem. Thank you once more

[Quentin]

---

@mmohotsi wrote:
Good day yosiahds

Thank you for this response.

This is the solution to my problem. I think the length was the major problem. Thank you once more

---

Glad you got it working.  Please mark @yosiahds's answer as the correct solution, to close out this question. 

[BriceGrandis]

It’s helpful that the solution identified several issues rather than focusing only on Unicode. The hidden tab characters, insufficient variable length, and typo in PROC REPORT were easy to overlook. Increasing the length and cleaning the input data seem especially important here. It’s a good reminder to check the SAS log and inspect the actual variable site values when a computed column unexpectedly comes out blank.