Kurt, I am amazed would expect you to direct to the OS level for those things. ... View more

pedromagalhaes   You are describing several problems in the organization.  It would be better to try to solve those. Although you are not in the position to do that you could give a signal on that. When that is possible hurting you personally than there is bad enterprise culture. Make your thoughts plans etc. What I am reading. 1- The business/users are programming developing building sas scripts.   No problem for the domain-knowledge for the more real challenging ICT area's a challenge. 2- The business/users want to have flexibility to edit those scritps.   That is release/change management (what version is in Production) and Version management (segregation of developers work). To have there auditable traceable processes in place is a common requirement by regulators.   Now there is nothing. 3- Scheduling is the common operations being productive normally supported by IT staff.   There must be a gap with IT staff as the users want or must do it their self. That can be caused by rigid IT people not wanting to cooperate with the business. Still a gap problem. 4- Scheduling with SAS is best done with LSF (schedule manager) that is not the same as workflow studio.   Mostly IT staff are having their own scheduling and holding off the SAS approach.   5- As the business is running ETL processes why not using the SAS ETL tools for that?   Once there was a product ETL-studio, it is named DI-studio these days. The WA-tool in SAS is even older as it was a predecessor having his own meta-database.                                              ... View more

options dlcreate=yes ; Than use the new folders in namings as you like. They will be create. The challenge is in the retention policy, when and how to delete those. By the way why not asking for xcmd usage? In a compliant environment you are running with your credentials to be auditable and traceable. The only reason for not allowing is that you are seen as a dangerous irresponsible nitwit by the OS admins. ... View more

The gui interface in EGuide will create a VBS script that will call the sas code. Basically it will try to schedule thing in the windows scheduler. The windows scheduler is often closed by desktop-admins.  The response I made is that the Eguide program and project does have options (import send-to) that cannot be used to be transformed in a batch approach. The problem is your are using the graphical part of EGuide and not aware of those limitations.  ... View more

The SAS metadata is working on a dictionary. Records / fields with their related DI code. Having all those relations there is an impact analyses under your hands. Within SAS installations there a Workflow Studio tool.  SAS(R) 9.3 Intelligence Platform: Overview    What are you adding/changing to that? ... View more

When you are using Eguide and have embedded tasks that rely on the Eguide own local interfaces to Windows (import/export) you have an issue as they cannot be exported as to be run as independent SAS code. Scheduling is based on sas-steps that can be run on their own.  Not terminal no keyboard no desktop interfaces.. ... View more

1/ The x cmd usage will return a message that a command had been fired to the OS. It tells nothing about the correctness of the command execution. The pipe command will give more info.    2/ Running that on a local SAS system there is no xcmd blocking setting as it is your machine on your credentials.  On a server there is commonly that xcmd being blocked as it not your machine and the IT guy. that one not there, is dictating what you can do. That is the default sas configuration setting.  (scripted - metadata). 3/ running local with drive letters is completely different to running on server (other machine other context) all namings will be different whn they are possible. Do you have all tree of these to overcome?   ... View more

You autoexec prompt is one coming from the autoexec flow in Eguide. That one is living interactive with you Eguide project start. Scheduling batch jobs on a server is about organizing your code on the server and have that run on your server. As your seever administrators for support in that. ... View more

Quentin, No problem for having patience for continued discussion...  It is learning from all more sides, I will still learn some things. Challenge 1.  Recognizing a sas session has been killed abended unexpectly. As any log can get lost premature there is very little trustworthy information. In an interactive session it is a flash the user will complain. In a background process how?     This one is solved by schedulers (eg LSF). They are having a database registrating the pid and the moment the process was spawned. When it disappears it is an unexpected abend.  Suppose you want to build that yourself (basically the same logic), than: - use the -initstmt option (sas-code) to store in a sas-dataset that time and pid process was started in a known location as the first record.   You will know it has started as the initstmt is executed in the wanted sas program context. - use the -termstmt option (sas-code) to store in that sas-dataset time and and pid and status when the process has ended as the second record in the same sas-dataset - Have a list of which programs has been started and where that known location is. You can verify in a regular time interval whether:    + jobs are running That is one record in the dataset and the process pid still exist in the system    + jobs are ready as both records are existing. As filling the dataset is done with sas. SAS processing did not stop for some reason.    + Job abended prematurely. Onely one record exists and the pid is gone. As the checking is done by a separate SAS process that one can do the mailing for alerts or whatever. The sysrc status and all others are known so reacting on that is also possible. Challenge 2 What to check?  There are a lot of basic settings as in SAS(R) 9.4 Language Reference: Concepts, Fifth Edition But these of SQL are to be added SAS(R) 9.4 SQL Procedure User's Guide, Second Edition see also the automatic macro variables that are giving more of those error conditions. As a not-surprise those errorcheckings are not rock solid. Teradata bulkload for example is using creating errortables and will not return some errorcode to proc sql. Instead you have to check the existance of some table.     For SAS/connect it is the sysinfo SAS(R) 9.4 Macro Language: Reference, Fourth Edition that is in the remote session (%SYSRPUT) to be retrieved. As those approach is involved likely on another system. collecting logfiles is more troublesome.    Challenge 3 I agree it is very troublesome to do the same as the DI generated code by adding macro code before and each block of sas code. Suppose you are having the goal of generating some dataset (report). You could clear that at the start of code (instruction to the programmer/developer) and check that at the end (instruction programmer developer).  The checking should be done by macro-code as that will still be executed although sas processing has stopped (Syntax processing mode).   The fool proof approach would be default status by "in error" and have that set to "ok" when that last validation says so.  In reality you have to accept the default of "OK" status and set it to "in error".        Challenge 4 Will this check everything? Of course not. I do not know how to check the program was functionally processed correctly. You can put in wrong bad data and it can run technically correct delivering rubbish. There is your limitation of the level you can do. Protecting against wrong data is a programmer/developers job to be validated by testing.                           ... View more

Joe, that commit will work automatically wit SAS when the connection is setup in mode=Teradata. When sharing Ansi modes tha do not share those session settings ... View more

Quentin, That was my start with the SAS-log any log also. My first job was statistical programmer.  At some point I reverted it all. The reasoning:  - Any log parsing that can be made will have some failure as it is coding. With changing releases you have to maintain verify and do more things. - with changing releases error checking and the recognition of those will change by the supplier (SAS) It is hard work (regression testing) to verify all things that went well in the old situation still work in the new one. The real question is whether the program/code did the intended work correct.  That is (A/B) testing.  The flipping change of view: Is there something to be found on that correct result, I test that one. And when found the result is incorrect  and the RC is accordingly than correct the RC as it is in error. There are that many possibilities for something to go wrong that checking the correctness is a more easier approach.   For the statistical background it is more easy to calculate the probability everyone has a different birthday the to calculate all options of some people sharing a birthday.    There are some uncertainties in those let us call them p-values as not everything is verifiable. What is the probability of not seeing the incorrect situation by validating in some way and was is the probability of missing that by analyzing some log. And what is all involved cost with that when needing to correct those. That is after the development  stage and validating the quality of the code. (D,T,A)  And with that validation of code some checkpoints on being solid enough (no not rock solid) to run as much unattended by others.    All kind of algorithmes being supplied (SAS system() the hardware OS etc are assumed to reliable and only when there is some indication it could be in error more investigation is done.  Still a lot of work on those investigations were many of them are resulting in conclusions impossible to be prevented/recognized by log-parsers. For example could you imagine seeing a dump with a semop java call in a saslog.        ... View more

Quentin,  look at the several logconfig,xml files that are arround. A part of the batch server:  <!-- Batch File Appender, match the output log file name to the input -log statement --> <appender class="FileAppender" name="BatchFileAppender"> <param name="Append" value="false"/> <param name="Unique" value="true"/> <param name="FileNamePattern" value="%S{App.Log}%d{yyyy.MM.dd_hh.mm.ss}.log"/> <layout> <param name="ConversionPattern" value="%m"/> </layout> </appender> What you see is the log file is created with this to support the date/time settings altoudh it will be place in the current dir is of that batch proces. A part of tracing the connec server (similar workspace server): <!-- Rolling log file with default rollover of midnight -->    <appender class="RollingFileAppender" name="TimeBasedRollingFile">       <param name="Append" value="false"/>       <param name="Unique" value="true"/>       <param name="ImmediateFlush" value="true"/>            <rollingPolicy class="TimeBasedRollingPolicy">          <param name="FileNamePattern" value=" ***/log/SASEMCS_%d_%S{pid}.log"/>       </rollingPolicy>       <layout>          <param name="HeaderPattern" value="Host: '%S{hostname}', OS: '%S{os_family}', Release: '%S{os_release}', SAS Version: '%S{sup_ver_long2}', Command: '%S{startup_cmd}'"/>          <param name="ConversionPattern" value="%d %-5p [%t] %u - %m"/>       </layout>    </appender> What you see is essential a altlog function with all dynamic date/time settings and a buffer flush. Following programs is possible that way. Logparsing can still be done on those. As the questions what to look for is not really determined  ....  Mostly used for looking for the evidence some proces had som weird abend.          As of your remarks Is see oor different history. Educated as "Systems programmer" the job was wiht a lot of others on the technical area for the process of programmers/testers/expoitation. A real OS has good logging capacitties MVS wiht SMF did come really far. Performance, capacity cost usage secuiryt and errors aside other loggings as in SDSF SYSlog etc.. Collecting and processing is a BI analytics approach. At Windows and Unix those are missing. So it is undestandable coming form different areas we have different viewpoint. For exploitation the processes should be clean (notes warnings error) and the RC being the only to be trusted setting (schedulers). The developers should deliver the code that way. The testers (system-intergration acceptance) validating those reqs. With that no logparsing is necessary.    I have seen all similar kind of activities of building something as devlopers becaus they assume they are needing that although most of it is already availabel in some other way but kept hidden (the untold options).    ... View more