| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Has anyone tried "TMA" (Transfer Mail Area) in a cluster environment?
The code (OA$SM_TRANSFER_MAIL_AREA) assumes that it is in an ALL-IN-1
sub-process when it runs the command procedure that defines the cluster
logicals (@OA$LIB:OA$SM_SUBMIT_CLUSTER_WIDE OA$SM_DEFINE_SHARED_LOGICALS).
Looking at the code (do not have a V3.0 cluster to test it) it appears
that logicals are successfully re-defined only on the node where TMA gets
submitted. Furthermore, having errored out on the other nodes, the
code skips cleaning up (deleting sDAF(s) located on the old location)
resulting in users writing to sDAF(s) on both the new and the old locations!
Regards,
Dan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2949.1 | More info please! | IOSG::THOMPSON | Thu Jul 01 1993 11:52 | 12 | |
Dan,
I don't understand your problem - what exactly is it that
is broken? I believe that this code is the same as in V2.4
- is the problem reproducable on a 2.4 system?
Did you run OA$SM_DEFINE_SHARED_LOGICALS on a standalone system?
If so remember that this requires the node-queue master file to
be populated - it won't be on a stand-alone system.
Karl
| |||||
| 2949.2 | Gory details, solution and further issue | MIMS::BEKELE_D | My Opinions are MINE, MINE, all MINE! | Thu Jul 01 1993 20:27 | 62 |
Hi Karl,
> ...what exactly is it that is broken?
.ALL-IN-1 is in a cluster,
.You submit TMA and you go home (sorry Karl, you have been
identified as my 'confident' customer for unknown reasons :^)),
.The job copies the sDAF to the new location you specified,
.The logical for the new shared area gets successfully redefined
on the node the job was created on,
.Next OA$SM_SUBMIT_CLUSTER_WIDE.COM tries to run but fails due
to the fact that it is not in an ALL-IN-1 subprocess (which
is how it was run under V2.4. V3.0 uses A1SUBMIT.CLD) nor
has ALLIN1/NOINIT been done before calling OA$SM_SUBMIT_CLUSTER_WIDE.
OA$SM_SUBMIT_CLUSTER_WIDE, however, tries to WRITE to OAMAILBOX
(same code as the V2.4 code),
.OA$SM_TRANSFER_MAIL_AREA, as far as I can tell, having encountered
a "warning", should jump to error handling routine and exist
without restarting ALL-IN-1 (customer insists otherwise),
.The sDAF on the source device does not get deleted (further proof
that code jumped to error routine),
.ALL-IN-1 at this point gets restarted (even his own logfile says
"Error occured whilst updating the logicals with new values -
this needs to be done before restarting ALL-IN-1"),
.Users login on all nodes. Those who logged on the node that the
TMA job got created on get to write to the sDAF on the new
location. Those who logged on other nodes get to write to the
same sDAF but on the old location (and you are at home, relaxed
and drinking some cool-aid (ha!)
To solve the problem of redefining the logicals cluster-wide I
have suggested to the customer to modify OA$SM_TRANSFER_MAIL.COM
as follows:
Change
$@OA$LIB:OA$SM_SUBMIT_CLUSTER_WIDE OA$SM_DEFINE_SHARED_LOGICALS
to
$ALLIN1/USER=MANAGER/NOINIT/OVERRIDE
$DECK
OA$INI_INIT
COMMAND OA$SM_SUBMIT_CLUSTER_WIDE OA$SM_DEFINE_SHARED_LOGICALS
EXIT
$EOD
The problem of ALL-IN-1 getting restarted cluster-wide eventhough
there were problems encountered (as I stated before I don't have
ALL-IN-1 in a cluster to disprove what he is saying) on some nodes
in the cluster is what I would like others to comment on.
Many thanks,
Dan
| |||||
| 2949.3 | workaround looks good for now.. | IOSG::TYLDESLEY | Wed Jul 07 1993 11:38 | 10 | |
hello Dan.
I think that your assessment of the situation in
OA$SM_SUBMIT_CLUSTER_WIDE is essentially correct; the oamailbox has
not been set up. We have a THR- number, and I hope this might get
fixed in a PFR.
Not sure what your 'further issue' was?
Thanks for your help.
DaveT
| |||||
| 2949.4 | mod OA$SM_TRANSFER_MAIL_AREA.COM | IOSG::VOWLES | Raphael VOWLES DTN 830 6910 REO2 G/M2 | Wed Jul 07 1993 11:55 | 32 |
re: <<< Note 2949.0 by MIMS::BEKELE_D
Here is a formalised solution. As Dan has requested: Has anyone had this
problem??
Please reply to let us know the state of play.
tta rv Wednesday 7-JUL-1993 10:54
==========================================================================
==========================================================================
Using Customization Management modify the command file element:
OA$SM_TRANSFER_MAIL_AREA.COM as follows:
==========================================================================
Change the one code line that reads: (on or about line 94)
==========================================================================
$ @OA$LIB:OA$SM_SUBMIT_CLUSTER_WIDE OA$SM_DEFINE_SHARED_LOGICALS
==========================================================================
To: (6 code lines)
==========================================================================
$ ALLIN1/USER=MANAGER/REENTER/OVERRIDE/NOINIT
$DECK
OA$INI_INIT
COMMAND OA$LIB:OA$SM_SUBMIT_CLUSTER_WIDE OA$SM_DEFINE_SHARED_LOGICALS
EXIT
$EOD
| |||||