You can have the main TWS window minimized by using this setting in config.ini:

?

MinimizeMainWindow=yes

?

I can’t guarantee that this will work consistently on macOS as I don’t have access to a macOS machine. TWS has a habit of un-minimizing itself when certain things happen, and IBC has to try and catch that and re-minimize. It may well not catch all cases, since few people use this setting (and neither do I, so I’d never notice unless someone tells me).

?

On macOS, it’s not possible to hide the terminal window which displays the information about the log file. The Linux and Windows scripts provide a means to do this, but this doesn’t carry over to macOS. I dare say that there is technically a way to do it, but without being able to get my hands on a macOS computer I can’t really figure it out (if anyone reading this has any ideas, please let me know).

?

Having said that, there is actually a way to run without the terminal window, but it has some disadvantages. If you look at the IBC log file you’ll see a line like this:

?

Starting IBC with this command:

?

The following line is a command that you can run directly from a command shell (presumably Bash), and it will run IBC and TWS in exactly the same way, but without the ‘wrapping’ provided by the normal shell script (if the command includes a -Drestart=… switch, remove it). Also redirect stdout and stderr to a file using normal redirection operators, to capture log output from IBC .

?

The primary disadvantage is that some IBC features won’t work properly: for example, autorestart will succeed in restarting TWS, but you’ll have to re-authenticate via 2FA every time (for a live account). (Actually I need to verify that that last statement is really true: the 2FA automation probably should work provided you don’t let the 2FA prompt time out on IBKR Mobile).

?

Frankly I see no real benefit in trying to hide TWS from view. It won’t save any resources. In my view, a much better approach is to run TWS in a virtual machine that’s used for nothing else, and access it when needed via VNC or whatever remote access mechanisms macOS provides.

Richard

Read the notes for the TWS_MAJOR_VRSN variable in twsstartmacos.sh. It says this:

?

#?? TWS_MAJOR_VRSN

#

#???? Specifies the major version number of TWS to be run. If you are

#???? unsure of which version number to use, run TWS manually from the

#???? icon on the desktop, then click Help > About Trader Workstation. In the

#???? displayed information you'll see a line similar to this:

#

#?????? Build 10.19.1f, Oct 28, 2022 3:03:08 PM

#

#???? The major version number is 10.19. (Note that this is different from

#???? the equivalent Windows and Linux settings because the macOS installer

#???? includes the period in the install folder name).

#

#???? Do not include the rest of the version number in this setting.

?

But you appear to have:

?

TWS_MAJOR_VRSN=1019

?

Richard

?

?

Mark

?

Perhaps you didn’t see, or didn’t read properly, my post on 10 September? If not, please read it!

?

Then, please, can you respond to what I asked? Which was this:

?

Have you actually got this working, ie cross-connect login, running TWS manually, ie without IBC? If so, then please send me the actual jts.ini that it uses.

?

If you haven’t had it working manually, then I really don’t understand why you started this thread: IBC is not magic: it can’t make TWS do something that it doesn’t do when run manually.

?

Thanks

?

Richard

That’s irrelevant now. I’ve understood the difference.

?

I need you to respond to my post from yesterday.

?

?

Mark

?

I don’t think this is going to work. I’ve done the changes I suggested, and when IBC runs it sets the right things in jts.ini, which ends up like this:

?

[IBGateway]

ApiOnly=true

?

[Logon]

Locale=en

s3store=true

tradingMode=p

TimeZone=Europe/London

displayedproxymsg=1

UseSSL=false

?

[Communication]

Peer=65.90.92.40:4001

?

But when TWS runs, the UseSSL option on the login screen is checked, ie it ignores UseSSL=false in jts.ini. If I run TWS manually with this jts.ini, and then uncheck the UseSSL option on the login screen, it won’t let it run unless I agree to use SSL.

?

So it seems to me that IBKR have given you bad information: telling you to make sure UseSSL=false in jts.ini simply doesn’t help. The fact is that current versions of TWS insist on using SSL, and there’s no way around it.

?

Now it may be that I’m missing something, and there is additional settings that are needed. So my question to you is this:

?

Have you actually got this working, ie cross-connect login, running TWS manually, ie without IBC? If so, then please send me the actual jts.ini that it uses.

?

If you haven’t had it working manually, then I really don’t understand why you started this thread: IBC is not magic: it can’t make TWS do something that it doesn’t do when run manually.

?

Richard

?

Mark

?

At the moment, the answer is ‘no’: there’s no way to disable SSL with IBC.

?

However, it should be possible to amend IBC to allow this.

?

I’m out for the day, so I can’t look at this now. I’ll try to look into it at the weekend.

?

However in the meantime, what version of TWS are you using? My login screen (10.19 or 10.24) doesn’t look like that. I’m unwilling to make changes to IBC that only work for old versions of TWS, so you’ll need to be on the current stable or latest version.

?

?

?

Can you please explain what you’re trying to do, because I have no idea what you’re talking about. What do you mean by ‘cross connected logins’?

?

TWS no longer allows not to use SSL. If you change the UseSSL setting in jts.ini to false, TWS automatically resets it to true.

?

Is it possible to do what you’re trying to do without using IBC? If so, then tell me exactly what this involves and I’ll look into it. If it’s not possible, then there is certainly nothing at all that IBC can do about it.

?

Richard

?

?

?

No idea. Exit code 137 means that the process has been sent a KILL signal. Nothing in IBC ever does this, so there must be some external reason for it (for example, running out of memory would do it).

?

Send the IBC logfile (attach it, don’t quote it in the post): it might provide some useful info, but probably not if you haven’t changed anything.

?

Richard

?

?

Alistair

?

The way to avoid this is not to do something that causes it to happen!

?

I realise that’s a bit vague, but actually it’s quite difficult to make this happen at all. I’d be interested to see the log file(s) immediately preceding the first one that gave problems.

?

For example, in your case, the autorestart file was found in C:\Jts\fgihapeajlfebknncbmjpfjgkajakgelpmcnfhif. Given that you haven’t specified TWS_SETTINGS_PATH in your start script, the only ways an autorestart file could be there is if:

?

• EITHER you previously set TWS_SETTINGS_PATH to that folder, OR you ran the self-updating version of TWS
• AND you let it run to its auto-restart time
• AND you killed the process after auto-restart began but before it completed.

?

So probably the best advice is this: don’t shut down TWS/Gateway by killing the process or by closing the banner window unless you’re absolutely sure that auto-restart is not under way.

?

Having said that, it’s perfectly possible that I’m missing something (because what I’ve described above is pretty rare), and that’s why it would be helpful to see those earlier logs if you still have them.

?

Richard

?

?