From: Mark Bixby in a not too long ago message:
"Perl was built using -D_SOCKET_SOURCE and -D_POSIX_SOURCE.
You can use Perl's socket functionality exactly as described in the Perl
documentation."
Emboldened by this, I decided to try it out.
This is all pretty basic, but ...
My test goal:
Run a perl script that will display on my "client" 3000 ("NED")
all the jobs executing on my "server" 3000 ("LEE") as if I typed
"SHOWOUT JOB=@J;EXEC" on LEE.
****************************************************************************
*
The Client Perl script on NED
****************************************************************************
*
#! /usr/bin/perl -w #linked to
/PERL/PUB/perl
# Script Name remje.pl
use IO::Socket;
my ($remote, $remoteaddr, $remoteport);
# $remoteaddr = IP Address of server, passed in as script argument
# $remoteport = port number also passed in as script argument
unless (@ARGV == 2) { die 'usage: $0 <ipaddr> <port>' }
# send arguments into $remoteaddr and $remoteport vars
($remoteaddr, $remoteport) = @ARGV;
#connect to the remote socket
$remote = IO::Socket::INET->new(
PeerAddr => $remoteaddr,
PeerPort => $remoteport,
Proto => "tcp",
Type => SOCK_STREAM)
or die "cannot connect to server port at $remoteaddr";
print $remote "NED\n"; #client identifies itself
while (<$remote>) { print; } #prints the output from server
close($remote); #closes the remote socket connection
****************************************************************************
*
The Server Perl Script on LEE
****************************************************************************
*
#!/usr/bin/perl -w #linked to
/PERL/PUB/perl
# Script Name "remjed.pl"
use IO::Socket;
my (@sjobs, ,$buffer, $connectsock, $connectaddr); #declare variables,
don't have to...just like to.
#If
further developed into something useful and put into
#production I'd "use strict;" so better to declare now
#create local socket
$server = IO::Socket::INET->new(LocalPort => 4000,
Proto => "tcp",
Type => SOCK_STREAM,
Reuse => 1,
Listen => 10 )
or die "Couldn't be a tcp server on port: 4000 : $@\n";
print STDERR "[showjobs] Server is started. \n"; #print to STDERR
because I set up an MPE job to launch
#the
server. STDERR handle will cause messages to be
#printed to JCL.
while (($connectsock, $connectaddr) = $server->accept()) { #For
testing, $connectaddr is tossable. I'm just
chomp($buffer = $connectsock->getline); #interested
in $connectsock. Eventually I'll use
#$connectaddr
print STDERR "[showjobs] Opened connection with $buffer.\n";
@sjobs = `callci 'showjob job=\@j;exec'`; #backticked callci
command output into @sjobs
foreach (@sjobs) {
print $connectsock $_; #print each line of
@sjobs back to client
}
print STDERR "[showjobs] Sent output to $buffer.\n";
close($connectsock); #close
connection with client
print STDERR "[showjobs] Closed connection with $buffer.\n";
}
close($server); #closes the
server, although for testing, I abort
#the
server to stop it from running, eventually
#I'll try to add a graceful shutdown.
****************************************************************************
*
Simple JOB to run remjed.pl daemon on server named REMJESRV
****************************************************************************
*
!JOB REMJESRV,MANAGER.SYS;OUTCLASS=LP,1;PRI=CS
!COMMENT CS queue because it's main functionality is to send output to
!COMMENT what is essentially a remote session.
!XEQ SH.HPBIN.SYS;INFO="-c /path/remjed.pl"
!EOJ
****************************************************************************
*
Simple Command file to run remje.pl on client named REMJE
****************************************************************************
*
# Can do much more with this, but will suffice for testing.
# Note the command file hard codes the IP address,
# but I will eventually have it so the user enters "REMJE <system>" and
# the appropriate IP address will be put in for the user.
# the port number can stay hard coded as I'd make sure the same port number
# is used on all servers.
XEQ SH.HPBIN.SYS;INFO="-c '/ron/remje.pl 10.xxx.xxx.xxx 4000'"
****************************************************************************
*
Result? It all works! <...and there was much rejoicing>.
Where to go from here?
I'd really like to do away with having to run the REMJESRV job or devote
a terminal to running the remjed.pl script.
I figure I could attach a modified server script to the JINETD services by
adding
appropriate entries in /etc/services and /etc/inetd.conf.
However, if I do that, the modified server script will not then be
responsible
for creating the socket (it can't in fact do so using the same number put
into the
/etc/services file since it will already exist). But if it doesn't create
the socket,
how do I get the script to print it's output back to the client, w/o having
to create
another socket (thereby having to make the client connect to two sockets)?
I'd like to keep this a one socket deal if at all possible using JINETD
(kinda like 'daytime'),
so any input into this idea would be greatly appreciated! :-)
Why is this important (to me)?
Well, right now I have jobs running on two of my production 3000's that
monitor what other jobs are
running (on themselves), and email/beep me if they have stopped for some
unexpected reason.
These Perl scripts can be developed further so that I don't have to do the
processing of figuring
out if there is a problem on my production boxes. Also my production boxes
use only JCL to do all
this processing, and using Perl would eliminate a lot of the hoops I have to
jump through to get
the more limited JCL functionality to do what I need, while providing me
with powerful options.
Not to mention that the production box can't tell me if it itself is down
(whereas a socket that
doesn't connect from a client can at least give me a warning that something
may be wrong).
Okay...I'm done...have at it, tear it up and all feed back would be
appreciated!
Thanks!
Ron Wuerth
Virginia International Terminals, Inc.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
