Thank you very much for the hint. Working from home I've just the company laptop's single screen, but I'll try to take profit of the new windowing ways given by Windows11. At the same time, I can't avoid to think that SAS/EG developers shouldn't refer to a possibly absent multi-monitor/multi-window capability, hopefully re-introducing the original ability to manage such boxes in the current single layout: I'm missing some things from the old v7.15, like the ability to right-click whichever task to directly take a look at its own SASlog (this item have been inexplicably removed from the contextual menu). Sure EG8.3 is a good leap forward, but it left behind some useful features nonetheless. Speaking of added features, I was hoping they added the ability to open multiple projects in the same session. Just a nice to have, as we 're able to open multiple parallel sessions at the same time (but I can imagine environments where such sessions are reduced to just one: there, a multi-project ability could be of great help).   ... View more

(must add as a reply to myself, as I can't edit my original post)    Update: inspecting the problem better, it seems it's related to local client only (and even not all local clients too).  By opening my EG project using the web interface, via Citrix dashboard, and using the Project Management to modify the application server in all the tasks at the same time, this problem don't arise.    The same: a colleague who is supporting me in the migration, reported me that, even using his locally installed client, opening my project and using Project Management, didn't incur in that bug. He have not been able, tho, to tell me which configuration setting to look at (and, possibly, to change) in my local client, to avoid having such problem.    To avoid spreading unuseful alarm, I tested such behavior on my migrating project (one project only, for the moment) multiple times.  I hope this update at least help who fell in my same pit. ... View more

    Hi Chris and all,   TYVM for the ballot's link but     that thread is now locked (probably 'cause Ballots "evolved" to something else)   don't you feel is it enough time, for a feature requested by many customers (as it's useful for sure, no doubts) to be still not present since Sep 2007? Are not 17 years "enough" to add a flag into EG's Tools > Options > Project and Process Flow section?   to all what other customers mentioned already, I would add another good reason why we (really) need to be able to turn that flag off "by default" even before than to open a project (which means in the .egp file's properties or, as it was told already, have it already turned off so that the opening project won't automatically switch it on): I'm migrating some projects from a SAS application server to another. A step I need to perform is Project Management: given my projects have all the AutoArrange turned off at migration start, when the Project Management works on them, to adapt to the new application server, it also switch the flag on (which, I believe, it's nothing else than a BUG😞 at that point it saves and reopens the project, so I've NO way to turn the flag off before the "feature" totally re-arranges (scrambling them) all my tasks (and that in ALL the workflows, not in the first one only).   If the AutoArrange worked well it wasn't that Big Problem... but it doesn't! What I'm seeing is tasks moved to the wrong positions, and we all know that, in EG, the tasks execution order IS positional.   Last but not least: if the problem involved the first workflow only it was (still annoying but) bearable, but it's NOT that way you told, sorry to say: I turn AutoArrange OFF in the 1st workflow, only to discover it's already ON in the 2nd (which then becomes totally scrambled... I'm speaking about a workflow having 50-60 tasks, to manually re-arrange... not exactly 10 minutes, and the project have like 10 workflows). That's a BIG problem, to us.   Such Big Problem could be avoided totally just adding a "global flag" in the Options, so that an "incoming project" I upload (or a new project I create) have such flag set to OFF and remaining OFF 'till I'll manually turn it ON.   I believe, in 17 years, one can program such "monster change" into EG without too much problems (but saving us to have them).  Thanks for reading, I would prefer to have updated the ballot's thread but, as I told, it's locked.   ... View more

So, if a (paying) customer recently switched from EG 7.15 to EG8.3 and the company is not going to use Viya, all we have, here, is "Status changed to: Suggestion Closed Thank you for your product suggestion for SAS Enterprise Guide. We are looking at further enhancing integration of SAS Enterprise Guide with SAS Viya 4. We don't have any plans for adding any other new features in the foreseeable future."?   At least I hope SAS will make features backporting, so that a customer can take profit of improvements. Pretty sure I'll remember that, when it will be survey time.   Also, I'm speaking about some extremely useful "gone features", like tasks' log (per task, not in the Submission Status). ... View more

Great hint, Chris, saved my day! ... View more

Thank you very much, all, for the quick answers and solutions (I was struggling on that since two days): all answers have been very useful (as always) and yes, I previously saw the EVENTDS thing but, to be honest, I didn't know how to manage it and figured out how to write a small "perpetual calendar" (which gives previous, current, and next year's holidays: 39 obs at all) taking a millisec to update every time I launch my EG project, (while I'm not sure I can "write our local holidays somewhere" into a dataset read via EVENTDS: I probably have to ask This and That department... I'm not sure: it's not that clear, here, who manages what).   So, at last, and despite Quentin's comment ("not suggesting you use this approach for this problem"), his suggestion seems saving my day: I tried it on my Festiv_ITA full calendar and it works as expected there too.   I'm going to apply the same logic to a PrevLabDay() macro too, which is giving the same problem since I enabled it to work with isHolidayIt(): while it was working with isWeekEnd() only it worked like a charm (and now you explained the reason behind).   I was nearly modifying my code, to make it use of &rc global var instead (so that my colleagues, which are working at the data side, can go forth), but I'll implement the DOSUBL suggestion, now, and will give a look into EVENTDS things, later, as it's probably a better/more robust way: even now I'm basing on holiday('EASTER'), which is luckily in common with non-ita-custom holidays (GREAT luck, as it's a variable holiday date, "base" for two other holidays here: all others are fixed ones and can be summarized with 10 datalines). ... View more

@ballardw  If you don't have direct access to SAS tech support your SAS Admin really should. Correct.   You description involving what appears to be multiple data sources gives me headaches just imagining all the places things can go wrong. At least, this is a batch project, so user-input is really to the minimum.   Something you might be able to look at. When you say that running the system manually goes okay then I would investigate ALL of the SAS system options used for the job. You might find one that is more related to batch processing that terminates when minor problems are encountered that a more interactive job doesn't (your Exceptions perhaps). I don't use EG so can't point to specific ones to look for involvement. The "exceptions" are not system-side: they're recognized data which we lack the rules to manage: we choosen to export such data into separate files, so that our customer have a chance to tell us what to do with them (or even to insert such rules by his own: we left config files available to them for this purpose).   You may also consider turning on as many of the log options, like Fullstimer and connection diagnostics to see if the job SAS logs would point to bottlenecks or suspect areas. I'm using "OPTIONS mprint mprintnest mlogic mlogicnest symbolgen syntaxcheck autocorrect fullstimer source stimer threads" in production environment (batch scheduling), is there anything more I should enable?   I can certainly understand the frustration. I am "the client" for a process where a data provider has to write one file to our secure FTP server. We didn't get any files for 5 months. It took that long for my ID side of things to realize the reason the provider couldn't log into the server because their system passed through and international server and our SFTP was configured to block all such. 5 months because our IT was that slow on "tracing". Our main problem is our IT Support is tracing nothing at all: they're also not answering in a viable way (AKA giving solutions) to direct inquiry (tickets): we're probably go escalate the solutions search to higher structure levels, as the fix seems far outside our action's perimeter.   @SASKiwi Thanks for your words, we're going in that direction too (hopefully), but it's not just a technical choice: we had to set a budget for that "improved support" level, by one of our departments (as our group have an IT dept. which is a company by its own, like it happens frequently, with large companies/groups). AFAIK such IT dept. uses SAS Management Console and related programs/scheduler, which should be an higher level than our current.   [EDIT] I forgot to add, in my reply: I (re)opened this thread mostly to understand if the EG error was only about "data it can't read" or involves the "code to be executed (by the engine)": the error also states "Unable to get SAS code". I would like to have a deeper insight on it, if possible (even reference links, which I still have not found). ... View more

    Hi @ballardw and TYVM for the quick reply,   You may have to look for an environment change, not just a SAS code or SAS setting change. In the world of clients and servers anything with an impact on the server can slow other jobs. Such as adding another program not related to this process at all that uses either the server or network bandwidth or storage space. I would ask the IT management if any programs were added or modified that use the SAS server or what ever systems generate the files you need to read daily.  We know for sure our IT is "working more" on the traditional-Host-to-SAS side, since some time (a month or two): our company data stay into their usual Host/DBMS (DB2, Oracle, etc.), to get worked on by IMS and CICS accounting transactions but, since some time, they're also copying previous-day "final output" data into SAS data-lake (so Teradata, Hadoop), so that we can access them via EG projects: such workload (which I've no idea at which times it's happening) sure encumbers SAS "servers".    I call them "servers" but they can be whatever: from a cluster of usual linux servers, to a cloud, up to host-grade ones, still running Linux. I'm very far from the IT architecture, so I've no idea about which machines are they using, to run SAS engine(s). For sure they're using Linux as it's reported by EG, while our EG-Scheduler doesn't use classic linux cron but relies on Windows Task Scheduler (so a vbs program launching EG and passing the path/projectname to execute, along with user/password to open an EG session for the project). Even for sure, the IT dept. working on SAS is not small, and they're using many machines, just I've no idea which grade they are but I doubt they're classic "servers".    So "to ask the IT management" it's totally not easy at all: I opened a ticket to our HelpDesk, which escalated to some "SAS IT" but the most they answered was: 1. try scheduling in different times (giving us no clue about which hour was to better use) 2. try segmenting the Big Project into some smaller chunks, which sounds like passing the buck back to our hands without giving any objective hint on the problem (and which could take some months, also considering there is no way to "arbitrate" the various chunks, via WTS, which "just executes" but don't "manages")   My complete guess could be that there is something delaying the creation of the files you use but the ones from the previous cycle are available. So the SAS end starts normally, using that previous data, and does what it is told. I've the same feelings: the error seems generated by some "timeout" which could happen between SAS engine and SAS-EG, 'cause the engine is too much delayed by other heavy jobs, but that's my feeling only: I've no evidences, can't have them directly, and our HelpDesk didn't give any back.   You didn't actually describe what was received in stead of "cause expected data have not been delivered". Has your customer mentioned, or been asked, if the data delivered was identical to the previous day's data? If so something in your system is introducing either a delay on generating the "new" files in time. So, in brief: nearly everyday (on need, but often) our customer fills in an Excel file we left into his "input folder" with some contract-codes they wants to be "deep-searched" (24 months from today()) into our transactions (we're anti money landering dept.), the extracted transactions are given, raw, splitted into previous/current years (2 files), then we also group them in 4 different ways, as asked by the customer: such process outputs, starting from the single account-code, 7 different files. Contract codes are usually from 3-4 up to 15-20, so we're having 20-30 up to 140 output files per day, depending to the input. All, up to when there was no errors, was done in 30-40 minutes so, around 2am, all files was ready: our customers (colleagues) start working ar 8am so it was all good, to them: they moved the output files into their own folders and the process was going smooth everyday (there are some "exceptions" which we're taking care, producing 2-3 output "exceptions-lists" but that's a side thing, having no real impact on the process). Files are named after their contract-codes, so no problem about overwriting them too.   Nowadays, with the error plaguing the scheduled project (but very rarely impairing us, when we execute it by hand, during the day!), in the morning our customer see the output folder empty ,if errors happened in the core-step, where data preparation is made for the following grouping ones, or they can see some files only, if the errors, which happens totally random, even when we schedule the process 2 times (1am and 3am), e.g. all codes generated 1st, 2nd, and 4th group-by data only, but all lacks 3rd grouping, etc. For example, this morning 1am run on 6 codes produced the 2 years raw data (2 files), got error in 1st and 2nd grouping, produced 3rd and 4th group data (6+12 files), plus the exceptions ones (total 22-23 files, exceptions included). So, when my colleague arrived at office, he have been asked to manually rerun the project: he did, and EG produced the whole 54 files (49 grouped data + 2 raw yearly + 3 exception lists). The fact, when lanched manually, the projects works seamlessy brings me to the point that there is no error, in the "application layer": the error (delay, timeout) is underneath, in the engine or DBMS layer, more probably: where we can't put our hands at all.   You may want to contact SAS tech support to see if they can help you generate better diagnostics to see exactly what is happening in your system to isolate relevant issues. I've no direct access to SAS tech support, AFAIK. I'm trying to ask to some IT colleagues I know but, as I'm not their "direct customer" (no contract, no budget, to them) they may give me a favor, to answer, of even won't: not their problem.   ... View more

Since foundation SAS and the basic SAS data set supports exactly one type of numeric value then that sort of conversion "help" isn't really helpful. It means CAST() could be helpful in some other scenarios too? (where more data types are supported, I'm not aware of what all SAS products data type support)   The internal conversion implied by Casting character to numeric is apparently a poor subset of the SAS INPUT function, at least from a brief study. I can see Cast to convert a character value like (...) missing values. Which could mean that CAST(), if extended outside (FEDSQL) proc sql to foundation/basic SAS, could be recoded to work better? (maybe nowadays it have not be done 'cause of PUT/INPUT presence?)   SAS formats for PUT and informats for INPUT also allow the designer of the format/informat how to handle Other values My proposal wasn't meant to replace PUT/INPUT by CAST: it should give an alternative, to be used by less knoledged people (like me) which had few luck with company's training, or have given no time to be properly trained, or such: if SAS devs think it could help people (like me, and the many I'm reading in the forums/net) an helper function should be welcomed (it could also reduce the amount of questions about "why I'm getting an error when ...?" usually implying PUT/INPUT conversions).   Side story: from time to time, I've noted that the expert thinks "how things should be" (and they certainly can do, from their high knowledge) but sometimes it could be an option to "just give up (with high theories) and do what (all) the people expects things should be", that even if the experts are right, and all the rest of the people is wrong. Just to give an example: in one of the last OS updates, Apple changed the way "precise (virtual) keyboard input" was managed into iPhones/iPads, 'cause their experts developed an "intelligent feature" which "understood" where the user wanted to place the cursor, when editing a text. That's the theory. Facts are "a bomb exploded", 'cause the "intelligent feature" was placing cursors where they thought a user wanted them... which, many times, was not where the user really wanted, and there was also no more the previous (oh so useful!) "magnifying glass" to help them. I read a ton users whyning in the forums and, as far as I'm seeing, in the last OS update I got from Apple, kind of the old magnifying glass was back: that's pragmatism, IMHO. ... View more

@PaigeMiller TYVM to have shared your thoughts, I know you're right but, as 99% of the workers out here, "I do what I can, not what I want". 😉 ... View more

In short, is to prevent of receiving an error, when a function requires a datatype and one have to explicitly use PUT or INPUT (or both, in some cases):   CAST(num1, string) if "string" variable have been already defined as character, makes CAST() to use a PUT(). It could be even written as string = CAST(num1), in the simplest form. So, in your example, string = CAST(num1); and num2 = CAST(string);   In case string and num2 wasn't already defined, they need a target-type for the definition (unless it's a wanted behavior, to raise an "must be defined before" error), so: string = CAST(num1, $12); num2 = CAST(string, 8); or CAST(num1, string, $12); CAST(string, num2, 8); as preferred   extended format could be: string = CAST(num1, 8, $20); (which pads with spaces, in this case) num2 = CAST(string, 8, BEST8.1); or CAST(num1, string, $20); CAST(string, num2, 8, BEST8.1); as preferred.   It's mostly to avoid, all the times, to have to think (and, at least in my case, usually to fail, getting errors) if to use PUT or INPUT: CAST should be an utility/support function (could be a macro too, which correctly translates to PUT or INPUT at need, together with their formats).   The problem I'm addressing is not that PUT or INPUT are not working well or as expected: the problem is, many of us (me included) are working in SAS while having a few (or no) training on it: I personally have been trained, and with basic training too, after more than 1 year I was actively using SAS EG. That generates a lot of confusion. Sure it's nothing a SAS expert experiments but, as I told, I read a ton of threads where the experts just suggest to correctly use PUT or INPUT so, why keep having (less trained) people, which have to work with SAS with the knowledge they (we) have at the moment, daily struggling with such errors, instead of "just writing an helper function"? ... View more