Sure, those are valid options as well. Thanks for pointing them out.   Our approach (as a team inside a large organization) to put as much code as possible inside the Stored Process is mostly to handle security in one place, i.e. who is allowed to change the stored process and all related input data --such as the formats-- thus decreasing the probability of accidental modifications.   Now I see that we can define read-only datasets (to be used e.g. as input to PROC FORMAT in the CNTLIN option) with the ALTER= option of the created dataset in a data step. But this requires a password that we need to remember or store somewhere (as opposed to handle security requirements solely through SAS Management Console).   Another option would be to store the formats in a read-only 'formats' catalog. Since I haven't found a way of setting read-only status to a catalog, at least it can be simulated using SAS Managemenet Console to map a dedicated library name to the location of the 'formats' catalog with option access=readonly. But still I user could separately map that location with read/write access and change the formats... unless there is a way in SAS Management Console of defining read/write access rules to a directory sitting in the SASApp server where the application is run?   If you have any other suggestions about security handling, I would be keen to hear.   Thank you Daniel ... View more

Hello Quentin,   Thank you for your thoughts.   Your first suggestion is exactly what I had tried: running the process through normal code submission in SAS EG works perfectly fine, so it's definitely a Stored Process issue.   As per your second suggestion, unfortunately I don't think I have other ways of running a stored process other than from SAS EG.   Regarding your third suggestion, if the unseen control character were the cause of the problem, the PROC FORMAT statement (which contains 2,000 lines) would also give an error or stop when run as a Stored Process on its own... but it actually runs successfully.   Daniel       ... View more

Good question. There are no errors in the truncated log file. Following are the last few lines of the log file I generate with PROC PRINTTO: (note that the log is truncated in the middle of the FORMAT procedure, furthermore, in the middle of a format definition) 1049 VALUE F61_FOR 1050 1051 /*LOW--1 = '001- hasta -1' 1052 -1<-0 = '002- hasta 0' 1053 0<-16 = '003- hasta 16' 1054 16<-29 = '004- hasta 29' 1055 29<-30 = '005- hasta 30' 1056 30<-31 = '006- hasta 31' 1057 31<-HIGH = '007- hasta HIGH';*/ 1058 1059 LOW-0 = '001- hasta 0' 1060 0<-15 = '002- hasta 15' 1061 15<-30 = '003- hasta 30' 1062 30<-HIGH = '004- hasta HIGH'; NOTE: Format F61_FOR has been output. 1063  Sistema SAS 1064 1065 VALUE F62_FOR 1066 1067 /*LOW--11 = '001- hasta -11' 1068 -11<--1 = '002- hasta -1' 1069 -1<-0 = '003- hasta 0' 1070 0<-11 = '004- hasta 11' 1071 11<-18 = '005- hasta 18' 1072 18<-47 = '006- hasta 47' 1073 47<-104 = '007- hasta 104' 1074 104<-194 = '008- hasta 194' 1075 194<-319 = '009- hasta 319' 1076 319<-494 = '010- hasta 494' 1077 494<-HIGH = '011- hasta HIGH';*/ 1078 LOW-0 = '000- hasta 0' 1079 0<-15 = '001- hasta 15' 1080 15<-31 = '002- hasta 31' 1081 31<-46 = '003- NOTE: Format F62_FOR has been output. NOTE: FORMAT PROCEDURE used (Total process time): real time 0.07 seconds cpu time 0.01 seconds ... View more

Hello Yurie, One way is to use the SQL procedure: data First; input ID type$ rev1 rev2 rev3 rev4; cards; 101 a 0 0 . 1 101 b 1 1 0 0 101 c 0 .  1 0 102 b 1 0 1 0 102 c 1 0 .  1 102 d .  1 1 0 ; proc sql;     create table First_counts as     select         id         ,type         ,(case when rev1 = 0 then 1 else 0 end) +          (case when rev2 = 0 then 1 else 0 end) +          (case when rev3 = 0 then 1 else 0 end) +          (case when rev4 = 0 then 1 else 0 end) as count_0         ,(case when missing(rev1) then 1 else 0 end) +          (case when missing(rev2) then 1 else 0 end) +          (case when missing(rev3) then 1 else 0 end) +          (case when missing(rev4) then 1 else 0 end) as count_miss         ,(case when rev1 = 1 then 1 else 0 end) +          (case when rev2 = 1 then 1 else 0 end) +          (case when rev3 = 1 then 1 else 0 end) +          (case when rev4 = 1 then 1 else 0 end) as count_1     from First;     select * from First_counts;     select         id         ,sum(count_0) as total_0         ,sum(count_miss) as total_miss         ,sum(count_1) as total_1     from First_counts     group by id     order by id; quit; For result 1: if the number of rev* variables increase you could write a macro to generate the lines that compute count_0, count_miss, count_1. Otherwise you could use ARRAYs in a DATA step and compute the counts "manually" by iterating on the different rev* variables. I leave this as an exercise. HTH Daniel ... View more

Well, the cumulative expected profit should not be a linear curve given the Profit/Loss matrix defined in the example (where profit and loss are constant for every case). In fact, in such constant profit/loss cases, the expected profit of a single case has a linear relationship with the predicted probability; therefore accumulating its value over the top score cases will give a non-linear relationship with the predicted probability, which will most likely also generate a non-linear relationship with the predicted probability quantiles (as the quantiles are the ones used on the horizontal axis of the graph). ... View more