Isso é parte da tarefa maior de personalizar o ambiente z/OS.
O WebSphere Event Broker para z/OS acessa tabelas do DB2 utilizando o ODBC. Para conectar-se ao DB2 utilizando o
ODBC, é utilizado o nome do local do subsistema DB2. Consulte o manual DB2 UDB
para
OS/390
e z/OS V7 Data Sharing: Planning and Administration para
obter detalhes adicionais.
Quando o sistema DB2 for inicializado, deverá haver
uma mensagem DSNL004I DDF START COMPLETE.O nome do local é exibido logo após
esta mensagem. Quando customizar um componente do intermediário
no z/OS, você criará um arquivo dsnaoini
chamado BIPDSNAO no PDSE do intermediário. Ele contém as informações necessárias para estabelecer a conexão ODBC.
Consulte o manual DB2 UDB para OS/390 e
z/OS V7 ODBC Guide and Reference para obter detalhes adicionais.
Evite utilizar um nome de origem de dados que seja igual ao ID do
subsistema ou ao ID de compartilhamento de dados. Se for utilizado o
mesmo nome, isso poderá afetar a granularidade de diretrizes na
conexão com o banco de dados.
Se você optar por utilizar o mesmo valor para o nome da
origem de dados e ID do subsistema, deverá editar BIPDSNAO
no PDSE do intermediário para que as palavras-chave Datasource e Subsystem estejam em uma seção.
Consulte o manual DB2 UDB for OS/390
and z/OS V7 ODBC Guide and Reference para obter informações adicionais sobre como personalizar este arquivo.
Durante a personalização, você pode especificar qual nome de plano utilizar ou
utilize o padrão
DSNACLI. Se desejar que o intermediário acesse grupos de compartilhamento de dados do
DB2
diferentes do seu, o plano
DSNACLI deverá estar ligado
de uma forma especial.Verifique se o local curinga foi
especificado utilizando SPUFI e emitindo o seguinte comando:
select * from SYSIBM.SYSPACKLIST where planname ='DSNACLI';
Será necessário
refazer bind se a coluna de local estiver em branco e não
'*'.
Também é necessário verificar se DSNACLI está na tabela SYSIBM.SYSPLAN.
Você obterá importantes benefícios de desempenho ao utilizar o recurso CACHE
DYNAMIC SQL do DB2, porque ele elimina a necessidade de reprocessar instruções do DB2.
Consulte CACHEDYN=YES no DB2 UDB for OS/390 and z/OS
V7 Installation Guide.
Se o banco de dados do usuário estiver configurado para utilizar uma vírgula como separador decimal utilizando o módulo
DSNHDECP,
você perceberá que existe uma restrição. Se houver uma
incompatibilidade entre o
DB2 e as definições de código do idioma do ID do usuário com o qual o servidor intermediário é executado (especificamente
LC_NUMERIC), as atualizações do banco de dados do usuário
poderão ser imprevisíveis.
LC_NUMERIC é configurado através da configuração
LC_ALL no membro
BIPBPROF e, portanto, no arquivo de ambiente. A lista a seguir detalha as quatro possibilidades:
- Se o DB2 estiver configurado para utilizar um ponto como um ponto decimal e LC_NUMERIC
estiver definido como um valor que indica um ponto decimal de um ponto; as atualizações do
banco de dados do usuário deverão funcionar corretamente.
- Se o DB2 estiver configurado para utilizar uma vírgula como um ponto decimal e LC_NUMERIC
estiver definido como um valor que indica um ponto decimal de uma vírgula; as atualizações do
banco de dados do usuário deverão funcionar corretamente.
- Se o DB2 estiver configurado para utilizar um ponto como um ponto decimal e LC_NUMERIC
estiver definido como um valor que indica um ponto decimal de uma vírgula; as atualizações do
banco de dados do usuário poderão gerar um comportamento imprevisível.
- Se o DB2 estiver configurado para utilizar uma vírgula como um ponto decimal e LC_NUMERIC
estiver definido como um valor que indica um ponto decimal de um ponto; as atualizações do
banco de dados do usuário poderão gerar um comportamento imprevisível.
O intermediário utiliza as tabelas do
DB2 de um banco de dados para armazenar informações. A configuração dos mesmos requer alguém com as seguintes autoridades:
- CREATESG para criar um grupo de armazenamento
- CREATEDB para criar o banco de dados
- Conceder utilização de conjuntos de buffer