About SASJedi

SASJedi · ‎02-23-2019

How about something like this? data have; call streaminit(12345); length name $20; array p[5]; drop i; do NAME="United Kingdom","Great Britan", "England"; do i=1 to 5; p[i]=round(rand('UNIFORM')*i*1000); end; output; end; run; data forplot; array p[5] p1-p5; set have; do i=1 to dim(p); Pop=vname(p[i]); Value=p[i]; output; end; keep name pop value; run; proc sgplot data=forplot; vbar pop/ response=value; by Name notsorted; run;

SASJedi · ‎02-22-2019

When PROC DS2 is invoked, it makes connections using its own threaded driver to all SAS libraries available in the session. Sometimes this is problematic. For example, SASHELP is a concatenated library, and as of now the DS2 driver can't handle concatenated library references. Not sure that this is the issue, but (as of SAS 9.4 M3) you can eliminate extraneous connections using the PROC DS2 LIBS= option. For example, if your DS2 program reads from MYSAS.MYTABLE and writes to WORK.NEWTABLE, you only need connections to the MYSAS and WORK libraries. You would use this statement to invoke DS2: proc ds2 libs=(MYSAS WORK); You can try this to see if it resolves your issue.

SASJedi · ‎02-21-2019

diogoalmas - Podes explicar um pouco mais precisamente o que é que não entende sobre esses programas SQL? Será que eles são copiados em SQL de outro ambiente, como um banco de dados relacional? Se os dados ainda residirem no banco de dados original e você está acessando-os com o SAS, talvez seja mais fácil fazer o query usando "explicit passthrough" do código SQL original (do banco de dados). Por exemplo, se o banco de dados fosse Oracle, a programa em PROC SQL seria algo como isto: proc sql; connect to oracle (user=student password=Metadata0 schema=orion); select * from connection to oracle (/* O SQL original aqui */) ; disconnect from oracle; quit; Cordialmente, Mark

SASJedi · ‎02-21-2019

Enterprise Miner and Enterprise Guide are both SAS clients, but they don't necessarily connect to the same SAS server on the back end, and even if they do, they don't necessarily execute SAS using the same configuration. The "ERROR: BASE driver, invalid PRIMARYPATH value" usually means that you have a SAS LIBREF assigned which points to a non-existent SAS library location. From an Enterprise Miner code node, try processing a few observations of the data set you wanted to process with DS2 just to make sure the Enterprise Miner platform has access to that data location... Mark

SASJedi · ‎02-21-2019

PROC DSTRANS is undocumented because it is only intended for back-end use by other SAS procedures in very specific cases. In SAS 9.4 M6, PROC DSTODS2 is a documented procedure designed to help SAS users translate DATA step code to DS2. I wrote a blog post about this a while back. One limitation is that both the original program file and the output file must reside in the current SAS default directory. In some client-server deployments, you won't have write permission to the SAS default directory. You can work around this by using the base SAS DLGCDIR function to set the default directory to a location where you do have write access. For example, if you were working in SAS on a Windows server and have write access to the c:\temp directory, you would save your DATA step program to C:\temp, then run code like this to make the translation: %put %qsysfunc(dlgcdir(c:\temp)); PROC DSTODS2 IN="datastep.sas" OUT="ds2program.sas"; RUN; Hope this helps. Mark

SASJedi · ‎02-14-2019

Try something like this: /* Make flat files to play with */ title; footnote; ods csvall file="C:\temp\t1.txt"; proc print data=sashelp.class(where=(Sex='F')) noobs; run; ods csvall close; ods csvall file="C:\temp\t2.txt"; proc print data=sashelp.class(where=(Sex='M')) noobs; run; ods csvall close; data _null_; file "C:\temp\t3.txt" dsd ; set sashelp.class (obs=3); if _n_=1 then put '"Name","Sex","Height","Weight"'; put Name Sex Height Weight; run; /* Proof of Concept */ DATA work.test; LENGTH filename txt_file_name _header _last_header $ 256; RETAIN txt_file_name _header _last_header ; drop _:; INFILE "C:\temp\t*.txt" EOV = eov FILENAME = filename DLM = "," MISSOVER DSD LRECL = 32767; INPUT@; IF _N_ = 1 OR EOV THEN DO; txt_file_name = scan(filename, -1,"\"); EOV = 0; _header=_infile_; if _last_header ne _header and _n_ ne 1 then do; PUT "ERROR: File structure for " txt_file_name " has changed."; PUT "ERROR- New file structure: " _header; PUT "ERROR- Previous file structure: " _last_header; stop; end; _last_header=_header; DELETE; END; ELSE INPUT Name:$15. Sex:$1. Age Height Weight; run;

SASJedi · ‎02-14-2019

You can try appending a form feed character (FF) using a DATA _NULL_ step after creating the output. I don't have ready access to a mainframe right now, but this SHOULD work. Try something like this: filename myprint file="myuid.printer.flatfile" DISP=mod; proc printto print=myprint new; run; title "Report 1"; proc print data=sashelp.class; where sex='F'; run; proc printto;run; /* Add the form feed: */ data _null_; file myprint mod; put _page_; run; Rather than use PROC PRINTTO, you might consider using ODS to write the output instead: ods listing file="myuid.printer.flatfile" DISP=mod; title "Report 1"; proc print data=sashelp.class; where sex='F'; run; ods listing close; I will say that Windows printers do not honor the Form Feed character when printing text files - so not sure this will fix it for you. Do you have other processes running on the mainframe that successfully append multiple reports to a single file and subsequently print each report on separate pages? Because if not, it may just be that your more modern printer is ignoring the embedded FF character. So, the suggestion from @Astounding to make all of the reports in a single SAS EXEC step might be the better answer. Regards, Mark

SASJedi · ‎02-13-2019

I can't figure this our with the XML mapper, but I can code for it: libname x xmlv2 "c:/temp/mtajouri.xml" automap=REPLACE xmlmap="c:/temp/mtajouri.map"; proc sql; create table temp1 as select distinct a.data_ordinal ,code ,a.type ,coefficient as Type_Value from x.Action a ,x.Coverage c ,x.Data where a.Data_ordinal=c.Data_ordinal and a.Data_ordinal=data.Data_ordinal order by Code, a.data_ordinal ; create table t2 as select code ,label as Option from x.Coverage c ,x.Data where c.Data_ordinal=data.Data_ordinal order by Code, c.data_ordinal ; create table t3 as select code ,value as Deductible from x.coverage c ,x.Data ,x.Deductible d where data.Data_ordinal=c.Data_ordinal and c.Coverage_ordinal=d.coverage_ordinal order by Code ; quit; libname x clear; proc transpose data=temp1 out=t1(drop=_:) ; by code; id type; var Type_Value; run; proc sql; create table want as select t1.Code ,TYPE_A ,TYPE_B ,OPTION ,Deductible from t1 inner join t2 on t1.code=t2.code inner join t3 on t1.code =t3.code order by t1.code ; drop table temp1; drop table t1; drop table t2; drop table t3; quit;

SASJedi · ‎02-12-2019

Arrays are one of the look-up table methods available in SAS. They are memory-resident, so performance is pretty snappy. The index is strictly numerical, so not as flexible as a hash object which can use numeric, character or even composite keys. Hashes can also return multiple data values for each lookup key. However, the hash object uses PDV-resident variables to specify key values and retrieve data. Threads in DS2 run "shared nothing", so when arrays and hash objects are specified in thread programs, at execution each thread spawned gets its own copy. This can become quite memory intensive. User-defined formats are another way of performing lookups in SAS (including DS2), and are also pretty fast and flexible. They don't contaminate the PDV, don't need to be duplicated when threading, and are re-usable in subsequent program steps. May the SAS be with you! Mark

SASJedi · ‎02-11-2019

In your code, somenum is a globally declared variable. Global scope variables reside in the Program Data Vector (PDV), are available within all methods in the data program, and are eligible to be included in the data program result set (if not excluded with a DROP or KEEP statement). Because the somenum was created by the data program and not read in from a SET statement, the PDV mechanism re-initializes this value at the beginning of every iteration of the RUN() method. However, numarray is a globally declared array. Global scope arrays are available to all of the methods in the data program and are eligible to be included in the data program result set - but they are NOT associated with PDV variables. The elements of a multi-dimensional data structure created with a DECLARE (DCL) statement reside in system memory. Because the elements do not reside in the PVD, they are never initialized by the PDV mechanism, and cannot be included in the data program result set, To create an array of PDV variables, use the VARARRAY statement. I hope this helps Mark

SASJedi · ‎02-11-2019

So, the trick is to apply the $CHAR3. format to the TrimCptbl column when you create it. This will cause SAS to preserve the leading space then the value is presented to Excel during PROC EXPORT. For example: PROC SQL; CREATE TABLE WORK.BEN_CONSO_FAMILLE_02 AS SELECT DISTINCT t1.AnneeSurv, t1.College, t1.Couverture, t1.Garantie, t1.TypeBenef, t1.Famille, /* AnneeCptbl */ (FLOOR(t1.MIN_of_AnneeTrimCptbl/10)) AS AnneeCptbl, /* TrimCptbl */ (" T" || put( MOD(t1.MIN_of_AnneeTrimCptbl, 10) , 1.)) FORMAT=$CHAR3. AS TrimCptbl, /* NbBenefConso */ (COUNT(t1.'Id Beneficiaire'n)) AS NbBenefConso, /* MntRC */ (SUM(t1.SUM_of_MntRC)) FORMAT=COMMAX8.2 AS MntRC, /* NbActes */ (SUM(t1.SUM_of_NbActes)) FORMAT=BEST12. AS NbActes, /* NbActesOptions */ (SUM(t1.SUM_of_NbActesOptions)) FORMAT=BEST12. AS NbActesOptions FROM WORK.BEN_CONSO_FAMILLE_01 t1 WHERE t1.SUM_of_NbActes NOT = 0 OR t1.SUM_of_NbActesOptions NOT = 0 GROUP BY t1.AnneeSurv, t1.College, t1.Couverture, t1.Garantie, t1.TypeBenef, t1.Famille, (CALCULATED AnneeCptbl), (CALCULATED TrimCptbl); QUIT; proc export data=WORK.BEN_CONSO_FAMILLE_02 outfile= "&RepertoireGlobal.\&Offre.\1. Données source\&AnneeMois.\4_4_BENEFICIAIRES_CONSOMMANT" DBMS=xlsx REPLACE; SHEET="Source_Prest_Benef_Cons_Famille"; run; May the SAS be with you! Mark

SASJedi · ‎02-11-2019

You didn't include the "&location.\Codes\02_ Macro - Prediction.sas" ode, so I can t be 100% sure, but it looks like you are compiling your macros to a permanent library using code similar to this: libname OPTMACRO "some location"; options mstored sasmstore=OPTMACRO; %macro MyMacro1 /stored; /*...more macro code...*/ %mend; %macro MyMacro2 /stored; /*...more macro code...*/ %mend; /* And after the macro definitions: */ libname OPTMACRO clear; You'll get the "ERROR: Unable to clear or re-assign the library OPTMACRO because it is still in use" message because SAS is still using the SASMACR catalog in the OPTMACRO library for compiled macro storage. Inserting a %sysmstoreclear macro statement just before trying to clear the OPTMACRO libref should do the trick - something like this: %sysmstoreclear; libname OPTMACRO clear; May the SAS be with you! Mark

SASJedi · ‎02-05-2019

In order for us to be able to help, I think we need a bit more information. It would be nice to have a few observations of each of the data sets being exported to test with, and an example of what you mean when you say "sas is trimming one column during the export". Does that mean one column is left out of the Excel tab, that the trailing blanks in text columns are not in the Excel file or perhaps one or more of the columns is being truncated? A small copy of the offending Excel file (or a least a screen shot showing the problem) would help get a more rapid response . You can DATA step program to create the sample data for you using the %data2datastep macro - see the article "How to create a data step version of your data AKA generate sample data for forums" All the best, Mark

SASJedi · ‎02-05-2019

Your case expression has no logical expression. It should look something like this: proc sql; select distinct Make , CASE (/* Logical Expression */ Type ) WHEN 'SUV' THEN 'N' ELSE 'Y' END from sashelp.cars ; quit; or like this: proc sql; select distinct Make ,CASE WHEN (type='SUV') THEN 'N' ELSE 'Y' END from sashelp.cars; quit; e

SASJedi · ‎02-05-2019

HOw about something like this? data have; input Var:$1; datalines; A B C D ; data want; set have; length NewVar $4; retain NewVar; NewVar=CATS(NewVar,Var); run;

Online Status	Online
Date Last Visited	Monday