- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hello all! This problem is not easy to explain, and I don't expect fast answer. I'm working with automated SAS productions running daily. Programs are running every day and run completely only on specific days to produce reports. Programs which produce reports are in a macro making them running on those specific days. So, programs producing reports are called by %include in that macro. Reports are encrypted with 7zip, then sent by email. When program is run manually, everything is working fine. When it gets automated, it produced the report but it doesn't encrypt it. Because encrypted files doesn't exist, email isn't sent.
Only solution found is to create a 2nd macro calling the encrypting and the mailing after and outside the original macro reading the date to launch the production. I wonder if anyone already had that problem and/or how to solve it without the need to create a 2nd macro for encrypting and mailing results.
Feel free to ask for more explanation, I could put some piece of code, but it wouldn't be really significant regarding to the problem.
Thanks and happy coding!
Marc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I would suspect that it is related to running the 7Zip call in batch that is the problem.
Could be as simple as the different run styles having different search paths so that 7Zip call does not work.
Could be related to verbose options on the 7Zip call. I had trouble in the past with a compression program that was designed to write a status line on the terminal as it compressed the data. (5/10... 6/10... somthing like that). When run in background it made such a long line of junk it broke something. The solution was to simply add the quiet/silent option to the command call so that it did not write out that junk.
With encryption I would check that it is not waiting for the non-existent user to respond to some confirmation prompt. Again check for an option to prevent that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for that inspiring answer, I will investigate few things in my code/log related to your message. I'm just surprised that encrypting works when automated in 2 separated macros, that makes me think that 7zip path is working and it doesn't get stuck in junk... I'll keep you in touch with result, thanks again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I use a 'call system' for encrypting with 7zip, I don't know about encrypting with ods package but I will check at it, thanks a lot for the idea!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I suggest you compare the values for the SAS system options XWAIT and XSYNC between your batch and interactive SAS sessions. Both of these change how CALL SYSTEM behaves:
proc options option = (xwait xsync);
run;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I will check what happen with option xsync, I use usually set options to noxwait, I suspect that it could be something as simple as that... What ever I find as interesting result, I will share!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
@marc11235 wrote:
I use a 'call system' for encrypting with 7zip, I don't know about encrypting with ods package but I will check at it, thanks a lot for the idea!
I would avoid using CALL SYSTEM. Use a PIPE so your program and read the messages that the command generates.
data _null_;
infile "command you want to run" pipe;
input;
put _infile_;
run;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Very interesting, I can't wait next day to start trying things! It feels like the break time will be busy about trying! Thanks Everybody for all good ideas, next step is to understand what happens and fix it properly, not to just make it works with a patch!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
When you use the PIPE method (recommended), add
2>&1
to the end of your commandline. This reroutes stderr to stdout, so that the INFILE can also catch error messages which might otherwise end up in the big bit bucket.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Sorry I been very busy probably like most of us, but I want to thanks everybody for support. I saw a few times the 'maxims' document rolling around, I will definitely read it, and if it is not one of them, I would add to sleep a day on the problem if you get stuck, fresh ideas will appear! It may takes a few days but I will get back with more details asap
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content