In WebSphere Application Server 8.5.5 I'm having problems setting the native_stdout and native_stderr log paths from wsadmin jython script.
Everytime I set one path, the other is blanked out. i.e. set to null.
I presume I need to form a line of code that sets both paths simultaneously but have been unable to create the correct syntax, if this is at all possible.
The code to produce one path change looks like:
srv = AdminConfig.getid('/Cell:mycell/Node:mynode/Server:server1/')
processDef = AdminConfig.list('JavaProcessDef', srv)
AdminConfig.modify(processDef, [['ioRedirect', [['stderrFilename', '${LOG_ROOT}/server1/new_stderr.log']]]])
AdminConfig.save()
This works fine but when I then use the same script to set the stdoutFilename, it blanks the stderrFilename previously set.
It seems to make no difference at which point I commit the changes using save.
Any help with this issue would be greatly received!
You're right, even though the manual elsewhere warns that AdminConfig.modify() might append to lists when you don't expect it to. I observed the same thing.
Here's the pattern you want to be safe, clear it out and set both properties at the same time:
AdminConfig.modify(processDef, [['ioRedirect', []]])
AdminConfig.modify(processDef, [['ioRedirect', [['stderrFilename', '${SERVER_LOG_ROOT}/my_stderr.log'], ['stdoutFilename', '${SERVER_LOG_ROOT}/my_stdout.log']]]])
After this, you can do this for a simple verification:
print AdminConfig.showall(processDef)
But watch the output closely as it is not pretty-printed
Related
I have some code which has worked in multiple installations for about a year. Today im doing a small change to a control and then another control seems to have developed an issue. When at runtime im getting a 91 error object variable or with block variable not set.
I therefore looked at the problem line which is: -
If Screen.ActiveForm.name = "frmFoutmelding" Then Exit Sub
so I noticed the name was lowercase. if i delete .name and rehit the "dot" then it shows me i can use .Name but as soon as i move from this line it drops back to .name
I've checked for instances of name and it appears everywhere in the code in different modules but i cant find if i have accidentally defined this lowercase name anywhere?
Googling doesn't seem to show much but i feel Im googling the wrong terms
chaps - thanks for your suggestions - this was the first instance of the lowercase name and searching as Jim suggested didn't reveal anything I'm afraid. What I did discover was that this was suddenly being run before any forms had actually been displayed and so the count was 0. I therefore, did an on error to check the form count and exit the sub if it =0 then if not to carry on with the line I thought I was having issues with.
It's likely that you did create a new variable or property called (lower case) name, or that some included reference did the same. It's possible to use reserved words as variable names in some cases, but it requires taking specific steps.
I would first search your code for instances of name As to see if you created a variable (this assumes you use Option Explicit, which is a must IMO). Then search for Property*name with * as a wildcard.
If those fail you could try unchecking references or components to see if any of them define name. If none of that finds anything, please post back here.
Jim Mack covers a lot of the potential issues. I think another is if you typed a lower case '.name' in association with Activeform at some point earlier in the same code module - the VB6 IDE checks in the current module and uses that to define what case to use. Look further up the same code module (sub or function).
Ultimately, check what changes you made by comparing the old source to the new in a file comparison tool like windiff - you do have backups, right?
I want to set path in Visual Foxpro. In such a way that I want to keep exe file on local machine and data\tables on server. How can I do so?
I personally have never liked using SET PATH, especially if you have many "paths" that your application is expecting to use.. If you have a given table / file in multiple locations that are visible with multiple paths that qualify, you may be getting the wrong table, but you won't necessarily know it since the application just runs as normal, finds a table and continues.
Instead, I would suggest one of a few things. Yes, have your application on each user's local machine, but have the person's shortcut have the "START IN" folder pointing to the path on the server where your data is. This way, your application will BE in the folder where the data resides and processes without issue. If no data is on the local machine, during your startup, you could add a messagebox about ... hey... your shortcut should be set to "Start In" setting to X:\SomeShareOnServer\MyVFPDataPath...
If not that, then another avenue I have used is to have your application during startup, add a property to the "_Screen" object which will NEVER loose scope, and set that property to the path you have the data located such as...
_Screen.AddProperty( "cDataPath" )
_Screen.cDataPath = "X:\SomeShareOnServer\MyVFPDataPath\"
Then, in your code, any of your opening tables or SQL queries, use the path variable PLUS the table... something like
if not used( "SomeTable" )
select 0
use ( _Screen.cDataPath + "SomeTable" )
endif
if doing a query, use similar approach
select ST.* ;
from ( _Screen.cDataPath + "SomeTable" ) ST ;
where ST.SomeID = 123;
into cursor C_TmpResult readwrite
So, although the second option may take more effort, especially on an existing application, the first option to make sure the "Start In" path is where the data is might help.
Again, this is my suggestion as I hate chasing down ambiguous -- sometimes it works, but not others. If I can't find a file, I WANT TO KNOW about it and fail outright.
Your call, your app, your environment. But if you DO use the "SET PATH" command, you might want to make sure you use the ADDITIVE command, just in case there are other settings, such as pointing to the a path for forms, classes, report folders... You run a SET PATH without it, and you kill your other paths...
SET PATH TO "X:\SomeShareOnServer\MyVFPDataPath\" ADDITIVE
Also, if you have any spaces in your path in question, MAKE SURE you use quotes around it, otherwise it will fail finding the path you expect and may cause compile error, such as
SET PATH TO X:\Some Share On Server\MyVFPDataPath\ ADDITIVE
You can use VFP's Set Path command
Set Path To m.lcDataFolder
early in your client startup code, i.e. in your project's "main.PRG".
Where the content of the m.lcDataFolder could for example come from something like a custom "myConfig.XML/INI/TXT" containing the desired string, e.g. \\fileServerNameOrIP\sharedDataFolder
Use 'SET DEFAULT TO' to change the current working directory or use explicit full paths as per the answer by #DRapp.
I am using Rstudio and not sure how options "run" and "source" are different.
I tried googling these terms but 'source' is a very common word and wasn't able to get good search results :(
Run and source have subtly different meanings. According to the RStudio documentation,
The difference between running lines from a selection and invoking
Source is that when running a selection all lines are inserted
directly into the console whereas for Source the file is saved to a
temporary location and then sourced into the console from there
(thereby creating less clutter in the console).
Something to be aware of, is that sourcing functions in files makes them available for scripts to use. What does this mean? Imagine you are trying to troubleshoot a function that is called from a script. You need to source the file containing the function, to make the changes available in the function be used when that line in the script is then run.
A further aspect of this is that you can source functions from your scripts. I use this code to automatically source all of the functions in a directory, which makes it easy to run a long script with a single run:
# source our functions
code.dir <- "c:\temp"
code.files = dir(code.dir, pattern = "[.r]")
for (file in code.files){
source(file = file.path(code.dir,file))
}
Sometimes, for reasons I don't understand, you will get different behavior depending on whether you select all the lines of code and press the run the button or go to code menu and chose 'source.' For example, in one specific case, writing a gplot to a png file worked when I selected all my lines of code but the write failed to when I went to the code menu and chose 'source.' However, if I choose 'Source with Echo,' I'm able to print to a png file again.
I'm simply reporting a difference here that I've seen between the selecting and running all your lines and code and going to code menu and choosing 'source,' at least in the case when trying to print a gplot to a png file.
An important implication of #AndyClifton's answer is:
Rstudio breakpoints work in source (Ctrl-Shift-S) but not in run (Ctrl-Enter)
Presumably the reason is that with run, the code is getting passed straight into the console with no support for a partial submission.
You can still use browser() though with run though.
print() to console is supported in debugSource (Ctrl-Shift-S) as well as run.
The "run" button simply executes the selected line or lines. The "source" button will execute the entire active document. But why not just try them and see the difference?
I also just discovered that the encoding used to read the function sourced can also be different if you source the file or if you add the function of the source file to your environment with Ctrl+Enter!
In my case there was a regex with a special character (ยต) in my function. When I imported the function directly (Ctrl+Enter) everything would work, while I had an error when sourcing the file containing this function.
To solve this issue I specified the encoding of the sourced file in the source function (source("utils.R", encoding = "UTF-8")).
Run will run each line of code, which means that it hits enter at the beginning of each line, which prints the output to the console. Source won't print anything unless you source with echo, which means that ggplot won't print to pngs, as another posted mentioned.
A big practical difference between run and source is that if you get an unaccounted for error in source it'll break you out of the code without finishing, whereas run will just pass the next line to the console and keep going. This has been the main practical difference I've seen working on cleaning up other people's scripts.
When using RSTudio u can press the run button in the script section - it will run the selected line.
Next to it you have the re - run button, to run the line again. and the source button next to it will run entire chuncks of code.
I found a video about this topic:
http://www.youtube.com/watch?v=5YmcEYTSN7k
Source/Source with echo is used to execute the whole file whereas Run as far as my personal experience goes executes the line in which your cursor is present.
Thus, Run helps you to debug your code. Watch out for the environment. It will display what's happening in the stack.
To those saying plots do not show. They won't show in Plots console. But you can definitely save the plot to disc using Source in RStudio. Using this snippet:
png(filename)
print(p)
dev.off()
I can confirm plots are written to disc. Furthermore print statements are also outputted to the console
The following script works, but I need help with one change. Right now using lday serach, and a little utility called GETPASS, this script will pull a listy users, from a specified context out of an LDAP directory, compare their LDAP password, to an unused attribute, If different, add it to the unused attribute called carLicense, and then send it in SHA 1 format, up our google APPS domain, with Google Apps directory sync. The one problem, is that it when it returns the ldapsearch, it works fine with a user in this format:
cn=joebloe,ou=googletest,o=someorg
However, if the usename has a space in it like this:
cn=joe bloe,ou=googletest,o=someorg
the script will fail as it does not know how to deal with that space. In this situations, a single quote, around the DN will solve the issue IE:
'cn=joe blow,ou=googletest,o=someorg'
However, I have tried to alter the script to address this need of mine, and I am failing miserably, please see a copy of the script in Pasetebin below. Any help with be deeply and GREATLY appreciated, as this is currently my only stumbling block to success.
http://pastebin.com/htWxsNXj
Replace the first line of generating result file (in your pasting is line 66) with:
echo "dn: '$RESULT'" >> $SCRIPTPATH/gadspwsync.ldif
If it won't help, don't remove the file in line 75. Check the content, show us the first line, then show the expected content.
I am trying to write a script that automates other perl scripts. Essentially, I have a few scripts that rollup data for me and need to be run weekly. I also have a couple that need to be run on the weekend to check things and email me if there is a problem. I have the email worked out and everything but the automation. Judging by an internet search, it seems as though using Proc::Background is the way to go. I tried writing a very basic script to test it and can't quite figure it out. I am pretty new to Perl and have never automated anything before (other than through windows task scheduler), so I really don't understand what the code is saying.
My code:
use Proc::Background;
$command = "C:/strawberry/runDir/SendMail.pl";
my $proc1 = Proc::Background -> new($command);
I receive an error that says no executable program located at C:... Can someone explain to me what exactly the code (Proc::Background) is doing? I will then at least have a better idea of how to accomplish my task and debug in the future. Thanks.
I did notice on Proc::Background's documentation the following:
The Win32::Process module is always used to spawn background processes
on the Win32 platform. This module always takes a single string
argument containing the executable's name and any option arguments.
In addition, it requires that the absolute path to the executable is
also passed to it. If only a single argument is passed to new, then
it is split on whitespace into an array and the first element of the
split array is used at the executable's name. If multiple arguments
are passed to new, then the first element is used as the executable's
name.
So, it looks like it requires an executable, which a Perl script would not be, but "perl.exe" would be.
I typically specify the "perl.exe" in my Windows tasks as well:
C:\dwimperl\perl\bin\perl.exe "C:\Dropbox\Programming\Perl\mccabe.pl"