AI suggests CDE is typically running in a container, so you may need to set the umask when you start the container.  You might want to have a chat with your favorite AI and describe your CDE / Viya setup, and/or call tech support and ask how to set the umask. ... View more

If you're using a service account, I would think setting the umask for that service account would be the best solution, as you suggest.  I'm not on Viya, so can't test. ... View more

  @clinyun wrote: Please see: PPI - The Pharmaceutical Proceedings Index, we found this old paper for you. That's great to know that web archive did capture some of the old NESUG papers that lex hosted himself.  That makes me optimistic that it may be possible to recreate his full index. ... View more

So glad you were able to add the videos!  That's impressive.   Yes, our older archives are likely missing some papers, and some of our archive links just pointed to lexjansen.com, so we'll have to remove those links.   Yes, I've heard the same about Lex digitizing papers himself.  He had papers going all the way back to SAS One!  And some of those original papers were gold. The PDV hasn't changed much in 50 years.   In the past two weeks I've probably tried to go to lexjansen.com three or four times, confronted each time by such a loss.  I still hold on to hope that someone will be able to recover lexjansen.com, in time.  But I'm sure Lex would be proud that his absence has left such a huge hole, and members of the SAS community like you are picking up the mantle. ... View more

You might try something like zipping the pptx file before emailing it, if you suspect it's getting corrupted by SAS or your mail server.   Maybe that's a silly idea, since pptx is literally a zip file.     You could try changing the extension on the .pptx to something neutral like .txt in case your email system has blocker on sending .pptx files.   If you have IT support, you might want to check with them to see if they can see if the mail server logs say anything interesting.   I guess it's possible SAS somehow munged the file during upload.  If you do a simple .pptx with just one slide from PROC PRINT, does the email work? ... View more

Cool you were able to crawl BASUG.  If you dig deeper into it, we do post slides and papers linked in our archives, and also videos from our webinars since covid.  Not sure how easily searchable it all is (website is made by Wix), but if there's a way BASUG could be sharing the data better, happy to try! ... View more

@mdsaraiv2 wrote: Thanks Kurt_Bremser,    Yesterday I got it. In my old computer I used to read data from harddrive without  any problem. In that computer optplex from 2000 all my usb front ports were equal so I never pay attention to that.  In this new one the front ports are all different and I stick it in the lowest capacity. I transfer my data to my computer and it worked fast.   I always say " if the computer is giving any problem 99% I am the problem rsss. But I slowly keep learning.  Thanks a lot!  Glad you got it resolved. I've heard that described as PEBCAK: "Problem exists between chair and keyboard" also PICNIC: "Problem in chair, not in computer." 😀 ... View more

@Linkachu1 wrote: So sad to hear about this! That website has been essential for me. Can anyone find this paper? "Rank Based Alternatives to Normal Least Squares" https://www.lexjansen.com/nesug/nesug95/NESUG95153.pdf That might be hard to find. NESUG went away years ago.  It's possible for NESUG, Lex's site was the only remaining repository.  I hope that's not the case.   When I used the way-back machine to look for some old papers, some of the links worked, but others failed.  I'm not sure if that's because the wayback machine didn't archive them, or if the key differenc is that some of Lex's paper links pointed to other repositories, but some of them he stored himself. ... View more

Thanks @data_null__ , no I hadn't noticed the different variable type.     Reading data from Excel is such a horrible experience in general, but I've been mostly happy with the guesses made by Henry Feldman's XLSX engine.     This is an interesting/surprising bug.  I wonder if he would accept it as a bug, or think otherwise.  Sadly he moved on from SAS several years ago, but hopefully they've still got others who can dig into the source code and see what's going wrong.   AI thinks the xml value which is a numeric value with trailing spaces is not allowed in the spec, but I don't know if that's the ISO spec or Microsoft's additional specs, and don't want to dig in more. Regardless, even if the xml is a bit odd / malformed, Excel is happy with it but the XLSX engine is clearly doing something bad when it reads it in.   I wonder if @Chevell_sas would be interested in looking into this. ... View more

Gotcha, so the AI was wrong.  : ) Did you try the explicit pass-through recommended by the AI?  It looks believable it could work, but it could definitely be wrong twice...   The other obvious hack is to convert trailing spaces to '*' in SAS, then push to SAP, then on SAP side convert the '*' back to space.   What you really want is a preserve_trailing_spaces option in SAS, for when it pushes data to an RDBMS.  But I don't know if that exists.  If not, could be a good product suggestion. ... View more

Okay, I took a few more minutes to unzip the excel files and compare the xml.  It's Friday.   Even though Excel is not displaying the trailing blanks, it's storing them in the xml.  So in the xml, you character value is really 200 characters long in one string, and 199 characters long in the other:   <c r="A4" s="2"><v>-100 </v></c> <c r="A4" s="2"><v>-100 </v></c> I guess you could argue it would be nice if  PROC REPORT or ODS Excel would trim those trailing blanks before writing the excel (.xml file).   That said, since the value stored in the $200 excel file is a valid value, it does seem like a bug in the XLSX engine that when it reads '-100' followed by 196 blanks, it somehow becomes '-1'. So worth following up with tech support.  Please share the result! ... View more

This looks buggish to me, but I can't tell if the bug is in PROC REPORT and ODS EXCEL, or the XLSX engine.  And I'm out of time playing this morning...   By eye the two Excel files created by length $199 and length $200 look the same, but clearly they are not exactly the same because SAS is reading them in differently, and truncating the data when it reads in the Excel file that was created from a $200 variable.   So there must be some difference in the Excel files.  If I had more time, my next step would be to unzip the xlsx files and compare the xml files to see where the difference is.  Or maybe someone better than me with Excel can spot the difference just lookin at attributes in excel.   Here is my test coded that replicates the problem.     Interestingly, if the ODS EXCEL block if I change from PROC REPORT to PROC PRINT, everything works fine.  That's odd, and another clue worth following up on...   %let workpath = %sysfunc(pathname(work)); %put workpath=&workpath.; data x199; length x $199 ; x = '-1'; output; x = '-10'; output; x = '-100'; output; x = '-10'; output; x = '-1'; output; run; data x200; length x $200 ; x = '-1'; output; x = '-10'; output; x = '-100'; output; x = '-10'; output; x = '-1'; output; run; ods listing close ; ods excel file="&workpath\x199.xlsx"; ods excel options (sheet_name="XXX"); proc report data=x199; format _all_ ;run; ods excel close; ods listing ; ods listing close ; ods excel file="&workpath\x200.xlsx"; ods excel options (sheet_name="XXX"); proc report data=x200; format _all_ ;run; ods excel close; ods listing ; libname x199 xlsx "&workpath\x199.xlsx"; libname x200 xlsx "&workpath\x200.xlsx"; data _null_ ; set x199.xxx ; format _all_ ; put "length=$199 " x= ; run ; data _null_ ; set x200.xxx ; format _all_ ; put "length=$200 " x= ; run ;  Returns: 1286 data _null_ ; 1287 set x199.xxx ; 1288 format _all_ ; 1289 put "length=$199 " x= ; 1290 run ; length=$199 x=-1 length=$199 x=-10 length=$199 x=-100 length=$199 x=-10 length=$199 x=-1 NOTE: The import data set has 5 observations and 1 variables. NOTE: There were 5 observations read from the data set X199.xxx. 1291 1292 data _null_ ; 1293 set x200.xxx ; 1294 format _all_ ; 1295 put "length=$200 " x= ; 1296 run ; length=$200 x=-1 length=$200 x=-1 length=$200 x=-1 length=$200 x=-1 length=$200 x=-1 NOTE: The import data set has 5 observations and 1 variables. NOTE: There were 5 observations read from the data set X200.xxx. ... View more

AI suggests changing your SAP field from varbinary(16) to binary(16), in order to preserve spaces.  That seems reasonable to me.  I wouldn't expect a varchar to preserve trailing spaces, since the point of a varchar is to avoid storing trailing spaces.   AI also suggests you could try doing inserts with explict pass through, where you do native SAP Hana inserts that will (hopefully) preserve the spaces.   Untested AI  (Gemini) generated code: /* 1. Explicitly select from HANA and write directly to WORK using Pass-Through */ proc sql; connect to saphana (dsn=PDWDM authdomain='P-USER'); create table WORK.AAG_STAMM as select * from connection to saphana ( SELECT AAGS_KEY FROM Z_AGA_BASAA.AAG_STAMM WHERE AAGS_KEY = X'0000BD0A4D9C33FB7F08000001779C20' ); disconnect from saphana; quit; /* 2. Explicitly write back to HANA via Pass-Through using host variables */ proc sql; connect to saphana (dsn=PDWDM authdomain='P-USER'); /* Using native pass-through insert to protect trailing binary spaces */ execute ( PREPARE ins_stmt FROM 'INSERT INTO UPW_EGUIDE.AAG_STAMM (AAGS_KEY) VALUES (?)' ) by saphana; /* Execute the native pass-through using your temporary SAS dataset */ insert into connection to saphana (ins_stmt) select AAGS_KEY from WORK.AAG_STAMM; disconnect from saphana; quit;         ... View more

SAS will always store character variables in blank-padded fixed-length variables, so when you export it SAS is helpful enough to trim the trailing blanks.   Are all of your keys a fixed length?  If so, I would think it would be possible to tell SAS to write them back with the padded blanks.  Could be as easy as specifying a format. Or as a hack you could add a '*' at the end when you read in the data, then strip the '*' after you write the data back to SAP.   Can you show a small example of how you write the data back to SAP? Is it a pass-through query or similar?   This might also be a chance to use the newish varchar variables available in the DATA step, because varchars don't pad values with blanks:   1 data _null_; 2 length varchar_var varchar(20) char_var $20; 3 varchar_var = 'foo'; 4 char_var = 'foo'; 5 put varchar_var= hex12. ; 6 put char_var= hex12. ; 7 run; varchar_var=666F6F char_var=666F6F202020 ... View more

@ChrisHemedinger wrote in part:   AND, we know that the AI experiences (AI summary in browser, chatbots, copilots) will surface answers from this community -- which is something we are proud of...though it makes it more difficult to measure. Indeed.  @data_null__ asked an interesting question in July about DOSUBL and PROC SCAPROC.  A few hours after he posted the question, I went running to google (not Gemini), and the AI summary from search already returned a response based on thread that was only a few hours old.  I was shocked.  Didn't realize how quickly they were hoovering up information.    Thread: https://communities.sas.com/t5/SAS-Programming/PROC-SCAPROC-stops-recording-when-I-call-my-macro-that-runs/m-p/989146/highlight/true#M380166 ... View more