Re: Shared tape drive for 2 LPARs -- MIDRANGE-L

Hi, Kevin:

 If I understand your query correctly, your situation is not
different, with two (or more) LPAR partitions, than when
sharing an external tape drive between two physical machines.
If the machines are connected via Token Ring or Ethernet,
it is relatively easy to configure them for SNA or TCP/IP
communications.

 LPARs are just like a two machine situation, in this respect;
all the logical "partitions" in the same physical machine are
always "connected" by high-speed internal communications
(implemented in HLIC software) that "looks like" Ethernet or
Token Ring, as far as OS/400 is concerned, and so, you can
configure TCP/IP or SNA over this "internal LAN", so all the
partitions can send files, messages, etc. (Otherwise, how can
you ever share anything across LPARs?  By saving to tape,
and then, vary the tape off, vary it on in another partition, and
then restoring from tape?  Come on!)

 In the case of SNA and SNA Distribution Services, or SNADS,
(you can configure APPC-over-IP so SNADS can use TCP/IP),
you can then use the SBMNETJOB command to send a "job"
over to the other machine. This "job" has a "job card" (such as:

// BCHJOB JOB(name) JOBD(lib/jobd) JOBQ(lib/jobq) ...

followed by some CL commands, in a source member. This is
then "submitted" over to the other machine, where it ends up in a
job queue, and if that job queue is active, it will (eventually) run.

This CL could simply CALL a CLP program that you have written
on that machine that checks if the tape drive is "in use" (using
ALCOBJ to try to allocate the object, etc.) and then can issue the
VRYCFG command to vary it *ON or *OFF, etc.  Then, the CL
could even send a job in the other direction, via SBMNETJOB
to "notify" the other side to continue...

Another solution that could be even simpler would be to use DDM
*FILEs and attach a "trigger" program to that file, and then, by just
writing a record into this file, and letting DDM send the record
across, causes the "trigger" program to "fire" on the receiving side,
and the record could even contain the "command" (request) to
execute... (DDM can work over SNA or TCP/IP...)

Or, if you don't want SNA and SNADS involved, you can use
"straight" TCP/IP ... from within FTP, (even from a FTP script),
you can issue, for example:

     QUOTE RCMD VRYCFG ...

 Or, you could just FTP the data to a "flat file", and again, have a
 "trigger" attached to that file, to issue the "commands"...


Or, a more "traditional" approach, you could have a "never-ending"
program running on each machine, listening on a message queue;
say you create a user profile named "AUTOOPER" or some such,
and have a program that waits at a RCVMSG on this *MSGQ ...

Then, when you need to do something like vary off a tape drive,
you simply send a message to this message queue, for example,
using SNDNETMSG (SNA again), or using some other tools,
such as the Java AS/400 Toolbox APIs to send mesages...
(SNDNETMSG now works over TCP/IP as well as SNA).

The message could be very simple, such as "VARY OFF TAPE".

 The program then receives the message, reads it, and interprets it,
and then performs the appropriate actions, and can then send back
a "reply" message, say, to "AUTOOPER" on the sending machine,
to say "okay, it is done now."

 There are certainly many variations to this scheme, depending on
your skills, experiences, and what tools you prefer to use.

If you happen to know about TCP/IP, then you might want to use
"sockets" -- a listener job (never-ending) on one machine listens for
requests on a given TCP/IP port, and a "sender" job (command) can
send requests to the correct port# on the correct IP address for the
"server" in question (LPARs each have their own IP addresses).

 I think these ideas are covered in some of the IBM Redbooks on
LPARs...

 I hope this helps...

 And, come on, you "vendors" out there; (you know who you are),
don't try to sell an "expensive" solution for a very simple problem!

 Regards,

 Mark S. Waterbury

> ===============================================
> Shared tape drive for 2 LPARS
>
> Subject: Shared tape drive for 2 LPARS
> From: "D'Asto, Kevin" <KDAsto@xxxxxxxxxxx>
> Date: Wed, 7 Aug 2002 13:40:30 -0500
> List-archive: <http://archive.midrange.com/midrange-l/>
> List-help: <mailto:midrange-l-request@midrange.com?subject=help>
> List-id: Midrange Systems Technical Discussion <midrange-l.midrange.com>
> List-post: <mailto:midrange-l@midrange.com>
> List-subscribe:
>
<http://lists.midrange.com/cgi-bin/listinfo/midrange-l>,<mailto:midrange-l-r
> equest@midrange.com?subject=subscribe>
> List-unsubscribe:
>
<http://lists.midrange.com/cgi-bin/listinfo/midrange-l>,<mailto:midrange-l-r
> equest@midrange.com?subject=unsubscribe>
> Thread-index: AcI+QegybrNxHR5pQi60vzp0QG7+3A==
> Thread-topic: Shared tape drive for 2 LPARS
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> have a System with two LPARS and one tape drive. The problem I have is
> that let's say LPAR- A is scheduled to do its backup first but the
> problem is that LPAR - B has the tape drive at a varied ON status how
> can I write a CL that will go and vary OFF the tape drive, As long as
> the tape is not active.  Then send a message back to LPAR - A to let it
> know that it can use the tape drive
>
> Thanks
>
> Kevin D'Asto
> Midrange Systems Administrator
> Fiskars Brands Inc.
> 2537 Daniels Street
> Madison, WI. 53718
> (608)294-4605
> kdasto@fiskars.com
>
>
>
>
>
>
>
>
>
>
> Next by Author: Re: ClientAccess and Windows XP
> Previous by thread: RE: How to identify QZDASOINIT serving a given request
> Next by thread: Re: Shared tape drive for 2 LPARS
> Index(es):
> Author
> Thread
>