Cause the fwdBro on GTW04 to send NLCDEV cmlog messages to a new MCC Standalone process.
Add a new Special Purpose Proxy that forwards NLCDEV cmlog messages only to a new MCC Standalone process.
- For the sake of discussion, lets call it PX03.
- PX03 would be different than the other proxies. It would not forward
DBEX, Message service, or other traffic. No Ethernet micros would be connected
to it. It would only forward messages from fwdBro on GTW04 to a special
purpose standalone on MCC. It would not send messages to ERR_INT on MCC
because ERR_INT only supports one connection (to PX00). This is a "phase
one" approach to introducing a new proxy.
- The new VMS standalone would be written to receive the messages and put
them into ERR_INT's mailbox.
- The connection would be as follows:
- PX03 would sit on the LAVC network if it will be taylored by SCS; otherwise
it will be a standalone and sit on LEB network.
- For standalone, it should be set up as PX00; for taylored, it should
be like PX01.
All messages would be forwarded from MCC to gtw00, except those from gtw00. So, gtw00 cmlog would contain all messages.
Only messages from MPG and TAxx (and those containing MP0, TA0 and TA1 in the text field) would be forwarded from MCC to gtw04. So, gtw04 would be a much smaller database than gtw00. It would be specific to NLCDEV users.
There would be no proxy involved with sending NLCDEV error messages to MCC.
Instead, the new Standalone would receive messages directly from fwdBro.
This is an easier to implement option than the one above because it does not
involve bringing up a new proxy.
A new VMS standalone would be written to receive the messages and put them into ERR_INT's mailbox.
The connection between nlcdev IOC's and MCC would be as follows:
Only messages from MPG and TAxx (and those containing MP0, TA0 and TA1 in the text field) would be forwarded from MCC to gtw04. So, gtw04 would be a much smaller database than gtw00. It would be specific to NLCDEV users. Presumably, they would enjoy not having to wade through all the PEP and SLC messages that don't pretain to them.
The connection between MCC and the gtw04 cmlogServer would be as follows:
MCC Error Log Global Section --> CMLOG_FWD_NLC MCC Standalone --> fwdCliS/cmlogServer(GTW04).
As is currently the case, all messages would be forwarded from MCC to gtw00, except those from gtw00. So, gtw00 cmlog would contain all messages from nlcdev ioc's, pep ioc's, and MCC itself.
The "Greg" option. Don't forward NLCDEV messages from GTW04 to MCC.
- This would force people looking for nlcdev messages to use cmlog.
Add a new network connection (wire) from GTW04 to the PEP network.
This would be very easy to do and would allow GTW04 to talk to PX00. But the idea was rejected because it would push NLCDEV error message traffic onto the PEP network.
Run the new cmlogServer/fwdBro on GTW02 instead of GTW04.
Currently, GTW00 serves the /u1 disk to GTW02, so we would not achieve the goal of the realm-split of being able to bring down machines/networks independently.
But, the previous issue would be nullified when the NFS server is installed (9/1 is the ship date).
But, this option would also push NLCDEV error message traffic onto the PEP network. Additionally, there is the idea that GTW02 is really a PEPII machine and we'd be putting NLCDEV processing onto it.
Put a second NIC into PX00, connecting it to both LEB and PEP.
- This is a possibility, but here are concerns that the software would
need to be modified to operate on two networks, concerns about the subnet
mask handling, and the general concern about even touching the software
this close to the run (yikes!!!).
What about the schedule?
Do we need to have this working before the run starts? If so, that influences our decision.
General note about the FECC
The FECC is expected to add 70-80 new ethernet micros and they won't all be on the PEPII network as the current ethernet micros are. So, we'll need to think about the proxy issues for those reasons. The expected timing of when we see the FECC micros is: First Implementations (2004). A larger number (2005). In addition to the FECC impact on the proxy, there are at least two problems that have been seen on the existing Ethernet Micro/Proxy system. Nancy and Ken pointed these issues out.
Ron MacKenzie 21-Aug-2003
Modified by: Jingchen Zhou 21-Aug-2003
Modified by: Ron MacKenzie 21-Aug-2003. Took out 2 things from item 5 which were cut/pasted from item 4.
Modified by: Ron MacKenzie 25-Aug-2003. Added new opition 3, the Greg option.