единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке

[fed]

Поскольку тема окончательно ушла в оффтоп, я тоже, пожалуй, поучаствую:
По поводу расширенной поддержки:
1. Уже после переезда в Турцию, я пытался узнать (для пары знакомых клиентов), оказывается ли подобная поддержка для России и сколько она стоит. Сразу скажу - действовал я неформально, по старым контактам в Микрософт. Возможно - по официальным каналам, я бы получил другую информацию. Так вот - в продажно-маркетинговых подразделениях MBS-Russia про подобную поддержку либо вообще не знали, либо чего-то очень давно слышали, но никакой конкретики не знают. В службе поддержки сказали, что они,конечно, про это слышали, но, вроде бы, она в России не оказывается. Может быть, если сразу много клиентов запросят возможность покупки этой поддержки, ее и начнут оказывать, но в данный момент ее просто нет.
2. Расширенность поддержки не гарантирует ее качества. Я тут как-то ездил к клиенту, у которого порядка 10 дней подряд каждые час-полтора падал AOS. У клиента была расширенная поддержка. Его инцидентом занимался какой-то аутстаффинговый индус (или пакестанец) из Sonata Software. Падение сервера, этот индус пытался лечить перебирая разные магические значения размера буфера в конфигураторе сервера, а также путем отсылки клиенту всяких архивных промежуточных билдов ядра (какие-то релизы между RU3-RU4-RU5). Когда я приехал, я просто тупо накатил RU7 и все прошло. Надо, правда, заметить, что если бы клиент не тупил, а сразу нажаловался на этого индуса своему менеджеру по расширенной поддержке, вполне возможно что его бы заменили на кого-то вменяемого. Правда чтобы у клиента появилось такое желание, надо чтобы он хотя бы раз столкнулся с кем-то вменяемым в поддержке MBS, правда ведь ?
3. Надо заметить, что у микрософта еще есть такая услуга как Microsoft Premium Support. Это совершенно отдельная услуга, которую предоставляет не MBS, а Microsoft Consulting Service. Стоит это порядка сотен тысяч долларов в год, и в принципе включает в себя прямую поддержку ВСЕГО продуктового стека. (Я даже знаю историю как клиент нашел баг в MS Flight Simulator и через Premium Support добился ее оперативного исправления) Правда тут надо заметить, что менеджеры по premium support обычно плохо понимают MBSовскую специфику и не очень-то хорошо умеют работать с поддержкой MBS

Выскажу свои соображения по поводу полезности эскалации багов в MBS в целом:
В случае обнаружения и идентификации бага в AX у меня есть, грубо говоря, два пути - исправить баг самому или ждать его исправления поддержкой.
Если я нашел баг и нашел пути его воспроизведения (а это всегда нужно чтобы зарегистрировать баг в поддержке), то с вероятностью 95%, я знаю как исправить этот баг. И скорее всего, исправление этого бага потребует от нескольких часов до нескольких дней работы.
Если же я попытаюсь зарегистрировать баг в MBS, то мне придется:
1. Подготовить тестовые данные для стандартного приложения.
2. Потратить время чтобы объяснить этот баг специалисту поддержки. (Возможно несколько конфколлов придется провести или кучу времени на переписку потратить или зааплодить нашу демо-базу в MBS)
3. Если этот баг признают, то никаких временных рамок по его исправлению мне не сообщат.Соответственно - я буду иметь кучу финансовых потерь от неработспособности функциональности.
4. Если этот баг будет исправлен в очередном rollup, то мне придется потратить очень немало времени и сил (и - возможно- времени и сил моих пользователей) на то чтобы на этот роллап заапгрейдиться.

Поэтому в 99% случаев, любой баг правится самостоятельно, а потом, возможно, регистрируется в MBS. Однако, регистрация уже исправленного тобой бага в MBS, это гарантированно работа с негативным экономическим эффектом, поскольку:
1. Ты тратишь свое время (гарантированные затраты), с очень негаратированным результатом (неизвестно признают ли твой инцидент ошибкой; если признают, то неизвестно будут ли исправлять; если будут исправлять - то неизвестно в каком rollup).
2. В случае если ошибка будет таки исправлена, то с большой вероятностью, это приведет к дополнительным затратам. Скажем, если ты незарепортил баг, то скорее всего твое исправление будет поднято на новый rollup (если ты на него будешь апргрейдиться) полуавтоматически, Если же ты его зарепортил, то тебе придется заниматься исследованием того как микрософтовский подход к исправлению бага отличается от твоего собственного, курочить и свой и микрософтовской код, писать конвертеры данных для апгрейда.

Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле. Только в этом случае, есть слабые шансы что затраты на регистрацию ошибки, когда-то отобьются. (И то не факт).

Так что, мы все конечно должны поблагодарить gl00mie за регистрацию багов, но вот его работодатель должен был бы выписать ему штраф за бессмысленные потери рабочего времени.

Вообще, очень хотелось бы чтобы MBS что-то сделал бы с работой своей поддержки. С одной стороны - понятно что нужно держать фронтлайн саппорт для того чтобы не допустить к квалифицировваным спецам безграмотных юзеров с безграмотными вопросами. С другой стороны - как-то это ненормально, когда после 10 лет работы с аксаптой, любой мой запрос требует длительного подтверждения что я не верблюд и чтения мною лекции по аксапте какому-то чуваку, который аксапту увидел год назад и не знаком с 90% ее функциональности. Еще более ненормальным кажется тот факт, что баг, признанный автором бага в группе российской локализации, не может быть исправлен без прохождения всей цепочки фронт-лайн саппортеров.

[mazzy]

Цитата:

Сообщение от fed

Поскольку тема окончательно ушла в оффтоп

разделил ветки. теперь это онтоп.

да, полностью согласен с fed.

Цитата:

Сообщение от fed

Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле.

для партнеров тоже невыгодна.
партнеры все равно делают некую базу собственных наработок.
лечение багов относится туда же.

регистрация в МС будет нормально происходить только если регистрация багов будет выполняться очень легко.

примерно как в службах поддержки у провайдеров.
еще никто не отклонял мои заявки в службах поддержки провадеров только потому что вопрос плохо составлен. Если вопрос действительно дурацкий, то мне дают отписку. Но на большинство вопросов отвечают по делу в какой бы форме я ни сформулировал вопрос. При общении с провайдреами я сам заинтересован составить вопрос наиболее полно и достоверно - ведь я же хочу получить ответ.

примерно так работают все ИТ-службы, которые я видел у клиентов и которые работают с системой заявок от пользователей.

примерно так и мы стараемся работать с вопросами пользователей - принимаем любые вопросы. И уже сами сортируем, объединяем дубли, группируем. если нужно, то переспрашиваем.

на моей памяти только две службы поддержки, с которыми общаться не хотелось -поддержка делового софта у 1Са и поддержка в МБС.
Добавил: не, вру. вспомнил и третью. служба поддержки клиент-банка в Сбербанке - это запредельный пипец.

Добавил: хочу сказать большое спасибо МБСу, что разрешили задавать вопросы на русском. Раньше было только на английском. Уже хорошо.

[EVGL]

Цитата:

Сообщение от fed

Поэтому в 99% случаев, любой баг правится самостоятельно, а потом, возможно, регистрируется в MBS.

Есть один класс багов, где поправить самому невозможно: крэш в ядре. Microsoft на удивление неплохо может справляться с такими. Присылаешь им дамп, а они говорят, в чем дело.

В плане потери времени я бы не был так пессимистичен. Я обычно тестовые данные не готовлю, а вкратце описываю сюжет и оптправляю. У специалиста могут появиться вопросы, но я рекомендую ему попробовать воспроизвести все самому и в 90% случаев он превосходно справляется. Потом на протяжении примерно полугода специалист создает видимость работы, то бишь держит меня в курсе: "мы работаем... запрос уже ушел в ХХХ, работаем... ХХХ анализирует..." Ничего особенного в этом нет. Наша поддержка для клиентов работает точно так же за исключением в разы большей скорости и эффективности.

[fed]

Цитата:

Сообщение от EVGL

Есть один класс багов, где поправить самому невозможно: крэш в ядре. Microsoft на удивление неплохо может справляться с такими. Присылаешь им дамп, а они говорят, в чем дело.

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Цитата:

В плане потери времени я бы не был так пессимистичен. Я обычно тестовые данные не готовлю, а вкратце описываю сюжет и оптправляю. У специалиста могут появиться вопросы, но я рекомендую ему попробовать воспроизвести все самому и в 90% случаев он превосходно справляется.

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

[EVGL]

Цитата:

Сообщение от fed

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

Да нет, я просто им пишу: "Извини, Наталия Фернандес / Золтан / Амитабха, но у меня нет времени на разжевывание. Обрати внимание на это и это." И ничего, справляются.

[Logger]

Цитата:

Сообщение от fed

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash
Finding the X++ call stack that caused a crash
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

Эти ссылки надо в рамочку и на видное место. В какой нить раздел на форуме. Как минимум тэг "полезное" обеспечен.
Я когда их увидел в блоге - еще удивился - не ожидал такого. А оказывается это опять fed постарался.
Большое спасибо.

По сути, несколько людей в России на голом энтузазизме делают большую работу заменяя по отдаче целые отделы по документированию и пиару.

С одной стороны грустно что все так. А с другой стороны хорошо что они у нас есть

[gl00mie]

Цитата:

Сообщение от fed

с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

В статьях в свое время обнаружилась небольшая неточность, я вот сейчас сравнительно долго искал упоминание о ней, так что продублирую соотв. уточнения здесь:

Цитата:

Сообщение от gl00mie

Надо только учесть, что у Tariq'а в статье есть пара опечаток, которые становятся очевидны при просмотре приведенного им выхлопа отладчика:

1. Цитата:

   Look for the Ax32Serv!interpret::evalFunc frames take the location from the line below and then run in AX2009 64 bit: dw 000000002311b150+30
   на самом деле +20
2. Цитата:

   Next you can run in AX2009 64 bit: db 000000002311b150+38
   на самом деле +28

Для аналогичного анализа дампа памяти или "живого" клиента AX 2009 подходят приведенные им рецепты для AX4 32-bit (ну и плюс в этом случае надо использовать WinDBG x86 - даже на винде x64). Да, и лучше это все делать на ядре RU7, потому что для него отладочные символы в открытом доступе есть, а для RU6, насколько я могу судить, - нет.
Также хочу напомнить, что с ключом ком. строки /console AOS можно запустить не как сервис, а как обычное консольное приложение - в т.ч. прямо из-под отладчика.

[Logger]

Цитата:

Сообщение от fed

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

Пишут что автомат отключили
https://blogs.msdn.microsoft.com/axs...-discontinued/
и вместо него есть еще одна инструкция
https://blogs.msdn.microsoft.com/cob..._dmp_analysis/