.

Validation checks or tools to check the compliance of SDTM data JANUS is a standard database model which is based on the CDISC’s SDTM standard. JANUS is used by the FDA to store the submitted SDTM clinical data. As a part of data definition file submission pharmaceutical companies have to submit SAS datasets in transport file ( . xpt ) format along with annotated CRF and Define.xml file. The reason being this is… to properly load the clinical data into JANUS database which is maintained by the FDA. It is very easy for FDA reviewers to review the clinical data once they load the clinical data into their JANUS database. They can even produce ad-hoc reports and perform cross-study review at the same time. FDA runs compliance checks on the data submitted to make sure the data was collected as per the SDTM standard. FDA checks the compliance of data by running the WebSDM™ developed by PhaseForward ). WebSDM™ is a SDTM compliance check validation tool performs a set of SDTM c...

HANDLING SPECIAL EMBEDDED CHARACTERS To manage and report data in DBMS that contains very long text fields is not easy. This can be frustrating if the text field has special embedded symbols such as tabs, carriage returns (‘OD’x ), line feeds (‘OA’x) and page breaks. But here is simple SAS code which takes care of those issues. The normal line end for Windows text files is a  carriage return character or a line feed character so   The syntax for taking out all carriage return ('OD'x) and line feed ('OA'x) characters is comment= Compress(comment,'0D0A'x);                              or comment= TRANWRD(comment,'0D0A'x,’’); If you just want to take out the Carriage Return, use this code: comment= TRANWRD(comment,'0D'x,''); You could also try this one too.. Comment=compress(Comment, ,"kw"); * k is for keep, w is for "write-a...

/* create sample data */ data one; input a $ b $ c $ d e; cards; a . a 1 3 . b . 2 4 a a a . 5 . . b 3 5 a a a . 6 a a a . 7 a a a 2 8 ; run; /* create a format to group missing and non-missing */ proc format; value $missfmt ' '=' missing ' other='non-missing'; value missfmt .=' missing ' other= 'non-missing' ; run; %macro lst(dsn); /** open dataset **/ %let dsid= %sysfunc (open(&dsn)); /** cnt will contain the number of variables in the dataset passed in **/ %let cnt= %sysfunc (attrn(&dsid,nvars)); %do i = 1 %to &cnt; /** create a different macro variable for each variable in dataset **/ %let x&i= %sysfunc (varname(&dsid,&i)); /** list the type of the current variable **/ %let typ&i= %sysfunc (vartype(&dsid,&i)); %end; /** close dataset **/ %let rc= %sysfunc ( close (&dsid)); %do i = 1 %to &cnt; /* loop through each variable in PROC FREQ and ...

When programming in SAS, there is almost always more than one way to accomplish a task. Beginning programmers may think that there is no difference between using the WHERE statement and the IF statement to subset your data set. Knowledgeable programmers know that depending on the situation, sometimes one statement is more appropriate than the other. For example, if your subset condition includes automatic variables or new variables created within the DATA step, then you must use the IF statement instead of the WHERE statement. This tip shows you how and when to apply the WHERE and IF statements to get correct and reliable results. It also reviews the similarities as well as the differences between these two SAS programming approaches. Detail differences in program efficiency between the two approaches will not be covered in this tip. For more details refer to  http://support.sas.com/kb/24/286.html

When moving SAS datasets /catalogs from one type of computer to another, there are several things to be considered, such as the operating systems of the two computers, the versions of SAS and the type of communication link between the computers. The easiest way to move SAS datasets from one system to another system is to: Create a transport file using any SAS version. Move the transport file to the new system. Import the transport file on the new system. Transport datasets are 80-byte length binary files made from SAS datasets. PROC COPY or PROC CPORT can create Transport datasets but they both create different types of transport files. Transport files can be created and read using either PROC COPY or PROC CPORT & PROC CIMPORT, but you cannot mix and match. Transport files created with PROC COPY must be read with PROC COPY; those created by PROC CPORT must be read with PROC CIMPORT. PROC COPY uses an engine (i.e. XPORT) to create a SAS transport file. PROC COPY is used to tra...

Task : I have a SAS date and wanted to create a variable with the month name. Here is how to do it...... Use MONNAMEw. format which is simple and easy.  You need to be using  SAS 9.X versions to make it work. /*Use MONNAMEw. format*/ data month; input date: mmddyy8 .; month_name= put (date, monname3 .); datalines; 01/15/04 02/29/04 07/04/04 08/18/04 12/31/04 ; run; proc print; run;

I happend to stumbleupon a post from SAS support blog regarding the ERROR message in the LOG file when trying to output a SAS dataset in the form of Excel sheet. Direct link: ERROR: The MS Excel table (worksheetname) has been opened for OUTPUT. This table already exists, or there is a name conflict with an existing object. This table will not be replaced. This engine does not support the REPLACE option. ERROR: Export unsuccessful. See SAS Log for details. When you use the EXPORT procedure on an Excel workbook, the workbook might be corrupted and the following error message generated: This problem can occur if a previous EXPORT procedure attempts to export a SAS data set in the workbook that does not contain any observations. The following example illustrates an export procedure on such a data set: % macro blowup; data a; a=1; stop ; run ; % do i=1 % to 2; proc export data=a outfile =" c:\temp\test.xls " dbms =excel2000 replace ; run ; % end ;...

Even though there is no function is available in SAS to do exactly the opposite work of the LAG function (i.e: reading the next record while working on the current one), there are few things you can do to do exactly that. Here are few simple techniques which are proved to work without any problem. *SAMPLE DATASET; data test; input id age grp ; datalines ; 1 10 1 2 20 1 3 30 1 4 40 1 5 50 1 1 10 2 2 20 2 3 30 2 4 40 2 5 50 2 ; run ; *1) Using the POINT feature along with automatic variable _N_; This solution was suggested by Paul M. Dorfman ; data leads; _n_ ++ 1 ; if _n_ le n then do; set one point=_n_; leadage=age; end ; set one nobs=n; run ; *OR*; data leads; _n_ ++ _n_ lt n; set one point=_n_; leadage=age; set one nobs=n end=end; if end then leadage= . ; run ; By using the above techniques, you can jump a bit higher and even look values of two, three or any numbers of observations in advance by advancing the value of...

Recently I stumbled upon a SUGI-Paper  SAS 1-Liners by Stephen Hunt. I liked the way Stephen developed the 1-liner for   STUDY DAY calculation. Direct link: One of the most common calculation used across all types of programming is determining a relative 'day' based on 2 date fields. In clinical trials the initial 'Study Day' is generally considered to begin at either randamization or dosing, thus assessments made prior to this starting point require a slight variation in the calculating in order to preserve the typical  'no day 0' concept.   SUGI proceedings10/054-2010.pdf   When it comes to calculating such, some programmers opt to both with evaluating whether a visit date occurred on or /after randomization. if visdt > randdt >.z then stydy=visdt-randdt; else stydt=visdt-randdt+1; However, this is unnecessary, sine the 1-liner will suffice: if visdt > .z & randdt > .z then stydy=visdt-randdt+(visdt>=randdt); ...