I’m having a problem with an agent on SLES8 with the Workload Scheduler. The first JnextPlan works fine, but the second fails, with conman giving an error. How can I do?
I think the library ligcc_s.so.1 is missing on the agent workstation. This is a library and usually it should be located in /lib. Try to look for it in other directories such as /usr/lib. When you have located it, make a soft link to it from the /lib directory and rerun JnextPlan.
If you can’t locate it in your computer, contact the IBM Software Support.
Related
I've tried for many hours to find the solution for my problem and couln't find it even here.
So I have that application.exe that I am writing the Wix Toolset installer for it. Unfortunately I have no access to the source code but I hope I can do my task without it.
The problem is that it runs correctly with vc_redist.x64 installed on the end user's machine, but not without it.
What I've tried:
I was trying to run it without those runtimes and got into "couldn't find vcruntime140.dll error"
So I pasted it in the app's folder and tried to move on with dll's and the next error occured as shown in picture:
the application was unable to start correctly (0xc000007b). Click OK to close the application
I've read those runtimes after installation go into eg. "C://Windows/System32"
so I tried to go to that location and
dir > before.txt
and
dir > after.txt
after installing the vc++ runtime.
and copy pasted the files that occured only after the installation.
I tried to use gumpbin.exe from Visual Studio that gave given output:
found some dependencies
and the Dependency Walker gave me kind of similar output.
Dependency Walker output the same libs as direct ones, but also gave imo about hundreds of indirect ones. So I thought copy/pasting all of them is a really hard job without software to help.
I was also thinking about forcing vc_redist.x64.exe to extract files to folder given by me so I could use them for my purpose and the only parameter that looked fine was /layout but it only copied the whole .exe to another folder. Didn't extract it.
My questions is:
is there an easy way of obtaining the vc_redist.x64 libraries so I could author only the needed ones in my installer?
Any help will be appreciated. Thanks in advance!
Edit:
My goal is to secure newbie end users from being unable to run the application when they accidentally uninstall the VC runtime, therefore having vc_redist.exe as prerequisite in bootstrapper is unfortunetely not the case
I am trying to diagnose an error during the build of a project with appveyor. This same project is also built with travis-ci, without any problems. I assume it is windows related.
The script produces some log files, but I have no clue on how these can be viewed after appveyor is done trying to build.
As a specific example: See the log of this build. At line 11706 it says:
Logs have been written to: C:\stack.stack-work\logs\yaml-0.8.28.log
How can I view the contents of that file?
You can push this file as artifact at on_finish stage, or simple RDP to the build worker and explore it interactively.
Side note: you can also try to debug your build in RDP, but note that environment variables from the build session are not available in the RDP session, so you need to re-create all or part of them.
I recently downloaded the latest version of IntelliJ Ultimate (at this time, it is 2017.1.4) for work.
For some reason, I cannot get it to open a new terminal window. When clicking the plus button here:
...nothing happens. Additionally, nothing shows up in the event log. I restarted IntelliJ, my computer, and did the "invalidate caches and restart" option.
Any ideas? Is there a log file I can look at?
It could be a known issue that is already fixed in 2017.2.
Another possible case is that the native terminal library fails to initialize on your system (check idea.log for exceptions). This can be caused by an antivirus or a corrupted IDE installation.
Thanks to #CrazyCoder for reminding me to check idea.log - the native terminal library, as well as other plugins, failed to initialize.
The root cause of the issue is that at my workplace, there is a security restriction to not run any executable that exists outside of C:\Program Files. As a result, IntelliJ cannot run certain plugins, jars, etc. that exist outside of that location, because it will attempt to execute them from your user directory.
To fix this, in IntelliJ, go to Help > Edit Custom Properties and point the config and system path to a known path where you can run executables, like so:
# custom IntelliJ IDEA properties
idea.config.path=C:\\Program Files\\JetBrains\\.IntelliJIdea2017.2\\config
idea.system.path=C:\\Program Files\\JetBrains\\.IntelliJIdea2017.2\\system
You will need to make sure to copy the contents of both directories to the new location. Hopefully this helps anyone else who runs into this issue.
I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!
I have a SSIS master package, which executes several child packages. It works great, but when I deploy it to the file system on the server, I get an error code "0xC00220DE". "The system cannot find the file specified."
When I run the package on the server by double-clicking it, it works correctly. But when I use DTExec:
dtexec /FILE "d:\cmcdx\ssis\MAESTRO_FACTURACION.dtsx"
I get the mentioned error.
The package configuration is correct, and the user I'm executing the package with is administrator of the machine.
Should I deploy the packages to Sql Server? What are the best practices for deploying a master-child package? I'm running out of ideas here...
By the way, I'm running Sql Server 2005 sp3.
Solved it.
I was using relative paths to point to the child packages, and in runtime SSIS was unable to find them.
In the end I used a specific path, set in a configuration file. Then I used the deployment utility, copied everything to the server, run it by double clicking on the SSISDeploymentManifest file and changed the paths to the proper location.
Thank James and Justin for your answers.
Is the package not getting a path or location value from a package configuration file? If so make sure you include the /ConfigFile argument and the path to the config file. Another thing to possibly check is if you have any connections in the package that refer to mapped network drives, these may not work running under the different service account than your local console account.
[Edit]
Try this command line below on the server (notice the double slashes).
dtexec /FILE "d:\\cmcdx\\ssis\\MAESTRO_FACTURACION.dtsx"
There are several things that could be going wrong here. You mention that you're using a master package to run several child packages. Are all of your child packages in their proper location on the server as well?
Remember that the paths to the child packages should be variables in your master package so that those values can be changed through a configuration file on the server if need be.
You might also want to check out this set of tutorials on MSDN:
Package Deployment How-To Topics
These tutorials explain how to properly enable package configurations on the server when your package runs.