Журавлев Денис
в общем отключайте md5 и shadow. Слишком древний информикс и новый линукс.
спасибо, коннект прошел локально после отключени мд5, шадоу остался включен

но коннект сути сабжа не изменил.....
есть 2 новых вопроса:
1й - может ли являться ошибка по креат роле следствием прописанной ДБ_Локали?:
http://www.sql.ru/faq/faq_topic.aspx?fid=541Примечание:
Не рекомендуется устанавливать свои локали перед первичной инициализацией дискового пространства сервера (oninit -i), во время которого создаются системные БД sysmaster и sysutils. Эти системные базы должны быть с локалями по умолчанию
DB_LOCALE=EN_US.8859-1 или DB_LOCALE=EN_US.819
2-й мне был предложен вариант по искуственной замене креат роле на такой финт ушами:
авторзамiсть CREATE ROLE 'dov_v'; пишеш
insert into sysusers (username, usertype,
priority) values ('dov_v','G',5);
це одне й те ж
вопрос: кошерна ли такая замена?

спасибо, я это читал.... вопрос не в том как трактует это IBM, а в применении к моей ситуации...
Тан
Я бы на вашем месте все перепроверила раза 3-4, а потом попросила бы кого-нибудь еще проверить все снова

если Вы по поводу проверки имён - еще раз повторяю НЕТ В СИСТЕМЕ И В БД ДАЖЕ НАМЕКА НА ТАКИЕ ИМЕНА .
сорри.... я ж не малый ребёнок.....проверили не смотря на то, что система только поднята.

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

Танспасибо, что крикнул, теперь я поняла
прошу прощения, я просто акцентировал Ваше внимание что в 10й раз напоминать про имена не стоит :)
еще раз прошу прощения.

как пример - есть 3 разные организации которые наступили на эти грабли, решения , кроме как описано выше, - не нашли.

Журавлев Денисшадоу отключить не?
на Юваре проверили - работает с шадоу
на СЛ4.4 с шадоу - коннектится
или есть предположение что из-за шадоу некорректно обрабатывает файл passwd?
и встречный вопрос: на старой системе клиент одновременно создает 3 коннекта(так надо по ПО).
онстат -у выглядит так:
8c5b9a5c Y--P--- 74 Ludmila LUDMILA 8c824744 0 1 11 0
8c5b9f10 Y--P--- 78 Ludmila LUDMILA 8c8fc1f8 0 1 51 33
8c5ba3c4 Y--P--- 76 Ludmila LUDMILA 8c83c658 0 1 43552 44039

нашел интерестную строку в файле sqlhosts
obloks onipcshm obloks abc
onobloks ontlitcp obloks sqlexec
не понятно назначение abc , к чему оно?

поставили систему по новой.
не прописывали ДБ_локаль и др. локали
отключили мд5 и шадоу
происталили ИДС
на креат роле таже грабля.......

zefsзаменяем строку
scsi_bes
...
create role "dov_v" ;
.....


на
grant connect to "dov_v" ;
update sysusers set usertype='G' where username="dov_v" ;

далее всё работает нормально во всяком случае у нас не было проблем с ролями, которые были созданы таким способом!

спасибо, сделали по своему через инсерт
учтем и этот вариант.

на РедХате с тем же пакетом ИДС в другой организации - те же проблемы с ролями
мне не понятна ситуация когда на юваре запускаю
select grantor, grantee, tabid, tabauth,
dic_tabid,dic_tabname,dic_ownername,dic_dbname
from systabauth,sysdic
where tabid=dic_tabid and dic_tabname='sysusers'
результат такой:
informix|public|7|s-------|7|sysusers|informix|oks|
informix|public|7|s-------|7|sysusers|informix|spov_x|
informix|public|7|s-------|7|sysusers|informix|sysmaster|
informix|public|7|s-------|7|sysusers|informix|sysutils|
=====
тотже запрос на СЛ44 и РХ даёт такой рез-т:
informix|public|7|s-------|7|sysusers|informix|oks|
informix|public|7|s-------|7|sysusers|informix|spov_x|
не отображает что такие таблицы в сисмастере и сисутилс есть, а они таки там есть....

мы пришли к выводу что 19800 ошибка - баг для 7.30 под ОС Линукс(описанный в пофиксенных для версии 9.30)
или укажите в каком месте мы что-то делаем не так.....
спасибо ВСЕМ!