× 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.



--
[ Picked text/plain from multipart/alternative ]
Maybe I missed part of this thread... But why not use  a shared (or
switchable) IOP for the  tape drive? LPAR has that
feature.  Inter-partition communications ( same physical system) can
be  done  via Virtual  LAN {free}  or Virtual OptiConnect {minimal
cost}at  very high speeds.

   Glenn

Glenn Ericson
Ph. (718)898-9805
<mailto:Glenn-Ericson@att.net>mailto:Glenn-Ericson@att<mailto:Glenn-Ericson@
att.net>.net

At 05:32 PM 08/07/2002 -0600, Mark Waterbury wrote:
>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.

   Glenn

Glenn Ericson
Ph. (718)898-9805
<mailto:Glenn-Ericson@att.net>mailto:Glenn-Ericson@att.net
--



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.