Implementing "LAN-wide Variables" with a broadcast? Other approches?

Good day,

this is not a truely VB6-related question (although VB6 is the language used to solve this problem); it's more a general question about the approach to take. Maybe someone has had the same problem earlier and wants to share his/her thoughts.

My VB6 application runs on several PCs in my LAN. Now the need arises, that any of these PCs must have read/write-access to the content of a few variables.

This is the problem: how do I realize such variables with scope LAN

As time goes on, some additional PCs start the application, others stop to use it. Sometimes no PC at all is using the application, and sometimes all PCs are powered down. Sadly, there is no PC which can be said to have a master status, so storing the content of the variables in a dedicated place is no option (it simply might not be available).

Also using the cloud is no option, because the data must not leave the LAN.

Is sending an UDP broadcast to 192.168.255.255 a possibility, as soon as a PC wants to alter the content of a variable? Can this even be done with VB's Winsock control?

Has anyone come up with a better solution?

Thanks very much in advance!
Donar

Quote:

---

Sadly, there is no PC which can be said to have a master status, so storing the content of the variables in a dedicated place is no option (it simply might not be available).

---

Then how can this be possible? Let's say when 2+ pcs are running and they share the variable in some manner. When those pcs shut down and a 3rd pc comes up, it will have no idea where to get that shared variable. And if it were to use some default value, then if one or both of those other pcs come up, you'll have a conflict on which variable to use. If the pc using the default value was doing so incorrectly, then everything it did while using that variable was incorrect.

Your scenario is a nightmare & I can't see any way of sharing some variable without having a common, accessible, place to store & retrieve it

Maybe you can describe what the variable will contain & how it will be used?

The last OC send email with 2048 key...EXor to the data...
Each PC must read the same email...and for any alter have to send it back as a new one...Always the new one has the latest info...

LaVolpe's right... your'e going to need something that acts as a central repository. Usually a database is used for this purpose, but it still needs to reside on a system somewhere.

-tg

Quote:

---

Originally Posted by LaVolpe

Maybe you can describe what the variable will contain & how it will be used?

---

Thanks for your answer.

The application controls electric devices in the LAN, i.e., sends commands to turn some attached power plugs on/off, reads the states of all outlets, etc. Think house automation.

When a PC in the network sends a command to such a device (governed by a TCP protocol), this may take anything between some milliseconds and up to 20 seconds, depending on the command. In this time the device is not accessible for other PCs, which possibly want to send a command as well.

On the devices there is no possibility to store status information, nor to obtain information if it currently is executing anything at all, hence the need for a "LAN-wide variable".

This variable will simply store, which of the (several dozens) devices are currently being used. A bit per device is enough. I can think of a bit field in the length of all devices, 1 = being used, 0 = available.

The one PC coming first is granted access rights and the bits is set. Another PC wanting to access the same device has to wait, because the bit is 1, but I can handle that easily in the local program instance.

The question is, do I generate too much avoidable network traffic with such broadcasts? I do not even know so far, if broadcasts are supported by VB6...

@georgekar. Thanks for your idea. No, email is no option, the whole thing must be quick and responsive.

If these electronic devices can be polled, then you wouldn't need a stored variable? Example, can't turn something off it it is already off, i.e., no response = not on? If polling works, then that shared variable only needs to be shared while more than 1 pc is on line & never needs to be stored when all pcs are off-line

Also, wouldn't some person manually turning something off, upset that shared variable (if it were to exist)?

Quote:

---

Originally Posted by Donar

...sometimes all PCs are powered down.

...using the cloud is no option, because the data must not leave the LAN.

---

As long as there's no other machine on that LAN which is guaranteed "On",
(all PCs Off), you will have a hard time to manage "LAN-global-information".

Easiest solution is always, when you have a "central point which is reliably there":

If that can't be one of the PCs, then you will have to find something else - a Machine
or Device on the LAN which qualifies as being "Always-On", to hold the Information...

E.g. some Routers offer an USB-Port which allows to plug-in a small USB-HDD
or an USB-ThumbDrive- where you could place that "global information" on then -
those Routers often have SMB-Services available, and can offer the DiskSpace
of that USB-Device as a Network-Share.

An alternative to such a "Router-hosted USB-Device in NetworkShare-mode" would
be "modded Linux-Routers", where you could set-up the in-built WebServer to
manage the same global info (storage then managed e.g. per PHP-script, working
against a small InMemory-file on the /tempfs behind the WebServer).

One can buy such (usually Linux-based) Routers for about 30-50 bucks.

In case you want an affordable x86-CPU-based device with low power-consumption -
there's quite a few options in the meantime as well - not as cheap - but "VB6-programmable".

Here's one which comes fanless (with a preinstalled Win 8.1, 64GB-SSD, 1GBit-Ethernet-port, WLAN):
http://www.newegg.com/Product/Produc...82E16883218044

Also with preinstalled Win 8.1, but even smaller and less power-consumption,
sporting a 32GB-SSD + 100MB-Ethernet-port ...
(reviews already out - but global distribution starting in december as I read it):
http://www.computershopper.com/deskt...box-pico-pi320

And the cheapest "VB6-programmable" device out there currently is perhaps this offer from MS
(99$ for an Intel-Quadcore ,1GB Ram, 16GB-SSD):
http://www.microsoftstore.com/store/...ctID.307250100

The alternative for the above "central point, central server-device"-approach is to
develop a P2P-solution - but that is (much) more difficult to accomplish programming-
wise - each PC would need to run a (yet to write) P2P-capable Server-Class, which
constantly communicates per "heart-beats" to share the info across all P2P-Server-
instances, but that sharing (with regards to where the most recent info is located,
reliable take-overs when a PC (or the Server-App) goes down. That will take days
to program and test, if it's not a field you have much experience with - and a good chance
"to fail utterly" at the attempt...

Well, it depends on your "hourly rate", if potentially bying a dedicated low-power-server-
device is not the cheaper option.

Olaf

Olaf, many thanks for your reply and the time it took to write it, I will examine each given option. Kudos.

Donar

@LaVolpe, thanks, I might come back to the details later. Manual intervention is no problem (and happens regular), that's all solved. The devices' outlets are pollable.

Pollable? Then thinking off top of my head an outline might look like:

1) PC comes online: broadcast and ask for current Master pc
2) If no Master, then that PC is master & returns it's IP to any future broadcasts for the Master
-- master keeps table of online slaves
-- slaves keep reference to master
-- If first pc online then obviously no devices are currently executing commands
3) Master keeps a queue of actions, per device
-- Queue can be smart and remove items that are in conflict. Ex: new queue command is to dim the lights, but an existing queue command awaiting execution is to turn lights off. One of them is obsolete & depending on your priority logic, one of them can be removed from the queue
4) All slave pcs send commands to the master. They inform master when going offline so Master table can be updated
5) When Master is about to go offline,
-- forwards "new Master" message to the slave chosen as new master; removing slave from its table
:: this new master - old master comm will need to transfer active slave list + queue (if any)
-- new master loops thru its table & informs slaves of itself being new master,
:: if commands come in to old master during this 'inform loop' (i.e., slave#n sends command before it was sent a 'new master' message), then need to handle that scenario. Possibly just forward command to new master

Here's my solution to that problem (if I understand it correctly, that is):

Also, be sure the "Locks" sub-folder exists. I take care of that elsewhere, but it could be embedded into the LockService call.

Also, mine's rather more involved. I have more involved .lck file names, but the additional information for the name is a date and ID of the actual service being accessed. For instance, my .lck name construction looks something like this:

sIDAndDate = sID & "-" & Format$(dtDate, "mm-dd-yyyy") & "-"
sServiceLockFile = AppPath & "Locks\" & sIDAndDate & sService & "LockFile.lck"
sServiceLockName = AppPath & "Locks\" & sIDAndDate & sService & "LockName.lck"

Enjoy,
Elroy

Code:

---

Option Explicit
Dim sServiceLockFile As String
Dim sServiceLockName As String
Dim lServiceLockFileNum As Long
Dim bServiceIsLocked As Boolean
'
Private Declare Function GetComputerName Lib "kernel32" Alias "GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long
'

Public Function LockService(sService As String) As Boolean
    '
    ' Returns True if lock is successful.
    Dim sMrnAndDate As String
    Dim iErr As Long
    Dim sMachine As String
    Dim sMsg As String
    Dim iFle As Long
    '
    sServiceLockFile = App.Path & "\Locks\" & sService & "LockFile.lck"
    sServiceLockName = App.Path & "\Locks\" & sService & "LockName.lck"
    '
    Err.Clear
    On Error Resume Next
    If bFileExists(sServiceLockFile) Then Kill sServiceLockFile
    iErr = Err
    On Error GoTo 0
    '
    If iErr = 0 Then
        lServiceLockFileNum = FreeFile
        Open sServiceLockFile For Output As lServiceLockFileNum
        Print #lServiceLockFileNum, MachineName
        '
        iFle = FreeFile
        Open sServiceLockName For Output As iFle
        Print #iFle, MachineName
        Close iFle
        '
        LockService = True
        bServiceIsLocked = True
    Else
        If bFileExists(sServiceLockName) Then
            iFle = FreeFile
            Open sServiceLockName For Input As iFle
            If Not EOF(iFle) Then Line Input #iFle, sMachine
            Close iFle
        Else
            sMachine = "UNKNOWN"
        End If
        sMsg = "Service is locked at this time."
        MsgBox sMsg, vbCritical, App.Title
        LockService = False
    End If
End Function

Public Sub FreeService()
    If bServiceIsLocked Then
        Close lServiceLockFileNum
        bServiceIsLocked = False
        On Error Resume Next
        Kill sServiceLockFile
        Kill sServiceLockName
        On Error GoTo 0
    End If
End Sub

Public Function bFileExists(fle As String) As Boolean
    On Error GoTo FileExistsError
    ' If no error then something existed.
    bFileExists = (GetAttr(fle) And vbDirectory) = 0
    Exit Function
FileExistsError:
    bFileExists = False
    Exit Function
End Function

Public Function MachineName() As String
    Dim lSize As Long
    Dim sBuffer As String
    Const MAX_COMPUTERNAME_LENGTH As Long = 15&
    '
    sBuffer = Space$(MAX_COMPUTERNAME_LENGTH + 1)
    lSize = Len(sBuffer)
    If GetComputerName(sBuffer, lSize) Then MachineName = UCase$(Left$(sBuffer, lSize))
End Function

---

Also, as a further caveat, it'll only work if one copy of your program is running on any particular computer (which I make sure of). Also, it'll only work for one lock at a time within the program, but that could be enhanced if you needed it.

Ahhh, and as I think about it, yet another caveat. For server based applications, I always have clients execute the actual .EXE file off of the server. That way, the App.Path will be the same for everyone. If you're running local installations, you'll have to deal with App.Path differently. A server installation sure make updates easy though.

Hmmm, but if you're just trying to share a handful of variables, and the issue isn't about locking, then why not just set an ASCII file out on the server somewhere and read it everytime you want the value for the variables, never truly keeping them in memory. And, if you're worried about someone else changing them before you get a chance to write them, use my above locking scheme with a retry for some period of time. IDK, it just seems like this is fairly easy, and server file IO should be fast enough to not worry about any time delays of not keeping them in memory.

^^ Elroy. The issue here is that there is no guarantee any 'server' will be online at all times or that a 'server' is even exists

Hmmm, you want to share variables on a LAN that doesn't necessarily have a stable file server? Interesting. That's not a problem I've had to solve before, but it is a somewhat interesting one. Heck, even peer-to-peer communications need a tracker server. It seems that you'd have to specify certain machines as "tracker" machines, depending on at least ONE of those tracker machines being on at any point in time. If I could depend on one (in a group of machines) being on at all times (regardless of which one), then I could do it. Otherwise, I'm not so sure.

Yeah, this isn't an easy nut to crack. Heck, let's say that you have 5 machines. They're all off. Machine #1 comes on and changes the variables, then it's turned off. Machine #4 comes on and wants the value of the variables. I don't see any way for it to happen.

IDK, maybe find a couple of registers in the router or switch where you could stuff them, but that would be very limited. I think you're trying to do something that's not going to work well even if you figure out something.

Regards,
Elroy

p.s. Just upon further thought. Some routers and switches do have USB ports. Maybe you could figure out how to access that storage. Bottom line, you've GOT to have some stable LAN storage or it ain't gonna happen.

Yep, some always-on device with local storage is simply a requirement. As pointed out already it is quite easy to have an un-updated peer come online when all updated peers are off.

So that leaves you with the need for at least a small NAS device always left powered on. This can range from a USB flash drive pluggd into a router supporting NAS to a dedicated device to do the same thing. These range from small and cheap to larger and more reliable:

Attachment 119725

However if this is about serious home automation you should consider that SOHO routers with onboard switches and WiFi access points have "blind spots." Many of them disable the Ethernet switch and WiFi radio and can't serve DHCP while being updated or rebooted, and they can freeze in that state. You may find you need to "reboot" your router for lockups even more often than you do the cheapest of NAS devices.

The normal solution is a "hard" Ethernet network with a reliable dedicated switch and preassigned fixed IP addresses for critical devices. This can then be connected upstream to the multifunction "router" though you may have to configure the DHCP range to be smaller than the entire subnet to leave unmanaged space for the fixed IP addresses.

Another idea.
We can save status info on each device. One info is the last master. So any pc insert to the net of devices, ask for a specific device if it's granted or not, and if is ok take the ownership but writing to stat us info the code id.
So we need a master overlordo pc that can reset every device to stand by condition. So for every day use, any pc can operate devices and before shut down mast restore the status info.
Any other pc can read if a device is available, and if not can determine which pc grant it, and maybe can asc to take control. This swap control is a later change of status info, by a key provided from last master of the device.

Quote:

---

Originally Posted by georgekar

Another idea.
We can save status info on each device. One info is the last master. So any pc insert to the net of devices, ask for a specific device if it's granted or not, and if is ok take the ownership but writing to stat us info the code id.
So we need a master overlordo pc that can reset every device to stand by condition. So for every day use, any pc can operate devices and before shut down mast restore the status info.
Any other pc can read if a device is available, and if not can determine which pc grant it, and maybe can asc to take control. This swap control is a later change of status info, by a key provided from last master of the device.

---

That's basically the same P2P approach, LaVolpe already outlined (in more detail) in post #9.

The problem with that is to ensure *reliably* reaching "all other PCs" - because
when not reaching *all* of them per Ethernet, you might miss the currently active Master,
ending up with two Masters.

The other problem (or slightly related to that) is *reliably* taking over ownership,
when a current Master goes down (what if the machine or the process which answers
the Ethernet-requests, goes down unexpectedly, without a chance to hand over the
Master-Status, the other clients possibly ending up with "no Master" - one that is not
reachable, running into LAN-connect-TimeOuts and stuff...).

There's quite a lot of possible fallacies with such an approach which need to be solved -
and a load of testing involved - taking days, maybe a week, until such a thing might run
relative well (also depending on the size of the LAN and the reliablity of the Ethernet-
connections there).

The question I was asking is, if that week of work worth a 50-200$ device which
takes up low power and can remain "always on" (playing central server).

Olaf

Even a simple counter is impractical in P2P. It only works if the data is "fuzzy" and doesn't require precision.

Thanks all very much for your time, it's being estimated.

It's possible that I am going for a hardware-backed solution, it surely seems to be the cheapest way.

However, if only for academical reasons, I am going to play with the following simplified scenario (there are more PCs and more IP-Plugs, also each IP-Plug controls several outlets, but for simplification's sake let's assume, there are 4 PCs and 4 IP-Plugs with 1 outlet each). Please keep in mind, that the IP-plugs can only be polled if they deliver power to an attached device, nothing more.

Do you see any problems with this scenario?



PLAYERS:

4 PCs A, B, C and D.
4 IP-Plugs 1, 2, 3, 4.



SETTING:

The operators of the PCs can give jobs to the IP-Plugs.
There are different jobs of different duration.
One can not ask the IP-Plugs anything other than if they currently provide power to a device or not.
In particular, one can not ask if a device is busy with a job; it can be or not.
The desired state is, that the PCs come to know, if a device is busy with a job or not.
There is a joblist of 1 bit per device, 1111=all busy, 0000=none. (See post #5.)
If a PC wants to give a job to a device, it must do this via a joblist-keeper, as follows.



TO DETERMINE THE JOBLIST-KEEPER:

(BC=Broadcast, Msg=Message)

No PCs are active.
A comes online.
A: BC "Who is the boss?"
Timeout:A assumes Boss status. Joblist=empty.
No more BC neccessary, no reply=A is alone.

A is still online, B comes online.
B: BC "Who is the boss?"
A: Msg to B: "I am boss."
Timeout:B assumes Viceboss status.
B: BC "I am viceboss."
A: Msg to B: "Here's a copy of the joblist."
B pings A periodically.
A pings B periodically.

A, B are still online, C, D come online.
C: BC "Who is the boss?"
A: Msg to C: "I am boss."
B: Msg to C: "I am viceboss."
D: BC "Who is the boss?"
A: Msg to D: "I am boss."
B: Msg to D: "I am viceboss."
B pings A periodically.
A pings B periodically.
C, D ping A, B periodically.

A, B, C, D are still online, A abruptly goes offline (power off).
B receives no ping response from A.
B: BC "I am boss."
C, D update, that B is boss in place of A.
B: BC "I need viceboss."
C, D update, that no viceboss exists any longer.
C, D: Msg to B: "I am available."
B picks the first answer, say D.
B: Msg to D: "Here's a copy of the joblist."
D assumes viceboss status.
D: BC "I am viceboss."
B pings D periodically.
D pings B periodically.
C pings B, D periodically.

B, C, D are still online, D abruptly goes offline.
B receives no ping response from D.
B: BC "I need viceboss."
C updates, that no viceboss exists any longer.
C: Msg to B: "I am available."
B picks the only answer.
B: Msg to C: "Here's a copy of the joblist."
C assumes viceboss status.
C: BC "I am viceboss."
B pings C periodically.
C pings B periodically.

B, C are still online, B abruptly goes offline.
C receives no ping response from B.
C: BC "I am boss."
C: BC "I need viceboss."
Timeout:C is alone.

B goes offline as well.
But nobody cares, because the devices can't be operated by nobody.
No PCs = no jobs being started.
Possibly still running jobs come to a halt at the latest in about 30 seconds.
This means for the first PC coming online into the LAN, that it has to wait for 30 seconds.

Worstcase scenario:
A, B, C, D are online, A is boss, B is viceboss. A and B go offline abruptly.
Because C, D ping A, B periodically, it isn't long before they are boss and viceboss.
Because they received no answer at all on "Who is boss?", C, D have to wait with new jobs for 30 sec.



TO GIVE A DEVICE A JOB:

A, B, C are online. A is the boss, C is the viceboss, B and C want to give device 4 a job.
B, C know that A is the boss (see above for the reason).
B: Msg to A: "I have a job for 4."
A checks joblist and reads xxx0.
A updates the joblist to xxx1.
A: Msg to C: "Here's a copy of the joblist."
A: Msg to B: "I gave the job to 4."
C: Msg to A: "I have a job for 4."
A checks joblist and reads xxx1.
A: Msg to C: "4 is busy, try later."

I've dealt with various redundant systems and one, for instance just uses the "simple" approach of each device becoming "bus" master based on a variable delay in no traffic on the bus.
So, for instance you have three devices that when powered on each wait a varying amount of time for a "heartbeat" message from the master. In the one case, each device waits 300ms longer than the other, so device A will take control and start transmitting the heartbeat if it doesn't hear a heartbeat within 300ms. The second, B, will start transmitting the heartbeat after 600ms of "silence", and the third, C, after 900ms.
Of course, these are embedded systems so generally are all powered on at the same time, and take about the same amount of time to boot, as the software is the basically identical, with the exception of the timeout periods, whereas yours would not be, but the principle might still work.
If you have a limited amount of data that makes up the status that needs to be shared, that could be the contents of your heartbeat message.
Each machine that comes on line, if it senses the heartbeat, will get the latest configuration from the heartbeat message, and can request an enumeration from the master for use as an ID and determining what delay it should wait before assuming mastership if the heartbeat stops.
If it doesn't get a heartbeat after a default period on startup, it can start transmitting a heartbeat to let others know it is the master, and do the polling to get the initial state of what is on or off, plus wait the requisite time for any possible unknown commands to be processed, or in reverse order if necessary. If a second one happened to come online at exactly (close enough) the same time and also started transmitting a heartbeat message, the transmitting machines should detect that and do something like Ethernet does for collision detection, each choosing a random amount of time to wait, and then if not heartbeat received, start transmitting again. since the wait period is random, one machine or the other should start first, and the second will become a remote monitor and request an enumeration.
All machines will have an enumeration to ID themselves in the heartbeat message if they become master, and all have the same information so can pickup where the previous master left off.
They will pickup in enumeration order to reduce conflict in the turnover.
The random timeout after collision has been working for over 40 years with Ethernet, although originally critics said that would never work, so the theory is fine for this application.
Since there is only one master that transmits the heartbeat, the "handshaking" is easier since you don't have to have the monitors pinging other devices to see who is there, and Master to New Master transition should be simplified since all devices should have the same information when mastership needs to transfer.

I once had a timing issue problem (back in about 1998) that I had a programmer working on. He kept trying to solve it in software. I forget the exact issue but the issue wasn't directly solvable, so he tried backing up a level and solving it at a prior level. That proved to be untenable too. So he kept wanting to back up yet another level. After you back up one level and it won't work (two at the most), you've proved through induction that it can't be done, but this programmer just couldn't get that through his head. He thought he'd find the answer after backing up enough levels.

The above discussion has much of the same flavor to it. Bottom line, one of two conditions has to be true, or it's an unsolvable problem: 1) you've got to have some permanent LAN storage SOMEWHERE; or 2) you've got to have a system where at least ONE machine (any machine) is always on. If it's possible for all the machines to be off, and then a random machine turned on and expect to get the LAN wide values, it ain't gonna happen.

Now if you can guarantee that at least one machine (not necessarily the same machine) is always on, the issue becomes trivial. You could certainly look into some Windows NT Server API calls to do interrupts (fire an event) in your software, but a simple solution is just to create a shared folder in some common location on every machine that's interested in these variables (say C:\SharedVariables). And then, everytime someone changes the values, write to all the C:\SharedVariable folders that are visible, with a datestamp in the "shared.txt" (or whatever) file in those folders.

Everytime you want to read the variable values, read all the visible c:\SharedVariables\shared.txt files you can find, accepting the one with the latest date stamp. If you want to "hold" the variables for a while so that you can possibly change them and re-write them, institute some kind of locking like I discussed in post #10. You'd have to also have error trapping in your code to tell the use when the variables were locked by another user.

To me, this is all relatively straightforward. However, again, it won't work if there's ever a chance that every single machine on the LAN can be turned off. If that happens, the next machine to turn on will simply read it's own version of the c:\SharedVariables\shared.txt variables, which may or may not be the lastest ones. Don't over-think it. It's an obvious and easy question with an obvious and easy answer.

@passel: thanks for the comparison with Ethernet itself, I have a good book on Ethernet in my shelf and grabbed it :)


Elroy, thank you very much for your contributions. In general, I agree unconditionally with what you say, but not with the setting lined out here. I suspect you did not see the elaboration after the first few posts; may I humbly point you to the first few lines of post #18?

The last changed value is guaranteed to be not interesting any longer after at latest 30 seconds. Hence, if the first instance of the application is started and finds itself alone in the LAN, it waits for 30 seconds. Then it knows for sure, that all devices are unbusy: we have a well-defined state.

I'd get somehting I can toss a database on to... when one of hte machines makes a request, it writes to the database, I requested item XYZ at hh:mm:ss time.... then if anyothers want XYZ, you get the latest time there was a request, and if it's been more than 30 seconds, allow the request and update the time... otherwise set a timer and apuse for 30 seconds and try again.

-tg

My simply idea mr Olaf isn't in the demonstration of the use of a master pc. I think about it as the "resetting" mashine, as a back up. Why? Because if any other pc grant ownership while is off then we have to take action. So my basic idea is that any device has some info to send...in any request...who is the owner is one of the valuable info. If we demant a device to operate then we need to contanct with it in a channel always open for info and control. But the control has to be encoded with keys. The master pc unlock all the devices. It isn't a relationship of a master and slave couple. We have "terminals" and "devices". Any device we say that allow one terminal to control each time. So What happen if we have a broken control? Can we have two terminals to believe that they have the control? Acting the info line, we get info for two things...the last owner and if we have an active control.
So for the owner info an ID is ok. For the active control the device at some interval check if "info" from the owner asked. If yes then an active control is operated. So two vars...owner id and active control help us to split the control to as many terminals we want.
Logic conclusions
If a device is out of order no iinfo return in any way.
If a device has lost conection to the system then suposed to lost active control (so the terninal with the ownershio can return feedback to the user..."bad connection"
The special situation is the terminal to terminal transfer of control by means that we operate a standard transfer not an accidently one. This may needed if the terminal has to get out of order and has jobs to place in another terminal.