Sponsored Content
Full Discussion: TWS 8.4 on HP-UX - lookups?
Operating Systems HP-UX TWS 8.4 on HP-UX - lookups? Post 302353399 by rnbwkat on Tuesday 15th of September 2009 08:53:52 AM
Old 09-15-2009
TWS 8.4 on HP-UX - lookups?

Just wondering if anyone else is using IBM's TWS on HP-UX 11.11i. Seeing some very strange name-lookup issues when it comes to using various utilities on the system. The same software works fine o0n AIX, Linux, Solaris, etc, but on HP-UX there is noticeable time lags in issuing commands - at the shell level. For example, trying to execute conman type commands, can hang for a minute or more before coming back. if you sniff the net while this is "waiting" you see lots of DNS requests that don't seem to make sense.

This is TWS 8.4 and just wondering if there are others out there using this slightly older release (because of support issues) on HP.

thanks
 

4 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Can awk do lookups to other files and process results

I know that 'brute-force' scripting could accomplish this with lots of cat/echo/cut/grep and more. But, because my real file has 800k records, and the matching files have 10-20k records, this is not time-possible or efficient. I have input file: > cat file_in... (4 Replies)
Discussion started by: joeyg
4 Replies

2. AIX

Signaling TWS from AIX

Hello Friends, We are manually executing a ksh script. On the successful completion of the script, we go to Tivoli Workload Scheduler console and manually submit a Job stream. In doing so, there is always a time lag between the completion of the ksh script and submission of the job stream from... (1 Reply)
Discussion started by: sudvishw
1 Replies

3. Shell Programming and Scripting

nslookup for reverse lookups on multiple servers

Hi all i need help :) i need to create a script (tcsh) to do a nslookup on all my hosts to see which ones do not have reverse lookup..etc. can someone please help? (1 Reply)
Discussion started by: brian112
1 Replies

4. IP Networking

How to do traceroute of DNS lookups?

hello,, after googling a lot,, i still cannot find the answer to my problem. i want to do a traceroute or a network debugging of dns lookups from a Mail Server running on DEBIAN LENNY 5.0. we have 2 routers in our office,, and i want to see through which of the routers the dns lookups are... (3 Replies)
Discussion started by: coolatt
3 Replies
Module::Install::FAQ(3pm)				User Contributed Perl Documentation				 Module::Install::FAQ(3pm)

NAME
Module::Install::FAQ - Frequently Asked Questions for Module::Install DESCRIPTION
Though Module::Install itself has a general FAQ section in the pod, it's more for advocacy. Here's an incomplete and growing list of the actual questions I have been frequently asked (or found on the net) about Module::Install. Do I also have to update my CPAN modules every time Module::Install is updated? The point of Module::Install is let module authors take care of everything related to updating toolchains for the sake of module users. So, if you choose to use Module::Install, it's you who should update toolchains, i.e. Module::Install and other bundled modules. You should check if there's any significant change/fix in your toolchains. You should check if your toolchains go along with other tools users use to install your distributions, or with the systems users are in, or whatever that matters. In the end, you are expected to have much more knowledge and willingness than average users. That being said, practically, you don't have to update your distributions if they are working well. But if you do find issues, please update your distributions, even when you have nothing to change in your own modules. Module::Install is not only a tool to write better, but also a tool to encourage you to help others. Do I really have to avoid auto_install()? Not at all, using "auto_install()" is just fine. While it indeed behaved erratically in older Module::Install versions, there have been no reported issues since mid-2009. As far as compatbility with various CPAN clients: several rather large projects on CPAN (including Catalyst and DBIx::Class), are using "auto_install" without any issues reported by their substantial userbases. That said, if all you want to do is make it easy for a contributor to checkout your code and quickly install necessary dependencies, there are alternatives to "auto_install". If your CPAN module is new enough, you can pass a dot to the cpan command it provides, and it will install all the required distributions from the CPAN: $ cpan . The same is true for the cpanm command from App::cpanminus, with which you even can write like "cpanm --installdeps ." Should I put an "inc" directory Module::Install automatically creates into a repository for my projects? Depends. If the repository is private and only for you, you usually don't want to put it in your repository to let you always use the latest Module::Install you have (the "inc" directory is recreated each time you run "perl Makefile.PL"). If not, but you alone are the release manager and know what you have to do when you release, putting the "inc" directory into your repository may help other casual contributors, especially if you use minor (or private) non-core extensions in your Makefile.PL. However, if you generously allow other people to release, or you're not so familiar with how Module::Install works and don't know what you have to do in the above situation, don't put it in the repository. It may be the cause of troubles including a wrong version in the "META.yml". If you feel sorry about the inconvenience for your fellow contributors, you may want to add explicitly "use Module::Install::<ExtensionYouWantToUse>;" after "use inc::Module::Install;" in your Makefile.PL. It doesn't do any harm, and it makes clear which extensions they need to install. What're there in the "inc" directory? Module::Install puts its components (sometimes with extra modules) under the "inc" directory to be released with a distribution. Those modules will not be installed into your system, unless explicitly copied into somewhere. They are only used to help configuration, tests, and/or installation. If there's no "inc" directory, Module::Install will automatically create it when you run "perl Makefile.PL". And if that happens, a directory (as of this writing, ".author") will also be created under the "inc" directory. If the ".author" directory exists, the "inc" directory will be recreated each time you run "perl Makefile.PL" to make sure everything you need is included and up-to-date. This ".author" directory will not be included in a distribution. "perl Makefile.PL" doesn't work or does a strange behavior for me. Why? Module::Install uses an Autoloader magic to delegate command handling to the extensions in the "inc" directory. This works while everything is in order, but when it finds something it can't understands, it dies with a compile error, or does what you don't expect. To prevent the latter strange behavior, Module::Install 0.96 and above dies when it tries to process unknown commands. In most cases (other than typos), these unknown commands are from non-core extensions on the CPAN, and they should hopefully have predictable names that you can easily tell from which extension they come, though some may be a bit hard to find. If you are trying to contribute to some project, and having a trouble to run "Makefile.PL", please contact the author of the project to learn what you have to install. If the distribution is already on the CPAN, you may also want to look into the MANIFEST file to see which extensions are included in the "inc" directory before you ask. This usually does not happen in the user land as distributions that use Module::Install should have all the necessary extensions under the "inc" directory. If this should happen, that's most probably because the release manager shipped the distribution under a non-author mode. Please contact the author to fix the issue. Why can't I do <anything> with Module::Install that I can do with ExtUtils::MakeMaker? Module::Install is just a wrapper of ExtUtils::MakeMaker. You can do almost everything you can do with ExtUtils::MakeMaker by passing arbitrary attributes to ExtUtils::MakeMaker in the backend via "makemaker_args" like this: use inc::Module::Install; all_from 'lib/Foo/Bar.pm'; makemaker_args( dist => { PREOP => '...' }, PL_FILES => {'bin/foobar.PL' => 'bin/foobar'}, ); WriteAll; However, by the singleton nature of Module::Install, it may fail to process Makefile.PLs in subdirectories correctly now, and you may need to override attributes explicitly in some cases where Module::Install provides other default values than ExtUtils::MakeMaker does. Please see also the ExtUtils::MakeMaker's pod for further instructions. I added MyMakefile.PL to my distribution, but it doesn't work as I expected. Why? ExtUtils::MakeMaker (and Module::Build also) treats "*.PL" files in the top level directory as something special to generate other files. So, if you add something that has ".PL" extension like "MyMakefile.PL" in the top level directory, it also runs automatically when you run Makefile.PL. If you don't like this behavior, use "makemaker_args" to pass an anonymous hash to "PL_FILES". makemaker_args(PL_FILES => {}); AUTHOR
Kenichi Ishigaki <ishigaki@cpan.org> COPYRIGHT
Copyright 2010 Kenichi Ishigaki. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.14.2 2012-03-01 Module::Install::FAQ(3pm)
All times are GMT -4. The time now is 05:03 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy