Dealing with such overlapping intervals you may have to provide some additional rules. Such as this case where a second starts within another interval but extends past the discharge of a previous interval. ID AdmitDate DischargeDate 1 1/1/2025 2/4/2025 1 1/17/2025 3/23/2025 What would you do in this case?   If, and this is a pretty big if in some situations you actually do only want the "initial", defined as the earliest admit date then on approach might be to sort but ID and Admit date. Then with the sorted data you might be able to use something like this: Data want; set datasorted; by id admitdate; if first.id; run; If the data is sorted by id and admitdate, assumes admitdate is a SAS date value numeric and hopefully with a date type format applied. The BY statement creates automatic variables for each variable that are referenced as First.variablename or Last.variable which are numeric 1/0 valued variables that SAS will treat as true/false to test if a value is the first or last of a given by group. So the IF First.ID, a subsetting IF, keeps only the observations with the first occurrence of an ID value.   However the above likely will not work if there are multiple admit sets, such as ID 1 having another admit 05/05/2025.   So a more complete description of likely scenarios and a few more rules are needed. ... View more

@palolix wrote: Thank you very much for your suggestion.   I changed the variable names as you suggested (FruitWt_Day0 etc) and then modified the code to this but I still get the same errors for the array   Changing the name of the variable does not change the variable type. So if you have a mix of character and numeric values as your error messages says then the change has absolutely no effect. The bit about naming similar variables this way is more helpful starting with reading the data initially and making sure that all the variables of the same group are of the same time. Then analysis or manipulation goes quicker. ... View more

If you provide some example data in the form of a working data set you might get working code. One way would be to use Proc Format to create a custom format for the county code variable and apply the format to the code variable in proc freq. Here is a brief example: Proc format; value county_code 1 = 'A' 2 = 'B' 5 = 'C' 4 = 'D' 3 = 'E' 6 = 'F' ; run; data example; input County_code yes_no $; datalines; 1 Yes 1 No 3 Yes 5 No 5 Yes 2 Yes 6 No ; Proc freq data=example; table county_code*yes_no; format county_code county_code. ; run; I didn't bother to put the county name variable in the example data set because the code value is all that is needed.   The format name does not have to be the same as the variable it just makes it easier to keep track of. Note the use of the period at the end of the format name in the format statement. That is how SAS knows that is the format and not a variable.   Formats are a very powerful tool because additional formats can be used with the same data set and variable to get different analysis. For example with something like a county code variable I could create a format that assigns the codes to something like geographic management regions, my state has 6 or 7 depending on whether you are working with Public Health Districts or Education regions for example. Or by some other characteristic such as population size group or density, mean income or just about anything. Then the only change to an analysis is using the format. Proc format can use a data set with codes and such descriptions as well to avoid writing a lot of code such as for Texas which has over 250 counties. If the codes are character and not numeric the format name in the proc format code needs be prefaced with a $ and when used in a format statement. This is needed because you could have separate formats for a numeric and character values.               ... View more

I would suggest using one of the SAS supplied data sets such as SASHELP.CLASS or SASHELP.CARS with Proc Gplot using similar options that demonstrates the same behavior.  Then show us the complete code from that example.  That way things like the incomplete AXIS1 and LEGEND1 definitions, missing a semicolons, would be addressed and removed as possible sources of a problem. Also it very often more useful to see the LOG with the notes and any warnings or errors involved with the code. For example, with your current code shown with the Axis and Legend statements incomplete then possibly the current code did not replace a previous file because Proc Gplot would not actually run with the shown code. The LOG would clear that up. Copy the text from the log, on the forum open a text box using the </> icon above the message window and paste the copied text. The text box preserved formatting that would be removed in the main message window. Here is an example LOG based on your posted code modified to use a set that exists on my system and a plot statement. Note the syntax errors thrown by the incomplete statements. 21 AXIS1 LABEL = ("test label") 22 LEGEND1 LABEL=("TEST LABEL") ------- 22 202 23 SHAPE=BAR(10pt,10pt) ----- 22 76 ERROR 22-322: Syntax error, expecting one of the following: ;, ',', COLOR, INTERVAL, LABEL, LENGTH, LOGBASE, LOGSTYLE, MAJOR, MINOR, NOBRACKETS, NOPLANE, NOSTAGGER, OFFSET, ORDER, ORIGIN, REF, REFLABEL, SPLIT, STAGGER, STYLE, VALUE, WIDTH. ERROR 202-322: The option or parameter is not recognized and will be ignored. ERROR 76-322: Syntax error, statement will be ignored. 24 PROC GPLOT DATA=sashelp.class ; 25 TITLE1 "test title"; 26 plot height*weight ---- 180 ERROR 180-322: Statement is not valid or it is used out of proper order. 27 FRAME 28 LEGEND=LEGEND1 29 HAXIS=AXIS1; 30 RUN ; 31 quit;   Is the image you show as created by SAS or after import into WPS? From your description it seems like you had a process working that changed when your client changed their software. Or did your data change making the graph appear different in the SAS created file?       You may also want to run Proc GDEVICE to get a listing of the current settings of your GIF device driver. It might be that something modified that driver. Code using the default location of the SAS/Graph devices: Proc gdevice nofs catalog= sashelp.devices ; list gif; run; and likely result: GDEVICE procedure Listing from SASHELP.DEVICES - Entry GIF Orig Driver: GIF Module: SASGDDMX Model: 19999 Description: GIF Universal Printer Type: PRINTER *** Institute-supplied *** Lrows: 43 Xmax: 8.333 IN Hsize: 0.000 IN Xpixels: 800 Lcols: 88 Ymax: 6.250 IN Vsize: 0.000 IN Ypixels: 600 Prows: 0 Horigin: 0.000 IN Pcols: 0 Vorigin: 0.000 IN Aspect: 0.000 Rotate: Driver query: Y Queued messages: N Paperfeed: 0.000 IN OPTIONS Erase: Autofeed: Chartype: 0 Swap: Cell: Maxcolors:17E6 Autocopy: Characters: Repaint: 0 Handshake: Circlearc: Gcopies: 0 Dash: Gsize: 0 Prompt - startup: Fill: Speed: 0 end graph: Piefill: Fillinc: 0 mount pen: Polyfill: Maxpoly: 3000 chg paper: Symbol: Lfactor: 0 Pensort: N Promptchars: '000A010D05000000'X Rectfill: '8000800000000000'X Dashline: 'FFFFFFFFFFFC0000'X Devopts: 'DDC3A0C809E823C8'X UCC: '0021010A000004010A0000040000000000010001'X Cback: WHITE Color list: BLACK RED GREEN BLUE CYAN MAGENTA GRAY PINK ORANGE BROWN YELLOW BISQUE CORAL LIME MAROON DARKGRAY DEEPPINK DIMGRAY NAVY OLIVE PERU PLUM GOLD THISTLE HOTPINK INDIGO KHAKI LAVENDER PURPLE SIENNA SILVER SKYBLUE TAN TEAL TOMATO VIOLET WHEAT CHARTYPE RECORDS Chartype Rows Cols Font Name Scalable 0 1 1 <MTmonospace> Y FILE INFORMATION Gaccess: Gsfname: Gsfmode: REPLACE Gsflen: 0 Trantab: Devmap: Devtype: GTERM Gprotocol: Fileclose: DRIVERTERM Hostspec: HOST INFORMATION It has been a long time since I played with the Graph devices but this may provide some help.   ... View more

You would need one or more procedures that write output such as Proc Print, Proc Report, a data step with the correct options, a modeling proc, something. Then there would have to be an ODS EXCEL CLOSE; after the procedures so SAS knows when you are done writing to the file. ... View more

I am going to throw in a style choice that your or your office is made that is making you write more code than is needed for array processing.  By placing the interval measures of 0, 3, 7 (or others) in the middle of the variable name you keep yourself from using the variable list features of SAS. If the variables were named for example FruitWt_Day0, FruitWt_Day3 and Fruitwt_Day7 you could write the ARRAY statement as: Array _FruitWt (*) Fruitwt:  ; The colon immediately after FruitWt tells SAS to use all the variables whose names start with Fruitwt. Or if you have other such variables then use Fruitwt_Day:  to get only those suffixed with Day.   Have you actually run Proc Contents yet? Or opened the data set and examined ALL the variables used in those array statements? Or actually closely read the LOG? That particular error will only appear immediately after the statement causing the error. Se this example from my log. 187 data junk; 188 set sashelp.class; 189 Array x (*) Name sex height; ERROR: All variables in array list must be the same type, i.e., all numeric or character. 190 array y (*) age height weight; 191 run; So be reading the log I can tell that one of the variables referenced on the Array X statement has a problem. So it is one of Name Sex or Height. The first two are character and the third is numeric. As shown by this from Proc Contents: Alphabetic List of Variables and Attributes # Variable Type Len 3 Age Num 8 4 Height Num 8 1 Name Char 8 2 Sex Char 1 5 Weight Num 8   ... View more

I agree with @Tom that several details are missing.   Your bit here: @NewUsrStat wrote: ... Moreover the format the variables will take is exactly their value like for example proc format ... "Chemotherapy" = "Chemotherapy"  "Transplant" = "Transplant", ....    If you have a data set of values that you expect to encounter you can use that data to make a CNTLIN data set for Proc format. Here is an example using the SASHELP.CLASS data set that you should have. /* select all the males from the data set and create a format that will show that text as the label and "Other" for the females */ data example_cntlin; /* the END = option is to allow conditional creation of the OTHER statement options as the last entry of the format*/ set sashelp.class (where=(sex='M')) end=lastone; /* key variables that a Proc Format CNTLIN requires are Fmtname start (end if there is range of values) label type, C for character here, and since we want to use the OTHER option the HLO variable which may contain other things */ fmtname='F_to_other'; start=name; label=name; type='C'; output; if lastone then do; /* that is a capital O not a zero*/ hlo='O'; /* special text for the Start/end values with Other*/ start='**OTHER**'; label='Other'; output; end; drop name sex age height weight; run; /* use the data set to create the format*/ proc format cntlin=example_cntlin; run; /* demonstrate how to use the format created*/ proc print data=sashelp.class noobs; var name; format name $F_to_other.; run; If you have any questions about what special values in which special variables used by Proc Format for a CNTLIN data set it is pretty easy if you know the options you need. Write a very small Proc format step with the options you need be they ranges, invalues (informats) or whatever. Add on the Proc Format statement the option CNTLOUT=somedataset. The procedure will create a data set with the variables needed and the options.   Caveat: If you have multiple variables in in a single data set that you want to work with you must make sure that the final data set is sorted by the FMTNAME variable as otherwise Proc Format will create and overwrite a bunch of basically one value versions of the formats. It might be best to create one CNTLIN data set per set of values/variable for simplicity sake. Keep the sets in a permanent library. Suggest also writing the Formats to a permanent library using the LIBRARY= option and then adding that library to the FMTSEARCH  path so you don't have to recreate the formats each session.   If your clinicians are anything like the ones I worked with you may need to make sure that the spelling is consistent because a value of "Xyz" the format is looking for will not match "xyz". I often fixed that by creating custom informats that used the UPCASE option that would treat all the text as uppercase before comparing to value on the informat and assigning the proper expected values.    Something like this: Proc format; invalue $sometext (upcase) 'ABC'='Abc' 'PDQ'='Pdq' 'JACK DANIELS' = 'Jack Daniels' other=_same_; run; data example; input text $sometext.; datalines; abc abC ABc pdq somethiing else ; The CNTLOUT option would show where the UPCASE gets set in the control data set. Note the use of _SAME_ to copy any unexpected text. The CNTLIN data set would want the START value to be all uppercase.    If you have known supposedly fixed set of values, such as Clinic names, you could use the _ERROR_ option in the INVALUE to throw an error when an unexpected value gets entered into a data set so the LOG would throw invalid data messages. If you find that one of your clinicians abbreviates or misspells a value consistently you could add that to the Invalue as format has not problems taking multiple input values to the same output. I used this frequently because one of our contractors would "update" their data system so that things that had been established to report a value as M or F for female would do things such as spell the word out or add a / and the Spanish equivalent. I could modify my informats to accommodate such and keep the original correct values in our data.   I always thought Proc Format was one the hidden gems of data management as long a single variables were involved.  ... View more

@Ok6 wrote: Thanks but error persists. Best practice for this forum is to show the code and any messages from the log. Copy the text from the log starting with the code statements submitted that are having an issue through the end of all of the messages associated with the code. On the forum open a text box using the </> icon that appears above the message window and paste the copied text.   The text box is important because the software running the forum will reformat text pasted into the main message window that sometimes reduces the readability or completeness of the diagnostics that SAS often supplies.   In the case of "file doesn't exist" type messages common problems are spelling , case of text, actual location of the file such as attempting to use a local to your computer file where the server running SAS cannot see it. If you show the actual code and messages we can help better. Also, it would be better to start your own thread instead of adding to an older thread. The creator of the thread has options available such as marking an answer correct that others do not. If you do start your own thread you can post a link to this one to reference what has been done so far.  ... View more

Since it sounds like you need to mark multiple observations (not specified how) it would likely take two or possibly more passes depending on other rules using a data step.   I can come up with at least two different meanings for " flag IDs not in (1st line) that have at least one "Other_trt" entry = "Y". " It would be a good idea to show the desired result to make sure any interpretation we use would be correct for the problem as well as showing the value(s) of any flags set.   Note that there quite a few places where using a numeric 1/0 instead of text Y/N or True/False are much easier to deal with. For example, SAS treats numeric 1 as True or Yes and 0 as False or No so you can SUM a number of values and get the count of Yes values. And the result of a comparison is returned as 1/0  so you don't have to add in logic to assign Y/N. A format can display the text value of "Y" or "N" or other text as desired for reporting for people to read.   If this were my problem I would likely use a separate step with either Proc SQL or possibly Proc Freq to get the desired counts of Other_trt values and merge that result with the DB data set by ID values to add in that Flag. ... View more

The warning is coming because you have a value of your macro variable College_id of "A&S" in this line: proc export data=caa.usf_college_sort(where=(college=%bquote("&college_id"))   I am not sure that the picture of the log that you show actually represents a run from the code shown. There is a bit of text in the picture that reads: " MPRINT (CAGOAL) :   WXLX;  " just before the Run statement for the Proc Export. There is nothing that you show in the CODE that would generate any such.    So perhaps you have a timing issue of the shown log and the code executed where this picture is from a previous run OR the macro wasn't recompiled after a change.   I might suggest closing SAS and restarting and then running the code, possibly  with a reduced input data set to just include the A&S. If you still get the warning then show us the entire log, pasted into a text box just like the code was, including where the macro is compiled. The suggestion of a reduced input data set is to reduce the amount of log needed.  ... View more

@Kurt_Bremser wrote: Save to a CSV file and read that with a DATA step. Both the "real" and character datetime values will appear in the same format, so you can read them with the E8601DT informat.   Disclaimer: I tested the "save to csv" with LibreOffice on a Mac, but I sincerely hope MS Excel will do the same.  Used to have to do this about once a week with my last job and Excel save to CSV usually worked except in the pathological cases of one data source that would have a column with cells that were formatted in Excel as currency for part of the column and then dates for the remainder. In which case the solution was to set the entire column of the Excel source to the proper appearance before exporting to CSV.   ... View more

Where is the Macro related code that you ran? I don't see any.   If you are setting the NONOTES and NOSOURCE options then you will lose much of the diagnostic information needed to resolve issues that may be causing problems.   The note about the quoted string in the following indicates that somewhere prior you would likely have had a mismatched quote and the code parser isn't processing things as you think they are.     1 OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK; 2 TITLE; NOTE: The quoted string currently being processed has become more than 262 bytes long. You might have unbalanced quotation marks.   In addition to using options NOTES and SOURCE for debugging you may want to add the option MPRINT show the code actually generated by macros. If you are doing moderately complex macro variable manipulation then SYMBOLGEN is a good option to add and if there are issues with macro logic, i.e. %if that misbehave, add MLOGIC to the options before running macro code.   ... View more

Did you download zip files of text or of SAS data sets? I think that if the file contains SAS data sets then unzip and create a library pointing to the folder where the files were unzipped would work.   If the zip contains text files to read then unzip and use the programs to read the files that were likely at the location you downloaded the data sets. ... View more

Remember to create a library other than work to store the resulting imported data set or you will have to re-import the data.  ... View more

@NewUsrStat wrote: I really do not know because only the catalogue was passed to me and the instructions you read were given. I have no access to other codes. There is a step that you may want to add to this process. SAS Catalogs are usually version dependent. That means that it is possible that an upgrade to SAS will make the current catalog unreadable. Once you have that catalog responding to the FMTSEARCH option you may want to us Proc format to create a data set of the format definitions using the CNTLOUT option. Then at a later date you can rebuild the catalog for a different version using Proc Format and the CNTLIN option pointing to that data set. Having the data set may also be helpful to answer questions about the actual behavior of the formats.   Proc format library=somelib cntlout=alib.formatcontrol; run; For example will read the catalog named FORMATS, the default name for a format catalog, in the library that has been defined on your system as Somelib and write the contents to a data set named Formatcontrol in the library defined on your system named Alib.  You likely want to write the data set into library other than work for later use. The exact library is up to you. To recreate the formats use: proc format library=thatlib cntlin=alib.formatcontrol; run; The above code will create the formats in the library named Thatlib, which would need to be added to the FMTSEARCH path to be usable.   Suggestion: I would provide such a control data set and the proc format code instead of catalogs. That way things like operation system dependencies and versions are minimized.   ... View more