Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?
25.01.2025, 02:02:07
Начало Помощь Поиск Войти Регистрация
Новости: ООО «Скрин маркет системз», правообладатель программы «Система брокерского обслуживания «TRANSAQ» официально заявляет, что не ведет никакой деятельности в мессенджерах или социальных сетях. 
Подробности на нашем сайте  WWW.TRANSAQ.RU.

Просмотр сообщений

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - ddd323

Pages: [1] 2 3
1
Я вывел в таблицу Финансовые инструменты [слева] - поля "Мин. цена FORTS" и "Макс. цена FORTS". Хочу вынимать их оттуда в автоматическом режиме.
Но во время вечернего клиринга эти поля автоматически не обновляются!!! [очевидно событие "обновлены границы торгового диапазона" терминал не получает или не обрабатывает].
Прошу исправить во время одного из ближайших обновлений функционала.

На скриншоте: время 19.32 - 22 минуты после начала вечерней сессии. Сама таблица Финансовые инструменты не зависала - она успешно перемигивалась зеленым и красным цветом в зависимости от направления сделки. Видно, что границы торгового диапазона по RTS-3.15 в таблице "финансовые инструменты" остались устаревшими (81740 и 97920): например, в таблице заявок видна заявка в 19.25 (это была заявка по рынку) в ней верхняя цена уже свежая - 97360. В таблице зявок видны заявки на продажу (тоже по рынку), сделанные до вечернего клиринга, которые естественно демонстрируют устаревшую нижнюю цену 81740

P.S. Во время дневного клиринга, как ни странно, все успешно автоматически обновляется в моменты смены состояний рынка (поле "Состояние")
P.P.S. Я в курсе, что можно обновить насильно, вызвав форму "описание торгового инструмента". Но необходимо, естественно, автоматическое решение с надежным отображением новых границ торгового диапазона, когда бы они на сервере/бирже не менялись - тем более, что иногда, во время резких движений, они меняются в произвольные моменты времени внутри торговой сессии.

2
Сегодня, конечно день необычный, но ...
Сегодня на открытии скрипт подавал заявку на продажу по рынку по фьючу RTS-3.14. В логе получил следующее:
10:00:01 03.03.14 trades=242 Заявка выставлена. Номер: 17031
Заявка.   status:8   trnid:17031   orderno:0   validbefore:0   client:NNN     operation:-1   price:-1   yield:0   quantity:2   condition:0   condvalue:   brokerref:1   error:
10:00:01 03.03.14 trades=244 Заявка выставлена. Номер: 17031
Заявка.   status:9   trnid:17031   orderno:12234609262   validbefore:0   client:NNN     operation:-1   price:121480   yield:0   quantity:2   condition:0   condvalue:   brokerref:1   error:

Т.е. сначала сработал onOrder и показал статус 8 (OS_ACTIVE), а потом через доли секунды в onOrder пришел статус 9 (OS_CANCELLED), что вроде как означает согласно хелпу "Снята трейдером (заявка уже попала на рынок и была отменена)". Я эту заявку, естественно, не отменял. У меня вообще в коде операций отмены заявок в принципе нет. В 2-х соседних окнах по этому же инструменту тоже заявки не исполнились со статусом заявок 9.  В окне заявок в терминале - все эти неисполненные заявки в нем есть со статусом "снята" (по крайней мере сейчас, утром (в первый час торгов) не обратил внимание были ли они там.
Проэкспортировал тиковые данные с финама - на 2-й и последующих секундах торгов сегодня по цене 121480, т.е. по границе разрешенного торгового диапазона цен, где первая сегодняшняя свеча "остановилась", еще было сделано очень много сделок. (Поле unfilled я при подаче заявки не использую)
С количеством денег было все нормально (потом все эти заявки повторил в ручном режиме - они исполнились)
Брокер "Финам". Сервер 78.41.199.32 (HFT который)

Как объяснить этот феномен? Глюки клиента? Сервера? Стоп-торги, некорректно описываемые в статусе заявки, но после которых какие-то сделки у кого-то проходили?

3
Подсистема ATF / баг в onStopIndicator
« on: 29.01.2014, 22:54:47 »
При удалении индикатора с графика функция onStopIndicator не вызывается.
5.08.336.01 rev 55 ATF 1.20

4
С версии 1.18 trade_action:... возвращает 0 в случае ошибки.
При каких условиях возращает 0 функция trade_action::cancelOrder(trnid)? Если я выставил условную заявку, например, продать по рынку при достижении некоторой цены, а потом хочу ее снять и получаю в ответ 0, означает ли это что она гарантированно исполнится (предполагая отсутствие сбоев между сервером Транзака и биржи и на сервере биржи)?
Я предполагаю, что trade_action::cancelOrder(trnid) посылает запрос на сервер Транзака, тот проверяет, что там с условной заявкой, если она - активна, то сервер отвечает клиенту 0. Если так, то моя гипотеза верна (0 означает "гарантированное" исполнение), а вот если, например, после этого сервер Транзака пытается еще вдогонку на Биржу послать запрос - типа не исполняйте, то тогда еще есть минимальный шанс, что заявка успеет сняться без исполнения.

5
И то и другое поле указывают на наличие ошибки при выставлении заявки. Всегда ли эти два поля непусты одновременно? Или есть ситуации, например, когда поле error равно 1, а message пусто и наоборот?

6
Финам. Фортс. Фьюч на сбер SBRF-12.12
HFT сервер. версия терминала 304.12 (UID послал в личку Heller'у)
Заявка высталялась из onNewCandle на свече 14.03 сегодня (13.12.12) так:
var OrdrHash = new_object("hash"); OrdrHash["quantity"] = 1; OrdrHash["operation"] = OP_BUY; trade_action::transactMultiple(OrdrHash);
Денег на счете достаточно.
Получил в onATFOrderErr следующее:
SBRF-12.12 (sbrf1): Некорректный ордер: (10032) Цена сделки вне лимита Покупка  SRZ2

Где проблема: глюк терминала? биржа с диапазонами цен намудрила? финам с настройками сервера? 13-е число?

7
Уважаемые разработчики, есть несколько вопросов.
Все вопросы ниже относятся к ситуации кратковременно разрыва соединения, скажем секунд на 30 - такого которое восстанавливается терминалом автоматически и не приводит к появлению окна "Соединение с сервером потеряно".
1) Скрипт АТF выставил заявку, но ровно после ухода соответствующего пакета с этой информацией с компьютера, где стоит терминал, происходит разрыв соединения с сервером, и пакет этот до сервера не доходит. Запрашивает ли терминал какое-либо подтверждение со стороны сервера о получении пакетов со своими транзакциями? И если да, обрабатывается ли каким-либо образом эта ситуация: например, повторным выставлением данной заявки после восстановления соединения или вызовом onATFOrderErr с соответствующим сообщением об ошибке "заявка ваша до сервера не дошла"?
2) Выставил скрипт условную заявку, с условием по цене, ну или по времени (купить по рынку при наступлении условия). Произошел разрыв соединения, и так получилось, что целевое время или пороговая цена по этой условной заявке выполнилось как раз во время, когда отсутствовало соединения с сервером. Сервер, понятное дело, послал заявку на биржу, она там выполнилась. Вопрос: вызовется ли в скрипте после восстановления соединения onOrder и onTrade по соответствующей заявке?
3) Разрыв произошел в середине скажем 10-минутной свечи, после прохождения onNewCandle. Правильно я понимаю, что терминал после восстановления соединения получает порцию информации о прошедших на рынке за время разрыва связи сделках (изменениях цены) и по каждому из них вызывает в скрипте calc()?
4) В ситуации вопроса 3, допустим до разрыва была цена в последнем калке до разрыва 1000, мы пропустили 100 изменений цены (событий, инициирующих калк), каждое снижало цену инструмента на 1, т.е. на момент восстановления соеднинения объективно текущий close нашей свечи равен 900. Терминал тоже после получения порции пропущенной информации как бы обладает достаточной информацией, чтобы сказать, что текущая цена равна 900. Вопрос, когда я, в скрипте, используя, например, closе[0] узнаю, что текущая цена (closе[0]) равна 900? Я так понимаю по определению роли функции calc() лишь при сотом вызове калка после восстановления соединения?


8
Из документации: getAllOrderIDs() - получить массив идентификаторов всех заявок (включая условные, но за исключением стоп-заявок, по всем клиентам и бумагам, включая исполненные и снятые). (ver. 1.12)

Судя из этого описания, можно сделать вывод, что к стандартным ключам хэша заявки при работе с этой функцией должны добавится "название бумаги" и вероятно "тип заявки" (условная/обычная). Выполнил я значит нижеследующие операции.
var ARR;
ARR = new_object("array");   
ARR= getAllOrderIDs();
var hsh = getOrder(ARR[0]); // так сказать получаю хэш первой попавшейся заявки :)
signal::outputMultiple(hsh.size());
Получил в окне "12". Причем, если вызывать getOrder(trnid), где trnid = номеру этой первой попавшейся заявки, то получающийся хэш имеет всего 10 ключей. Т.е. действительно получается добавились 2 новых ключа. И точно среди них должно быть имя бумаги...
Перебрал все возможные судя по документации имена соответствующего ключа: secid, secname, sec, shortname, id, security, name
signal::outputMultiple(hsh["имя_ключа"]);
а в ответ пустота. (Делал это на свежезагруженной интре ATF1.16)
Короче фантазия иссякла.
Уважаемые разработчки, поделитесь секретным знанием какие новые ключи возникают у хэша заявки при использовании функции getAllOrderIDs()?
(А ежели их не возникает, то как же отделять заявки по одной по бумаге от заявок по другой, ведь в отличие от getActiveOrderIDs(), getAllOrderIDs() выдает номера заявок по всем бумагам?)

9
Давно заметил, но вот дошли руки написать. Проверьте, пожалуйста.
Летом финам сделал обязательное обновление и перешел с АТФ 1.8 на 1.15. У меня тут же в отчетах, которые я формирую по сделкам появились лишние пустые строки (в обычном виндовском notepad их не видно, но например при открытии в notepad++ или переносе в excel они тут же появляются). Собственно, мой анализ привел к следующим выводам:
Скрипт, выполняющий запись в файл: file.write("AAA\nBBB")
В версии 1.8 писал в файл (windows ANSI, в терминах отображения спецсимволов при открытии этого файла в notepad++):
AAACR LF
BBB
а в версии 1.15 начал писать в файл:
AAACR
CR LF
BBB

10
Уважаемые разработчики!
1. Правильно ли я понимаю, что такая конструкция будет работать:
function onTrade(var id)
{
    var trade = getTrade(id);
    var order_hash = getOrder(trade);
}
2. А если использовать строчку var order_hash = getOrder(trade["orderno"]);  то будет работать? Или вариант функции getOrder с входным параметром в виде значения строго зарезервирован за getOrder(trnid)?
3. Возможна ли ситуация, что хотя в момент исполнения данного трейда нам даже уже известен биржевой номер соответствующей заявки trade["orderno"], хэш order_hash придет не/недозаполненным, т.к. терминал не получил еще всей информации и соответственно во внутреннем хранилище переменных еще не имеет всех значений полей этого хэша (но будет их иметь, получив следующую порцию данных с сервера транзака)?  Или архитектурно это невозможно и, чтобы такое случилось нужен какой-то непредставимый вами сейчас технический форс-мажор? Иными словами, можно твердо расчитывать, что в момент исполнения трейда я могу получить исчерпывающую инфорацию по заявке, по которой этот трейд исполнился?
4. Какие поля будут присутствовать в хэше order_hash? Все классические отсюда: http://www.transaq.ru/dokuwiki/atf:%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D1%8B (из таблицы Структура заявки getOrder(id)), или, например, будут присутствовать только поля, которые можно получить с сервера биржы?
5. Более специфичный чем п. 4 вопрос: какие поля будут присутствовать и будут заполнены в том случае, если заявка по которой пришел этот трейд была подана на этот же регистр ФОРТСа (по которому выполняется этот onTrade), но через сервер квика, или через другой сервер транзака (например, у финама есть так называемый HFT-сервер Транзака, который не связан отношением "резервирования" и "взаимного снятия условных заявок" с основным и резервными серверами Транзака финама)

И еще до кучи, хотя это не имеет отношения к особенностям работы getOrder:
6. в ситуации описанной в п.5 на графике и скрипте, в котором этот onTrade выполняется, будет ли вызываться onOrder() по заявке, поданной через "другой" (не тот к которому сейчас подключен выполняемый скрипт) сервер Транзака но по данному регистру ФОРТса? Или иными словами какая у вас логика и архитектура заложена: событие, инициирующее вызов onOrder, связано с обработкой/сменой статуса заявки на сервере биржи (имеющей номер trade["orderno"]) ИЛИ строго с внутренней заявкой (с trnid) на этом же сервере Транзака, к которому подключен сейчас этот скрипт (т.е. нету trnid - не будет и вызова onOrder).

11
Прочитал недавно такую новость

С 17 сентября 2012 года ОАО Московская Биржа увеличит в 2 раза минимальный шаг цены и стоимость минимального шага цены для срочных контрактов на российские индексы (с исполнением в декабре 2012 года и далее):
фьючерс на Индекс РТС
маржируемый опцион на фьючерс на Индекс РТС
фьючерс на Индекс ММВБ
...
Новые параметры контрактов начнут действовать с вечерней дополнительной торговой сессии 17 сентября 2012 года*.
...
(оригинал здесь: http://rts.micex.ru/n1365/?nt=101)

Коллеги-разработчики, не поясните, чем это нам грозит: просто в стакане вдруг все цены станут кратны 10 и попытки подать заявки с явно указанной ценой, оканчивающейся на цифру 5 будут отвергаться сервером? Или еще что-нибудь?

12
После последнего финамовского (обязательного) обновления появился странный глюк.
У меня 2 счета подключено. Один кстати вообще на акции ММВБ, а другой фортсовый. Раньше при перезапуске транзак всегда включал счет, который то ли сохранен в конфиге, то ли был выбран в интерфейсе программы последним - перед закрытием. У меня и то и другое совпадает и вообще стоял фортсовый месяцами. Правда иногда если я включал в этот день ммвбшный приходилось вроде дважды перегружать транзак чтобы устойчиво стал опять фортсовый.

Так вот после последнего обновления по непонятному закону раз в 2-4 недели стал при запуске транзака выставляться ммвбшный. Например, всю прошлую неделю стоял фортсовый и даже ни разу ммвбшый я не включал, а в понедельник с утра - транзак запустился с ммвбшным. Ставишь фортс - а если транзак перезапустить - опять включается с ММВБ, то есть состояние не запоминает. И вторник начался с ммвб и среда. Это уже раз третий такая серия. Предыдущие разы транзак сам через пару дней переставал себя так вести и начинал с утра открываться с фортсовым (из конфига и тем с которым заканчивал работу вчера). Копался в ини- файлах транзака - там встречается фортсовый, а ММВБшный нет. В общем ничего не понятно, но с учетом того что это влияет на работу аты очень неприятно.  (ставить в 80 местах кода setclient пока лениво, хотя наверное правильно)

P.S. Все вышеописанное происходит естественно при неизменном конфиге, который был сохранен в положении "фортсовый счет". Я вообще конфиг только раз в 3месяца меняю, когда меняю фьючерсные контракты. Или счет в конфиге не сохраняется?
P.P.S. Не знаю важно ли, но в выпадающем списке счетов в интерфейсе транзака - ммвбшный счет у меня верхний, фортсовый второй, соответственно.

13
В руководстве по АТФ есть следующий пример:
var balance;  // Просто некоторые переменные
var x;        // предположительно испольщуемые
var money;    // роботом, которые мы сохраним
 
function init()
{
   var xml = new_object("xmlarchive");
   xml.loadfile("file.xml");
   balance = xml.loadvar("balance");
   x = xml.loadvar("x");
   money = xml.loadvar("money");
}
 
function onStopIndicator(var reason) {
   var xml = new_object("xmlarchive");
   xml.newdocument("file.xml");
   xml.savevar("balance", balance);
   xml.savevar("x", x);
   xml.savevar("money", money);
   xml.savefile();
}
Вопросы:
1) без первых двух строчек внутри function onStopIndicator(var reason) этот код будет корректно работать? (Объекты типа файл, созданные и "открытые" в ините имели глобальную область видимости. Если объекты типа xmlarchive такие же, то по идее без первых 2- строчек будет работать корректно)
2) Когда происходит реальное сохранение в файл на диске? Только при вызове xml.savefile(); или еще когда?
3) Я так понимаю onStopIndicator вызовется только при корректном закрытии по крестику в транзаке. Если я сниму процесс транзаковский через таск-менеджер - onStopIndicator  вызовется?
4) Почти риторический: я правильно понимаю, что если выдернуть комп из розетки - скрипт из примера мне переменные в файл не сохранит. И при следующем запуске скрипта прочитает мне то, что записалось "вчера" при корректном вызове xml.savefile(); из onStopIndicator?
5) Естественный, как следствие: xml.savefile() - нормально будет работать, если я его, например, из двух калков подряд вызову? А из 10? (из каждого калка вызывать не собираюсь, но несколько раз в долю секунды иногда вызывать надо, так как меняются значения переменных)

14
Блин, да еще 1.15 сделали в Финами обязательным обновлением... У меня все скрипты перестали работать.  :'( Я xml архивом не пользуюсь, сам с файлами работаю. Открываю файл на чтение в ините, потом закрываю, потом октрываю на wopen и пишу по мере работы скрипта. В частности есть запись в этот файл и в самом конец инита. (В общем все как у вас в тестово м примере на вики "Сохранение данных в файл" + запись в файл в конце инита). В 1.8 все нормально работало.
А теперь похоже file.close() перестало работать. В чем проявляется:
1)  при запуске скрипта - по прежнему скрипт при запуске выполняет инит 2-3 раза (старый глюк, я надеялся в 1.15 исправился. для справки у меня 3 графика с автозапускаемыми скриптами), так вот при чтении из файла с переменными при втором запуске инита (при первом запуске - он мне все  переменные нормально заполняет) мне заполняет переменные пустыми местами. Вывод запись в файл в конце инита не состоялась корректно. Возможно потому, что файл плохо закрылся или "недооткрылся". Проверяем эту гипотезу:
2) пытался это лечить следующим образом (ниже кусок инита):
file.ropen();  // это было в изначальном скрипте
чтение переменных из файла;  // это было в изначальном скрипте
file.close();  // это было в изначальном скрипте
while(file.isopen()) {file_log.writeLn(getFormattedDateTime(getServerTime())+": не успело закрыть");}
file.wopen();  // это было в изначальном скрипте
запись переменных в файл // это было в изначальном скрипте
file.close();
В результате транзак при запуске графики не открывает - там пустые места а в лог - в другой открытый файл  (file_log) пишет "не успело закрыть". я пару минут, пока она мне в файл 100 МБ накатало подождал. В общем не успело оно за 2 минуты файл закрыть...
В общем получается, что файл действительно не закрывается после чтения

Но увы не все так просто. Если закомментарить while - После 3-го запуска инита вызывается (быстрее чем через 2 минуты) onNewCandle , в конце которого тоже стоит сохранение в файл, а в начале (при первом запуске onNewCandle ) file.wopen(). И при этом, правда с глюками (переменные==0 не сохраняет, не смотря на использование as_string(переменная)) сохранение работает.
Т.е. - есть альтернативная гипотеза - при втором/третье вызове инита некорректно работает file.ropen из-за слишком быстрого подряд вызова. Но почему не работает - может потому что file.close(), которое в конце инита не успевает исполниться, или вообще не работает?  ;)
Ибо, если его file.close() из конца инита убрать, т.е. когда file.close() точно не работает - наблюдаются те же эффекты.
И опять же в 1.8 то же выполнение инита 3 раза подряд не мешало корректно работать и открывать файл на чтение, даже несмотря на то, что он был в состоянии "открыт на запись" (file.close() в конце инита не было) перед вторым и третьим запуском инита.

Проверяйте file.close и в любом случае исправляйте тройной вызов инита.

15
1. Я правильно понимаю, что id клиента устанавливается индивидуально для каждого скрипта (графика)?
То есть установка разных id на разных графиков друг другу не мешает?
2. Аналогичный вопрос про сам програмный клиент Транзак - на панели инструментов есть поле выбора номера клиентского счета. Изменение счета в этом поле - поменяет id во всех графиках со скриптами (где допустим в функции init был установлен через setClient некий id) или наоборот нигде?

Pages: [1] 2 3


Войти

Powered by MySQL Powered by PHP Powered by SMF 2.0.10 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!