Автор |
Тема: Нестандартное использование Сервера ФБП (Прочитано 46848 раз) |
|
MELVIS
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 7
|
 |
Нестандартное использование Сервера ФБП
« В: 16.11.12 в 14:46:40 » |
Цитировать | Править
|
Сразу прошу Автора Сервера ФБП и Сообщество ФБП простить меня за не совсем стандартный подход к использованию Сервера ФБП.
Основные задачи:
1. Расширение возможностей работы с журналом операций (паралельная работа с БД с разными форматами, содание (интегрирование) обьединённых БД в реальном времени).
2. Оптимизация, логики перерасчёта Сервера при внесении изменений в прошлом (перерасчёт не прерывается при cоздании новой операции в прошлом, а проводится до полного завершения, новые и изменённые операции за время перерасчёта накапливаются в буферном журнале операций и «подкладываются» Серверу в виде готового *.f3p, а уже потом производится новый перерасчёт с учётом этих операций).
3. Использование многоядерности процессора, повышение быстродействия Сервера за счёт сосредотачивания работы Сервера только на вычислительных функциях - работу с файлами операций выполняет «буферное» приложение.
4. Возможность расширенного администрирования прав ползователей.
5. Обход ограничения для длинны строки запроса к Серверу в 255 символов (редко, но иногда бывает).
6. Создание системы автоматического востановления БД при аварийном завершении работы Сервера.
7. и многое другое ....
Способ решения:
1. Создание «буферного» приложения, которое выполняет роль «администратора-синхронизатора-интегратора». «Буферное» приложение полностью берёт на себя работу с файлами *.f3p, и готовые файлы *.f3p подкладывает Серверу после завершения перерасчёта. После «подкладки» нового (изменённого) *.f3p Сервер делает перерасчёт по команде P mc=*.
Проблема:
При такой «подкладке» *.f3p Сервер всё делает отлично, за исключением одного – не работает директива jf по операциях созданных не Сервером.
Учитывая то, что мы полностью ушли от TXA, это для нас очень большая проблема.
Опробовать «подкладку» можно на любой базе по такой методике:
1. запускаем два Сервера на двух поностью одинаковых базах 1 и 2 (копии одной базы);
2. создаём новую операцию в базе 2;
3. при работающих Серверах 1 и 2 копируем *.f3p с новой операцией из базы 2 в базу 1
4. даём команду на перерасчёт в базе 1;
5. смотрим результат в базе 1 (Сервер даёт проводки по новой «чужой» операции, но jf по новой операции которая создана без участия Сервера 1 не работает– нет операции)
!!! Эта методика только для выявления "нерабочей" jf при подкладывании чужих операций.
!!! «Буферное» приложение – это не Сервер ФБП
Ми поняли, что Сервер не обновляет индексы штампов операций при пререрасчёте.
Это так?
Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?
|
| « Изменён в : 19.11.12 в 19:44:41 пользователем: MELVIS » |
 Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
 |
Re: Нестандартное использование Сервера ФБП
« Ответить #1 В: 16.11.12 в 19:40:17 » |
Цитировать | Править
|
on 16.11.12 в 14:46:40, MELVIS wrote:Сразу прошу Автора Сервера ФБП и Сообщество ФБП простить меня за не совсем стандартный подход к использованию Сервера ФБП.
Основные задачи:
1. Расширение возможностей работы с журналом операций (паралельная работа с БД с разными форматами, содание (интегрирование) обьединённых БД в реальном времени).
|
|
Интегрирование уже не может быть в реальном времени, т.к. реально дельту времени к 0 в числовых методах не привести.
Quote:
2. Оптимизация, логики перерасчёта Сервера при внесении изменений в прошлом (перерасчёт не прерывается при зоздании новой операции в прошлом, а проводится до полного завершения, новые и изменённые операции за время перерасчёта накапливаются в буферном журнале операций и «подкладываются» Серверу в виде готового *.f3p, а уже потом производится новый перерасчёт).
|
|
Исключите возможность работы с ЖО для клиентов базового сервера и эта проблема станет не актуальной.
Quote:
3. Использование многоядерности процессора, повышение быстродействия Сервера за счёт сосредотачивания работы Сервера только на вычислительных функциях - работу с файлами операций выполняет «буферное» приложение.
|
|
По всей видимости, «буферное» приложение уже реализовано Вами. А в самом пересчете распараллелить что-либо в учете в наших регистрах– проблематично, т.к. они, как правило переплетаются.
Quote:
4. Возможность расширенного администрирования прав ползователей.
|
|
Чего именно, Вам не хватает сегодня.
Quote:
5. Обход ограничения для длинны строки запроса к Серверу в 255 символов (редко, но иногда бывает).
|
|
«Краткость – сестра …»
Ради чего и до какого объема, на эту тему были обсуждения, пока не видно большого смысла.
Quote:
6. Создание системы автоматического востановления БД при аварийном завершении работы Сервера.
|
|
Эти проблемы чаще на администраторах всегда и везде.
Quote:
Вот так всегда….
Quote:
Способ решения:
1. Создание «буферного» приложения, которое выполняет роль «администратора-синхронизатора-интегратора». «Буферное» приложение полностью берёт на себя работу с файлами *.f3p, и готовые файлы *.f3p подкладывает Серверу после завершения перерасчёта. После «подкладки» нового (изменённого) *.f3p Сервер делает перерасчёт по команде P mc=*.
Проблема:
При такой «подкладке» *.f3p Сервер всё делает отлично, за исключением одного – не работает директива jf по операциях созданных не Сервером.
Учитывая то, что мы полностью ушли от TXA, это для нас очень большая проблема.
|
|
Не очень понятна связь. Вы в TXA выводили фразу операции?
Для чего Вам [jf  , ведь Вы уже операции сформировали, а потом хотите получить от сервера подтверждение, что они такие же, как Вы ему «подложили»? Если Вы хотите редактировать на базовом, то см.совет в п.2.
Редакция – это реальная проблема в предложенной технологии, а [jf – нет. Quote:
Опробовать «подкладку» можно на любой базе по такой методике:
1. запускаем два Сервера на двух поностью одинаковых базах 1 и 2 (копии одной базы);
2. создаём новую операцию в базе 2;
3. при работающих Серверах 1 и 2 копируем *.f3p с новой операцией из базы 2 в базу 1
4. даём команду на перерасчёт в базе 1;
5. смотрим результат в базе 1 (Сервер даёт проводки по новой «чужой» операции, но jf по новой операции которая создана без участия Сервера 1 не работает– нет операции)
Ми поняли, что Сервер не обновляет индексы штампов операций при пререрасчёте.
Это так?
Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?
|
|
Можно, при том, не меняя ничего на сегодня в сервере. Просто могу обновить свой bk.lib для Вас и будет Вам счастье.
P.S. В качестве буферных серверов никто не мешает пользовать стандартные, интегрируйте их как Вам угодно и сколько угодно и «подкладывайте» отчетному серверу любыми доступными средствами. После выполнения совета по п.2. можно особо не думать о конфликтах и потерях.
|
|
Зарегистрирован |
|
|
|
MELVIS
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #2 В: 16.11.12 в 21:32:33 » |
Цитировать | Править
|
Спасибо за детальный анализ нашего сообщения и критику, но ответа на поставленный вопрос мы не получили:
«Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?»
Всё остальное – это наши проблемы. После завершения работы над проектом, если у Вас будет желание, мы продемонстрируем его достоинства.
|
| « Изменён в : 17.11.12 в 10:45:07 пользователем: MELVIS » |
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #3 В: 17.11.12 в 04:07:06 » |
Цитировать | Править
|
on 16.11.12 в 21:32:33, MELVIS wrote:| ...Всё остальное – это наши проблемы... |
|
При подобных манипуляциях с *.f3p, имхо, кратно возрастает вероятность появления не уникальных ключей в штампах операций. А это уже серьезный фактор, дестабилизирующий систему.
По сути же вопроса - можно опробовать следующий вариант: В каждом месяце в начале дня иметь операцию, которая ничего не делает
¦¦ x x (0)
со штампом AAAA-001 для января, ВAAA-001 для февраля и.т.д..... и вместо запроса на пересчет, править операцию в нужном месяце, например
o KEY=AAAA-001... и.т.д....
|
| « Изменён в : 17.11.12 в 05:35:27 пользователем: mine-R » |
Зарегистрирован |
|
|
|
Iamik
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 6
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #4 В: 17.11.12 в 09:50:17 » |
Цитировать | Править
|
Quote:| со штампом AAAA-001 для января, ВAAA-001 для февраля |
|
мда, в вашей логике эта дестабилизирующая ситуация как раз и проявилась .... Не может существовать два штампа AAAA-001 и BAAA-001 потому что уникальность определяется без учёта первого символа. В правильных руках всё будет работать нормально 
|
|
Зарегистрирован |
|
|
|
MELVIS
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #5 В: 17.11.12 в 10:57:39 » |
Цитировать | Править
|
Для mine-R "При подобных манипуляциях с *.f3p, имхо, кратно возрастает вероятность появления не уникальных ключей в штампах операций."
В нашем варианте присваивание и контроль за уникальностью штампов операций - это работа «буферного» приложения. Проблем нет - опробовано на практике.
|
| « Изменён в : 17.11.12 в 11:23:56 пользователем: MELVIS » |
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #6 В: 17.11.12 в 13:44:40 » |
Цитировать | Править
|
on 17.11.12 в 09:50:17, Iamik wrote:В чем противоречие? Было указано возможное направление и наглядно показаны острые углы, которые необходимо обойти. Так что, штампы сосуществовать вполне себе могут, но до первой перезагрузки сервера.
on 17.11.12 в 10:57:39, MELVIS wrote:В нашем варианте присваивание и контроль за уникальностью штампов операций - это работа «буферного» приложения. Проблем нет - опробовано на практике.
|
|
Заинтриговали Возможно, я не совсем корректно представил себе технологию работы из Вашего перврго поста. N-ное количество серверов выводят в файлы *.in запросы напрямую в box "результирующего" сервера?
|
| « Изменён в : 17.11.12 в 14:05:28 пользователем: mine-R » |
Зарегистрирован |
|
|
|
MELVIS
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #7 В: 17.11.12 в 15:58:11 » |
Цитировать | Править
|
Re mine-R
"Заинтриговали Возможно, я не совсем корректно представил себе технологию работы ..."
Да, Вы совсем не поняли нашего подхода. Сервер читает готовые файли *.f3p.
«Буферное» приложение управляет запросами к Серверу и, как администратор запросов, не пропускает Серверу директив по работе с журналом операций, а полностью берёт на себя эту работу. Берёт на себя и «многое другое...». Прошу воспринять эту фразу не из-за того, что нечего сказать, а потому что «многое другое...» не есть предметом обсуждения в данном случае. По завершении проекта, если у Сообщества будет интерес, мы обнародуем его для критики.
Нам нужно только чтобы заработала jf при «подкладывании» Серверу файла *.f3p.
Надеюсь Автор услышит нашу просьбу и выскажет своё мнение по этому вопросу.
Автор – всегда прав, на то он и Автор.
Очень бы хотелось получить его понимание.
|
| « Изменён в : 19.11.12 в 19:47:26 пользователем: MELVIS » |
Зарегистрирован |
|
|
|
BBBB
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 89
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #8 В: 17.11.12 в 16:55:30 » |
Цитировать | Править
|
А почему вам не нравится предложение Бориса о решении вопроса с jf? Если он уже увидел как это сделать - почему нет?
И все равно не понятно - почему результирующему серверу ставятся такие жесткие условия - и не перестартовывать, и не пересчитывать, и не принимать *.in из _box_ - но выдать все по jf. Может вам тогда и не ФБП:сервер нужен?
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #9 В: 17.11.12 в 17:28:55 » |
Цитировать | Править
|
on 16.11.12 в 21:32:33, MELVIS wrote:Спасибо за детальный анализ нашего сообщения и критику, но ответа на поставленный вопрос мы не получили:
«Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?»
|
|
Странно, вообщем-то ничего странного, наверное ваш гениальный буфер Вас сильно вдохновляет, что Вы не видите ни вопросов по ходу, ни прямого ответа на свой вопрос(наверное нужно было с Вас пример брать и писать жирным) . Плз. прочтите еще раз и вслух предпоследний абзац моего предыдущего поста, а лучше ещё раз от начала до конца.
Также вношу коррективы к своему первому посту, что и с редакцией(это второй момент, на котором Вы пока не акцентировали внимания) подложенных операций, как и с обходом [jf( это первый ваш вопрос) реализуемы без внесения изменений в текущую версию сервера. Решение второго вопроса конечно накрывает и первый, как бы уже и заодно. Решение простое, но специфичное в тонкостях реализации и потребует условий для ваших «буферов» или «буферных приложений» и конечно элементов взаимодействия.
Quote:
Всё остальное – это наши проблемы. После завершения работы над проектом, если у Вас будет желание, мы продемонстрируем его достоинства. |
|
Вижу без демонстрации достоинство Вашей системы в актуальности для учета, не требующего перманентной актуализации отчетных и вспомогательных форм для ввода, ред. или удаления операций. Актуальность вашей системы в гораздо большей реактивности промежуточных серверов(кот. Вы назвали буферными приложения) на действия оператора, т.к. Вы организационно развели по веткам учет на своем предприятии и вероятно правильно сделали. Тем самым специализировав комплекс программ для решения поставленных перед Вами задач. Ура, что есть у нас такие. С другой стороны Ваш комплекс, вероятно, далек от универсальности нашего уважаемого ФБП-сервера. Вносить изменения в сервер, которые посвящены согласованию с нештатным его использованием, согласитесь, что этому нет ни конца ни краю, при чем в Ваших силах самим додуматься до решения, которое уже существует, ведь это уже 99% решения, т.к. уверенно знаешь, что есть решение, только, оно не записано на последней странице учебника). Думаю, что так веселее.
Интерес к Вашей системе резко появится, как только опубликуете пул своих предприятий и их лестные отзывы о сотрудничестве с Вами, успехов Вам.
Ударим рифмой прозу дня
Чтоб веселее жить друзья
Финансы революшн на пороге
Кланяемся новой проге
Буфера Виталия сервер вознесут
Сервера в охотку лихо разметут.
P.S. Делаю ставки на BBBB и Mine-R, эти ребята скоро дадут Вам решение.
|
|
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #10 В: 17.11.12 в 20:23:50 » |
Цитировать | Править
|
on 17.11.12 в 17:28:55, Boris, Kiev. wrote:| ...P.S. Делаю ставки на BBBB и Mine-R, эти ребята скоро дадут Вам решение. |
|
Я "свой" вариант решения выше обозначил. Если добавление новых операций в результирующем сервере запрещено, то проблемы уникальности штампов возникнуть не должно. Но синхронизировать то, что уже в озу с тем, что подложили как-то нужно, потому и предложил, чтобы результирующий сервер перед пересчетом, редактировал заготовленную операцию-пустышку.
Мне любопытен также средний объем в Mb подкладываемых f3p. И использование/неиспользование прочих авантюрных схем (напр. загон одной из баз или даже обеих вместе с каталогами обмена в ram-диски и.т.п. )
P.S. Наверняка есть и элегантные решения на основе loaddir (к примеру, чтобы не включать пересчет, если вдруг подложили неизменившийся f3p), но готовых наработок у меня нету
|
|
Зарегистрирован |
|
|
|
chipic128
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 19
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #11 В: 18.11.12 в 23:40:56 » |
Цитировать | Править
|
Вопрос к создателю сервера!
У Вас в компютере сегодня сколько ядер?
Думаю больше чем 1, а сервер ФБП на скольких работает - на 1., почему ми не продвинулись в сторону развития а зависли на стадии 90-х годов. Ми работаем на ФБП уже продолжытельное врема, у нас работает много подразделений на которых тоже ФБП, НО - страшные тормоза при работе например с параметрами 3-и или более месяца назад, и сервер страшно ТУПИТ, когда изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают - "Почему мои дание не актуальны", тогда я в ручном режыме отключаю прием *.in, дожидаюсь конча перерасчета и тогда восстановляю работу. Неправильно все это. Эту проблему можна решить очень просто, и + к всему использовать многопоточность на разных ядрах и разних процесорах. Понимаю что перерасчет по разных ядрах не раскинуть, поскольку нужно соблюсти последовательность, но обработку форм спокойно можно разнести по ядрах. И кстати после долгого диалога со Светланой насчет команды Р - и P + так результата и не вышло - даная комманда не работает на сервере х64, мне сообщили что после выпуска новой версии учтем, версия вышла, команда не работает и из мануала тупо убрали.... это проще всего.
Да Технология сервера СУПЕР но почему так сложно дошлифовать его до совершенства
|
| « Изменён в : 19.11.12 в 10:06:45 пользователем: chipic128 » |
Зарегистрирован |
|
|
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 264
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #12 В: 19.11.12 в 06:07:50 » |
Цитировать | Править
|
Вопрос задан разработчикам, я не разработчик, но позволю себе прокомментировать некоторые соображения т.к. поднятые вопросы уже не раз обсуждались.
on 18.11.12 в 23:40:56, chipic128 wrote:
изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают.... |
|
Полностью согласен с chipic128. Правильно было бы изменить логику работы сервера. Не сбрасывать расчеты на начало сентября (для данного примера) а "добивать" до конца подбирая по пути измененные файлы октября, ноября, тем более, что, как я понял, пользователи "наяривают" в ноябре.
Quote:| обработку форм спокойно можно разнести по ядрах. |
|
Наверное можно, и, даже, нужно. Однако, это не даст ускорения в получении актуального результата работы формы т. к. все авно надо дождаться завершения пересчета выч. состояния. Кроме того, грамотно написанная форма вообще-то работает очень быстро и так.
Переделка сервера под многопоточность задача сложная, сопряжена с переделкой кода и, по сему, чревата непредсказуемыми последствиями в смысле возникновения ошибок. Результат же усилий может оказаться не столь впечатляющим.
К стати, существенного ускорения работы, кажется, можно добиться и "малой кровью" - без существеннй переделки кода. Надо просто вежливо попросить операционную систему напрячь процессор по-полной. Это называется Intel Turbo Boost Technology.
http://www.intel.com/content/www/us/en/architecture-and-technology/turbo -boost/turbo-boost-technology.html
Quote:| но почему так сложно дошлифовать его до совергенства |
|
Ответ очевиден. Совершенство не достижимо!
|
| « Изменён в : 19.11.12 в 06:24:04 пользователем: Vladimir » |
Зарегистрирован |
С уважением,
Владимир
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #13 В: 19.11.12 в 11:55:17 » |
Цитировать | Править
|
on 18.11.12 в 23:40:56, chipic128 wrote:
На эти вопросы, создатель не раз отвечал, почитайте архивы.
Почитайте руководство о режимах OLD DUAL
OLD__ DUAL__
Сегодня не нужно приобретать машину с многими ядрами, если планируете её выделить исключительно под ФБП-севрер.
Сравните работу одной и той же базы на разных машинах по ядрам.
Пользуете raid0 или нет?
Сделайте аудит настройкам. Найдите свои узкие места, ведь есть профиллер в отличие от других инструментов, может кто подскажет(просто для общего развития), какой сегодня ещё аналогичный инструмент может предложить такую возможность.
Шлифуйте настройки.
P.S. И конечно, если удастся воспользоваться советами и продвинуться, не сочтите за труд клипнуть сюда, а то обидно - "ТУПИТ" и всё.
P.S.2. И не очень понятно, чего отклонились от темы буферных приложений. Про "ТУПИТ" лучше писать в отдельную ветку, а лучше поискать эту тему в архивах и продолжить там, конечно если останутся вопросы и предложения.
|
|
Зарегистрирован |
|
|
|
Denis, Dnepropetrovsk
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 129
|
|
Re: Нестандартное использование Сервера ФБП
« Ответить #14 В: 19.11.12 в 12:05:36 » |
Цитировать | Править
|
on 18.11.12 в 23:40:56, chipic128 wrote:| Ми работаем на ФБП уже продолжытельное врема, у нас работает много подразделений на которых тоже ФБП, НО - страшные тормоза при работе например с параметрами 3-и или более месяца назад, и сервер страшно ТУПИТ, когда изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают - "Почему мои дание не актуальны", тогда я в ручном режыме отключаю прием *.in, дожидаюсь конча перерасчета и тогда восстановляю работу. |
|
Не могу поверить, что для всех ваших пользователей всегда нужны актуальные данные для продолжения работы  . К тому же если Ваши пользователи успевают вводить операции раньше чем сервер выполняет перерасчет 2-х месяцев, то получается что у вас такое огромное количество операций что сервер долго выполняет пересчет (у меня например 15000-20000 операций в месяц пересчитывается за 2 сек.). Поэтому вам следует искать варианты для уменьшения этого количества (например упаковывать документ в 1 операцию. По собственному опыту скажу, что без упаковки мне например не хватило-бы штампов для ввода всех операций в режиме 1 операция=1 строка документа).
А по поводу актуальности данных считаю, что для 99% случаев актуальность данных не имеет никакого практического значения .
PS Попробуйте режим DUAL (в нем отчетные формы выполняются даже при идущем перерасчете). При активном использовании extrd.dat включайте fastged. И будет Вам счастье в плане скорости.
|
| « Изменён в : 19.11.12 в 12:17:48 пользователем: Denis, Dnepropetrovsk » |
Зарегистрирован |
|
|
|
|
|
