I need to rejig some VERY old Windows code that uses Perl to talk to MQ. Specifically, I need to be able to install Perl's MQClient::MQSeries, MQSeries::QueueManager, MQSeries::Queue and MQSeries::Message modules.
When I fire up Strawberry Perl, go into CPAN and try to install them, I can see that there's several MQ client DLLs that are required for these Perl modules to build. However, they're not on my system, even after downloading and installing the current MQ Client from IBM.
It used to be that downloading and installing the MQ Client from IBM gave you the option to install a whole bunch of development libraries (presumably including the bits necessary to install the above Perl libraries), but it seems that's no longer the case. For example, there's no MQM.DLL file anywhere, which is one file that the Perl libraries seem to need to build correctly.
Suspect I've probably just not installed the correct MQ Client package to get this stuff, but have no idea where to find it (Google is no help). Any suggestions?
MQSeries 1.29 was released in 16 Jun 2009, so I guess you can just ask it's maintainer.
You can also ask in newsgroup news://news.software.ibm.com/ibm.software.websphere.mq , or ask IBM's support.
where'dja get the MQ download?
maybe you might try mqseries.net - it's a hotbed of MQ activity.
I'd suggest downloading the WMQ Client installation. Depending on which one you want, v7.0 is SupportPac MQC7 and v7.1 is SupportPac MQC71. This will get you the client libraries with which to build the Per module. If you need the server libs, the Evaluation download of WMQ Server v7.1 is here:
Related
I need to work on a Perl script that has some tasks, like reading/writing Excel sheets, connection to an Oracle database, etc.
First I used ActivePerl. On installing modules, ActivePerl threw an error:
Authorization required 401
(I.e., it requires a business licence for adding modules.)
Then I tried the same with Strawberry Perl, but I still could not install.
What I have tried:
CPAN
ppm
Download a module and install using it nmake
Install modules using the Padre Perl IDE.
Is this a license issue? Or am I missing something here? Is Perl a free distribution for development?
The image shows installing DBD::Oracle on Strawberry Perl v5.22.0:
It looks like you are using Strawberry Perl. That requires no license or other special steps to use. It's ready to go.
One of the top lines of output in your picture is "Can't connect to cpan.strawberryperl.com:80". It then tries to connect to other sites and has the same failure. It looks like a network issue.
The community edition of ActivePerl provides support to only the latest versions of Perl, and access to the packages ActiveState built for older versions is available in Business and Enterprise edition.
If you install Perl 5.18.4, 5.20.2 or 5.22.0 then you'll not get a 401 error.
Alternate solution: Use CPAN instead of ppm to install Perl modules.
See more at: Download and Install Perl: ActivePerl
ActiveState is a commercial company. They release a community edition, but they make money from support. Part of that means they only offer "free" the newest versions. Which is why you get the error you do - upgrade to a newer Perl, and they'll let you update.
More broadly - technically each module can be licensed separately. There's no requirement to release Perl code (including modules) under any sort of FLOSS license.
However, bear in mind that the ActiveState community edition isn't the same license as CPAN modules would be. CPAN modules are "Mostly GNU". But ActiveState CE has some additional terms.
For example,
The use of the Software is unsupported and is for non-commercial or non-production use.
You should make a point of reviewing licenses, because it really is a bit of a minefield if you're not careful.
I'm reading the Subversion book "Version Control with Subversion For Subversion 1.7." There are several sections in the book which state that this or that only works with version 1.x or greater of Subversion. So, this raises the question "how do I know the version number of the Subversion server to which my Eclipse client is connecting?"
Now, I happen to have remote Subversion repositories hosted by Beanstalkapp.com, so I suppose I can go to their site and ask them, but is there a way to tell from within Eclipse to which version of Subversion my Eclipse client is connecting?
I'm using the Tigris plugin for Eclipse to access the remote Subversion server (at Beanstalkapp.com). The version of Eclipse is Kepler SR 2.
(Just a note to differentiate this question from this similar question: How to find my Subversion server version number?. I'm not looking for some CURL command or other command line initiated command to determine the Subversion server version number. I'd like to be able to do this from within Eclipse, hopefully without having to add any plugins other than the standard Subversion plugins -- Tigris in my case).
It is bad practice for server software to advertise its version number. If you browse a Subversion http repository directly, it will sometimes show the version number in the footer, but this is something admins can and should turn off.
A Subversion client does not know the version of the server it is talking to. All 1.x clients and 1.y server versions are compatible with each other. The server and client simply negotiate their capabilities with each other. So you can sometimes get a rough idea of a server version by knowing its capabilities.
In general, there is no need for you to know the version of the server. The client will work out those details and generally only minor low level feature details even care about this. For example, the only functional difference between a 1.7 and 1.8 server are some low-level HTTP protocol differences that can be leveraged. These do not manifest as user-visible features.
The Subversion release notes typically have a table that says which features need the client or server. The majority of new features only need a new client. The ones that need a new server usually have to do with server-specific features related to how it stores data on disk, which the client does not need to know.
See Subversion Release Notes
When trying to install Talend MDM, the documentation said something rather interesting:
"JBoss Application Server comes prepackaged with Talend MDM."
That would make my life a lot easier, but I can't tell if they are trying to say that Talend's downloadable version of JBoss comes with Talend MDM, or if the open source JBoss AS actually comes with Talend?
If so, what other neat software tools come prepackaged with JBoss, and if so, how can I view a listing?
There's a misunderstanding here. What the documentation means is that as part of the Talend MDM product, the JBoss Application Server is shipped. So JBoss is a component (actually the core component) of Talend MDM. Not the other way round.
Talend MDM actually depends on the precise version of JBoss that is shipped with the product (it may even be modified here or there), so it is not possible to install Talend MDM into a different JBoss instance.
What are the best practices for deploying a Perl application? Assume that you are deploying onto a vanilla box with little CPAN module installation. What are the ideal build, deploy methods? Module::Build, ExtUtils::MakeMaker, other? I am looking for some best practice ideas from those who have done this repeatedly for large scale applications.
The application is deploying onto a server. It's not CPAN or a script. It's actually a PSGI web application. That is, a ton of Perl packages.
I currently have a deployment script that uses Net::SSH::Expect to SSH into new servers, install some tools and configure the server, then pull down the desired application branch from source control. This feels right, but is this best practice?
The next step is building the application. What are the best practices for tracking and managing dependencies, installing those dependencies from CPAN, and ensuring the application is ready to run?
Thanks
The company that I work at currently build RPMs for each and every CPAN & Internal dependency of an application (quite a lot of packages!) that install into the system site_perl directory. This has a number of problems:
It is time consuming to keep building RPMs as versions get bumped across the CPAN.
Tying yourself to the system perl means that you are at the mercy of your distribution to make or break your perl ( in Centos 5 we have a max perl version of 5.8.8 ! ).
If you have multiple applications deployed to the same host, having a single perl library for all applications means that upgrading dependencies can be dangerous without retesting every application of the host. We deploy quite a lot of separate distributions all with varying degrees of maintenance attention, so this is a big deal for us.
We are moving away from building RPMs for every dependency and instead planning to use carton [1] to build a completely self contained perl library for every application we deploy. We're building these libraries into system packages, but you could just as easily tarball them up and manually copy them places if you don't want to deal with a package manager.
The problem with carton is that you'll need to setup an internal CPAN mirror that you can install your internal dependencies to if your application depends on modules that aren't on the CPAN. If you don't want to deal with that, you could always just manually install libs you need into local::lib [2] or perlbrew [3] and package the resulting libraries up for deployment to your production boxes.
With all of the prescribed solutions, be very careful of XS perl libs. You'll need to build your cartons/local:libs/perlbrews on the same architecture as the host you're deploying to and make sure your productions boxes have the same binary dependencies as what you used to build.
To answer the update to your question about whether it is best practice to source checkout and install onto you production host; I personally don't think that it is a good idea. The reasons why I believe that it is risky lays in the fact that it is hard to be completely sure that the set of libraries that you install exactly lines up to the libraries that you tested against, so deployments have the potential to be unpredictable. This issue can be exasperated by webapps as you are very likely to have the same code deployed to multiple production boxes that can get out of synch, also. While the perl community does a wonderful job of trying to release good quality code that is backwards compatible, when things go wrong it is normally quite an effort to figure things out. This is why carton is being developed, as this creates a cache of all the distribution tarballs that you need to install frozen at specific versions so that you can predictably deploy your code. All of that said though; if you are happy to accept that risk and fix things when they break then locally installing should be fine for you. However, at the very minimum I would strongly suggest installing to a local::lib so that you can back up the old local lib before installing updates so you have a rollback point if things get messed up.
Carton
local::lib
perlbrew
If it has some significant CPAN dependencies, then you might want to either write a small script that uses CPAN::Shell to install the necessary modules or edit the Makefile.PL of your application so that it reflects the necessary dependencies in the BUILD_REQUIRES portion of the file.
You may take a look at sparrowdo a perl6 configuration management tool, it comes with some handy plugins related to perl5 deployment, like installing cpan packages or deploying psgi application.
Update: this link https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb could be useful.
Disclosure - I am the tool author.
I am going to be moving all my websites to a Windows Web Server 2008 R2 machine. I have installed it in a virtual machine to test that my websites work with it.
I have noticied that there is a program called Web Platform Installer. I have used it to install a few sites but I was just thinking is it a security risk using this? Would it be better for me to manually install the sites (WordPress, Umbraco, etc)
Thanks
We push that out to all our customers just for ease of deployment, and I have not seen any security issues with it, however, I would question its reliability as it fails about 10% of the time (to install whatever I have selected). Having said that, when it does work, its a fairly good tool, as it will install any prerequisites that you may not have been aware of (like SMO, or if you try to install Wordpress without MySQL), and will also keep you up-to-date on newer version of software that you have installed.