Why Perl 4? Perl 4 was supposed to go the way of the dinosaur many years ago. If your platform can run NT or Win2K, you'll have no problem running Perl 5. If you're running Perl 4 because your boss, admin, secretary, etc. stated that you needed to keep that, then I suggest they don't know what they are talking about. Even if you really do have Perl 4 running on that box, I doubt you'd have a problem installing Perl 5 and running it concurrently.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

You could always dump the contents of this lot into a single file, show it to your boss and see if he changes his mind about using modules:^)

 LWP::MemberMixin   -- Access to member variables of Perl5 classes
   LWP::UserAgent   -- WWW user agent class
     LWP::RobotUA   -- When developing a robot applications
   LWP::Protocol          -- Interface to various protocol schemes
     LWP::Protocol::http  -- http:// access
     LWP::Protocol::file  -- file:// access
     LWP::Protocol::ftp   -- ftp:// access
     ...

 LWP::Authen::Basic -- Handle 401 and 407 responses
 LWP::Authen::Digest

 HTTP::Headers      -- MIME/RFC822 style header (used by HTTP::Message
+)
 HTTP::Message      -- HTTP style message
   HTTP::Request    -- HTTP request
   HTTP::Response   -- HTTP response
 HTTP::Daemon       -- A HTTP server class

 WWW::RobotRules    -- Parse robots.txt files
   WWW::RobotRules::AnyDBM_File -- Persistent RobotRules

The following modules provide various functions and definitions.

 LWP                -- This file.  Library version number and document
+ation.
 LWP::MediaTypes    -- MIME types configuration (text/html etc.)
 LWP::Debug         -- Debug logging module
 LWP::Simple        -- Simplified procedural interface for common func
+tions
 HTTP::Status       -- HTTP status code (200 OK etc)
 HTTP::Date         -- Date parsing module for HTTP date formats
 HTTP::Negotiate    -- HTTP content negotiation calculation
 File::Listing
[download]

Thanx for your replies!
(and please accept my humble apologies for my bad formatting in the original post)

The reason for us doing it this hard way is that we use Tivoli Distributed Monitoring to run the monitor.
Sadly enough, it comes with Perl 4 :(
But regardles of what is better or not, is it at all possible to do this using Perl 4 or is it a dead end?

"May the forces of high bandwidth be with you."

Okay, some possibilities. I've no experience of Perl4 so if anything I suggest is dodgey or wrong hopefully one the guys or girls here who has that experience will correct me.

1. Have you checked the distribution CD's for Tivoli and looked to see if they included any of the more common modules?
2. If not, you can probably still get hold of the Perl4 versions of some of these modules on CPAN or somewhere. I did a simple google for perl 4 module and found this which would be a good starting point. The installation doesn't seem to need a complier, but I didn't look too hard.
3. If you really cannot use this module, then the source code will give you a good idea of the work involved in writing you own replacement.
4. If the system you wish to run the script on is not just one but many servers, and you cannot get permission (short-sighted though that would be) to "install modules", then probably the simplest solution would be to install and develop a Perl 5 solution using ActiveState Perl in your lab or on your workstation and then use the AS pl2exe utility to wrap the perl 5 .pl file and a perl 5 runtime into a single executable and distribute that.

   Problem solved I think. No dependancies. No possibility of interfering with your existing Perl 4 codebase. Worth a look?

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!