× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. August 2002

RE: Shared tape drive for 2 LPARs

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Al,

Are you saying that a simple vary on command won't work? What exactly did
they do to implement LPARS in terms of what I consider normal commands?

-----Original Message-----
From: Al Barsa [mailto:barsa@barsaconsulting.com]
Sent: Thursday, August 08, 2002 10:00 AM
To: midrange-l@midrange.com
Subject: Re: Shared tape drive for 2 LPARs



It's not as simple as this.  Besides the VARY *OFF/*ON parts in the
appropriate partitions, you must move the configuration from one partition
using the LPAR API's, which are about as easy to use as relativity.  You
must communicate with them in XML, and the work needs to be done in the
primary partition.

Al

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com





|---------+----------------------------------->
|         |           "Mark Waterbury"        |
|         |           <mark.s.waterbury@worldn|
|         |           et.att.net>             |
|         |           Sent by:                |
|         |           midrange-l-admin@midrang|
|         |           e.com                   |
|         |                                   |
|         |                                   |
|         |           08/07/2002 07:32 PM     |
|         |           Please respond to       |
|         |           midrange-l              |
|         |                                   |
|---------+----------------------------------->

>---------------------------------------------------------------------------
-----------------------------------|
  |
|
  |       To:       <kdasto@fiskars.com>
|
  |       cc:       <midrange-l@midrange.com>
|
  |       Subject:  Re: Shared tape drive for 2 LPARs
|

>---------------------------------------------------------------------------
-----------------------------------|




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
>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.






_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.