A versão Quick3270 Secure suporta os seguintes protocolos: SSL v3, TLS v1.1, TLS 1.2 e TLS 1.3.

O Quick3270 possui facilidades de migração, com capacidade de executar macros dos seguintes emuladores: IBM Personal Communications™ (PCOM) - Executa macros geradas pelo IBM Personal Communications - Importa arquivos de mapeamento de teclado do IBM Personal Communications (.kmp) - Importa arquivos de lista de envio/recebimento do IBM Personal Communications (.srl) - Lê as configurações de cores do IBM Personal Communications - Inclui modelos de arquivo de configuração para usar configurações padrão semelhantes às do IBM Personal Communications - Fornece um objeto compatível com autECLSession (Automação) Attachmate EXTRA!™ - Executa macros geradas pelo Attachmate EXTRA! - Utiliza arquivos de tabela de tradução personalizada (.ctt) - Inclui modelos de arquivo de configuração para usar configurações padrão semelhantes ao Attachmate EXTRA! - Fornece um objeto compatível com o sistema (automação) Micro Focus RUMBA™ - Executa macros geradas pelo RUMBA™ Micro Focus Reflection™ - Fornece um objeto compatível com RIBM (Automação) ​ Brandon Associates®/Joly Giant Software® QWS3270™ - Executa macros geradas pelo QWS3270. HOBLink™ - Executa macros geradas pelo HOBLink.

Baixe aqui o PDF com as informações solicitadas

Baixe aqui o documento que apresenta os tipos de eventos monitorados pelo VSA, além de exemplos enviados ao SIEM em formato SYSLOG

Baixe o manual de configuração, acessando aqui.

Baixe o guia para ter acesso às configurações do LEEF no VSA

O VSA enviará os eventos para a porta configurada no SIEM LogRythm. Uma vez que já esteja “ouvindo” a porta TCP 514, por padrão, a liberação do firewall será: Sentido Mainframe (cliente) -> SIEM (server) Protocolo => TCP IP / Porta Origem => IpMainframe / 1024 – 65535 IP / Porta Destino => IpSIEM / 514

Habilitar a monitoração das mensagens EZZ603*, ICH408* , IEF12*. Sobre essas mensagens: EZZ603* ==> Sempre que um usuário estabelecer uma conexão ao servidor TN3270 (emulador), essa mensagem será exibida indicando o IP do usuário e a LU (sessão) atribuída a ele. ICH408* ==> Mensagens de tentativa de logon sem sucesso IEF12* ==> Mensagens de LOGON e LOGOFF Para Verificar a conectividade com o SIEM, abaixo algumas dicas: a) Na log do VSA, a informação indicando que há conectividade é a abaixo: T80ITM0021: HOST-IP=xx.xx.xx.xx T80ITM0900: EISTMART SOCKET T80ITM0900: EISTMART CONNECT T80IDR9807: SSI is Connected T80IDR1000: <<== SMART OPEN FOR BUSINESS ==>> b) Além disso, através do comando do TCPIP, todas as conexões podem ser listadas. * /D TCPIP,NOME DA PILHA,NETSTAT,CONN VSA 00000036 IPMAINFRAME..PORTALOCAL IPSIEM..PORTASIEM ESTBLSH >> indica que o mainframe está conectado no SIEM c) É possível ainda registrar os eventos enviados ao SIEM na sysout do VSA. Alterar no arquivo de configuração o parâmetro WTOTOCON para YES e restartar o VSA WTOTOCON=Yes

Certamente! Tal orientação encontra-se no manual de Configuração do VSA. Se o parâmetro ALERTStoMVS estiver configurado como YES, então o evento será enviado, via rede, e também será gravado em arquivo. Alternate Destinations for Alerts CONFGIN File Parms UDPPORT2= (Deprecated; in ASCII) UDPADDR2= (Deprecated; in ASCII) SRV2ADDR= (in ASCII) SRV2PORT= (in ASCII) SRV2PROTO= (in ASCII) You may want to have a second device (desktop or server) capture VSA alerts as well as your primary. Refer to Using the Mainframe Agent for setting up a second device. ALERTStoMVS= Yes | No | Only (absent = No), where: (in EBCDIC) Yes Writes alerts to a physical sequential file on MVS No Does not write alerts to an MVS dataset Only Writes alerts to a physical sequential file on MVS (but prevents TCP or UDP SENDs) To define the AlertFile: you must tailor and submit job DEFALRT. ALERTStoMVShdr= SysLog | LEEF | CEF SYSLOG (default) and segments alerts into 1k records LEEF Log Event Extended Format (without segmentation) CEF Common Event Format (without segmentation) //ALRTMVS DD DSN=&HLQ..&PRODUCT..ALRTMVS,DISP=SHR,DCB=BUFNO=10 When used, requires flat file: BLKSIZE=32760, RECFM=VB. Not recommended for a high volume of alerts. It needs lots of storage, perhaps a GDG, and issues PUTs (QSAM). NOTA: O uso de arquivo para importação gera um delay na consolidação dos eventos no SIEM. O VSA pode enviar eventos nos formatos abaixo: SYSLOG = Standard Syslog header and format (the default) LEEF = Log Event Extended Format (LEEF) (IBM’s QRadar) CEF = Common Event Format (MicroFocus/HP/ArcSight) 1. A recomendação do fabricante é que para o LogRythm, por exemplo, a customização dos 'parses' é interpretar os eventos do VSA, considerando o formato LEEF. Em relação ao evento gerado pelo VSA ser idêntico para as saídas syslog ou arquivo, segue abaixo um trecho do evento registrado no arquivo: Menu Utilities Compilers Help BROWSE SDSQ.O31.VSA33008.ALRTMVS Line 0000000000 Col 001 080 Command ===> Scroll ===> CSR ********************************* Top of Data ********************************** <113>Jan 22 07:30:56 10.31.0.1 VNCDMAGTÝFF01FB9B1090|O31 |2020012207305369 <113>Jan 22 07:30:56 10.31.0.1 VNCDMAGTÝFF01FB9B1090|O31 |2020012207305376

Baixe aqui o PDF com as Novidades da versão 4.2 e anteriores

Baixe aqui o PDF do Guia de Instalação da versão 4.1

Baixe aqui o Guia da Pré-Instalação do VFTP

Baixe aqui o Guia de Instalação do VFTP.

Os passos básicos para a instalação do WQ no ambiente CICS é realizar o upload do xmit e executar alguns jobs para linkedição do WQ, de carga de transações, programas e arquivos no CICS. O Script de instalação é basicamente descompactar o WQ e executar o start do WQADMIN No caso do WQ no ambiente Linux é importante providenciar a instalação das dependências abaixo: Compilador GCC versão 4.4 ou superior, incluindo suas bibliotecas (para 64Bit); Bibliotecas do GTK2 atualizadas ( 2.18 ou superior, para 64Bits) Bibliotecas do OpenSSL atualizadas (1.0.0b ou superior)

Para a migração da instalação do WQCICS para o ambiente de Produção, o procedimento a ser executado pela equipe de suporte é: Copiar a loadlib SWD.WQ.V215.JOBLIB Copiar o arquivo VSAM de configuração XYZ.WQ.V215.CNFWQ XYZ.WQ.V215.CNFWQ.DATA XYZ.WQ.V215.CNFWQ.INDEX Extrair do CSD do Seratest do MVS3 os programas, transações e TDs do grupo WQCICS, ou executar novamente o JCL de carga dos programas e transações SWD.WQ.V215.JOBLIB(@6LODCSD) Se for refeita a carga do CSD, as TDs da instância WH deverão ser recriadas. Após o grupo WQCICS com o arquivo, programas, transações e TDs tiver sido instalado, executar a transação wqcf wh e alterar o endereço IP. Caso no ambiente Linux, o servidor seja mantido o mesmo, basta reconfigurar o endereço IP que aponta para o novo CICS. Entretando, caso o WQLinux seja migrado para outro servidor, será necessário ainda gerar uma nova licença. Nesse caso, basta copiar o diretório /opt/wq451 para o novo servidor e instalar o XVFB para start por console. Após o 1º start do WQLinux enviar a LOG para geração da chave de ativação da licença.

Requisitos do Equipamento (“Hardware”): • PENTIUM IV ou equivalente com Processador acima de 2.4GHz; • Memória de pelo menos 512MB; • Espaço livre em disco de 1GB para instalação do WQSNG e para gravação dos arquivos LOG e AUDIT, além do espaço livre necessário para o Sistema Operacional. Requisitos de Sistema Operacional (“Software”): • Windows 64 bits, nas versões: Vista, 7, 8 ou 10 para o WQSNG de 64Bits; • Linux (pelo menos Fedora 12 ou Ubuntu 12.04 para 64 Bits), instalado preferencialmente com desktop KDE; • Compilador GCC versão 4.4 ou superior, incluindo suas bibliotecas (para 64Bit); • Bibliotecas do GTK2 atualizadas (2.18 ou superior, para 64Bits) • Bibliotecas do OpenSSL atualizadas (1.0.0b ou superior) >> Após atender aos requisitos acima, devem ser executados os comandos abaixo para validação da instalação: Observação: Os comandos foram emitidos numa distribuição CentOS antiga. Logo, as versões mais atuais poderão ser diferentes. Entretanto, o objetivo é validar se o GCC, o GTK2 e o OPENSSL estão instalados [usuario@localhost WQ]$ gcc -v Using built-in specs.Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr -- mandir=/usr/share/man --infodir=/usr/share/info --withbugurl= http://bugzilla.redhat.com/bugzilla --enable-bootstrap ............................................................. --enable-java-maintainer-mode --with-ecjjar=/ usr/share/java/eclipse-ecj.jar --disable-libjava-multilib - -with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 - -build=x86_64-redhat-linux Thread model: posix gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) [usuario@localhost WQ]$ yum list gtk2 Loaded plugins: dellsysidplugin, dellsysidplugin2, fastestmirror, presto, refresh- : packagekit adobe-linux-i386 2/2 Installed Packages gtk2.x86_64 2.18.3-19.fc12 @anaconda-InstallationRepo-200911081904.x86_64 Available Packages gtk2.i686 2.18.9-3.fc12 updates gtk2.x86_64 2.18.9-3.fc12 updates [usuario@localhost WQ]$ openssl version OpenSSL 1.0.0b-fips 16 Nov 2010 [usuario@localhost WQ]$

Etapas: 1) O WQSNG pode ser usado para validar a comunicação com o Gravames, caso o link (ou VPN) já esteja operacional. Caso não esteja, é possível iniciar os testes da sua aplicação de negócios através de strings para o componente 'rebatedor' do próprio WQSNG. Note que esse 'rebatedor' não validará a aplicação (ex: transação 761); apenas validará o envio/recebimento de strings pelo WQSNG. Nesse caso, a configuração será feita para que o WQ conecte-se localmente e “ecoe” de volta, todas as strings que ele receber da sua aplicação de negócios. 2) Após descompactar o arquivo de instalação do WQSNG no raiz do disco C, execute o command prompt (modo administrador) e as BATs, na sequência: a. Start WQ.bat >>> Inicia o WQ em modo teste (limitado a 100 transações); b. Simulador.bat >>> Inicia o simulador que é um rebatedor; c. Monitor.bat >>> Inicia o monitor de instâncias. Obs: A BAT chamada TESTE_SNG.bat envia strings para o rebatedor. O objetivo desse teste é validar que o WQClient e Server estão funcionando. Após liberado o Link com o Gravames, será possível usá-la (com suas strings) para validar a comunicação em paralelo ao teste da aplicação de negócios de sua empresa. As LOGs estarão sendo gravadas em (por exemplo para a versão 4.41 do WQSNG): C:\WQ441\SNG\Logs O arquivo de configuração é: C:\WQ441\SNG\WQ.ini Após disponibilizado o Link de acesso ao Gravames, será necessário fazer os ajustes necessários para que seja apontado ao IP do SNG. 3) Uma vez que os testes locais (com 'rebatedor') estejam Ok e que já tenha sido estabelecido o link com o SNG, será necessário confirmar: * Conectividade com o sistema SNG * IP e porta do SNG para conexão com o CICS de homologação remoto * Teste de Telnet Do servidor (onde o WQSNG está instalado), comandar >> telnet IPCICS PORTACICS (ex: telnet 192.168.101.148 3501). Se o Telnet funcionar OK, significa que foi bem sucedida a conectividade com o CICS. Daí, basta configurar o WQSNG para a conexão ao ambiente de homologação do SNG, testando as transações de negócio (ex: inclusão, baixa, consulta etc...) Essas strings serão enviadas ao SNG para serem processadas e devolvidas à sua aplicação.

Certo! O WQSNG está disponível tanto para o sistema Windows quanto o sistema Linux! E sem problemas, quanto a instalação do WQSNG e do componente WQ Conector serem instalado em sistemas distintos, ou seja, o WQSNG pode ser instalado no Linux e o WQ Conector no Windows.

O modelo de licenciamento do WQSNG prevê as seguintes licenças: * Produção: 01 WQ e 01 WQ Conector, * Homologação: 01 WQ e 01 WQ Conector, * Disater Recovery (DR): 01 WQ e 01 WQ Conector, No ambiente DR as licenças ficam em 'Standby' e serão utilizadas, exclusivamente, em casos de emergência, substituindo as licenças que estavam ativas na produção. Caso a redundância seja no modo 'Ativo', ou seja, prevendo a alta disponibilidade (02 WQ Conectores enviando pedidos para 01 ou mais WQSNG) será necessário o contato comercial com a Workers Informática para ajuste financeiro do contrato de uso das licenças da solução

Os Return Codes (RCs) de processamento do SNG podem ocorrer por conta dos acessos que este sistema faz, remotamente, a um Detran para executar uma operação. Esse específico é um RC de aplicação. Já os RCs de infraestrutura, que são emitidos pelo WQSNG, são sempre 'negativos' e gerados pelas funções: StartConector, EndConector, SendRequestToSR, SendAsyncRequestToSR, ReceiveSRRequest e SendSRResponse. Os RCs do WQSNG estão descritos no Manual do Desenvolvedor É recomendável que pelo menos seja registrado na LOG o motivo do não processamento e, dependendo da situação, seja feita uma nova tentativa de acesso após algum tempo. Ainda sobre o erro mencionado (“025 – Sistema remoto sobrecarregado, não foi possível enviar dados para a aplicação remota devido à sobrecarga da ligação de destino.”), é possível que seja uma situação temporária, já que o SNG não consegue repassar a sua operação ao parceiro dela (ex: Serpro ou Detran) por um problema que pode ser de rede ou de carga no parceiro. Neste caso, se faz interssante que sua empresa realize um alinhamento sobre a tratativa de situações como essas, diretamente com o seu contato ao SNG.

A análise das Logs do WQSNG do dia do evento são fundamentais para a solução desse tipo de problema: * WQ_LOG e WQ_AUDIT (ambos do Servidor WQSNG) * WQ_CONECTOR (do Servidor de Aplicação) Pode ser interessante 'Restartar' todo o WQSNG, incluindo o aplicativo de testes TstSNG.exe. Verifique se o processo “TstSNG.exe”, iniciado pelo SIMULADOR.BAT, esteja executando. Teste o processo de consulta novamente! Certifique-se que o antivírus na máquina que executa o WQSNG não esteja impedindo a execução correta do TstSNG.exe. Caso não haja tráfego por mais de 5 minutos o 'rebatedor' desconecta o WQSNG. Outra situação possível é que a Aplicação tenha registrado um determinado tamanho do pedido (Parte Fixa do SNG), mas envia, de fato, um tamanho diferente. O TstSNG ficará esperando o restante do conteúdo até o Timeout.

A parte de baixo da tela (Comunicador Servidor) não ficou azul porque foi configurado apenas a conexão CLIENTE do WQSNG para a conexão ao servidor do CICS, sentido EMPRESA -> SNG. Caso seja necessário que o WQSNG seja Servidor, então será necessário também informar o seu endereço IP para a conexão no sentido EMPRESA -> SNG. Além disso, será necessário configurar a sessão CLSERVER no arquivo WQ.ini [CLSERVER] APPNAME=C:\WQ551\TstCLIENT >>> Indicar a aplicação que será inicializada quando uma string de dados for recebida do SNG IP=localhost >>> IP do Servidor (esse ip “nateado” será informado ao SNG) PORT=3502 >>> Porta do Servidor (essa porta será passada ao SNG) Contudo, geralmente as EMPRESAS atuam como CLIENTE, apenas enviando strings ao SNG.

Não há essa necessidade. O Servidor é necessário quando o SNG envia ao oarceiro uma string para processamento. Daí, sua Aplicação encaminha uma string ao SNG, que processa o pedido e retorna com a resposta na mesma conexão CLIENTE. Geralmente, quem implementa a função Servidor são os Detrans, por conta do SNG acessar suas bases de dados.

Os Return Codes (RCs) disposníveis no WQSNG, como o -4nn, estão disponíveis para eventuais consultas, incluindo suas possíveis combinações, no manual “Interface WQ - Guia de Referência Rápida - Desenvolvedor.pdf” Abaixo, a descrição de como interpretar o RC -4nn: A tentativa de conexão com o Gerenciador de Filas foi realizada com sucesso, porém falhou no processo de envio de autenticação ou no recebimento da resposta enviada. O código “nn” corresponde a um dos valores negativos abaixo que indicará a causa da falha. Ex.: Para -414 ver erro –14. -4 >> indica que houve um erro na escrita ou leitura do pedido no gerenciador de filas. nn >> O código “nn” corresponde a um dos valores negativos abaixo que indicará a causa da falha. 1) Para -414 ver erro –14.... Erro -14 : O tempo máximo para leitura dos dados ou o comando expirou. -40 A conexão com o Gerenciador de Filas foi encerrada porque foi rejeitada pelo mesmo. Esta rejeição pode ocorrer porque a versão do Conector WQ não é a mesma do Gerenciador de Filas, ou porque o Comunicador não está ativo e conectado com o WQ Remoto. 2) O erro -440 , de acordo com o manual, pode estar ocorrendo pq a máquina foi “restartada” e a conexão ainda não estava ativa qdo a aplicação enviou o pedido. As possibilidades de ocorrências dessas mensagens -4: -412, -413, -414, -415, -416, -417, -418 -440,

Recomendações para migração do ambiente de Homologação para Produção: a. Copiar todo o diretório do servidor de homologação para o servidor de produção b. Alterar as configurações de IP e Porta nas sessões : ** [QUEUEMANAGER] >> Informar o IP do servidor da produção e a porta que o WQ receberá conexão da sua aplicação (default é 9001) ** [REMOTESYSTEM] >> Informar o IP e a porta do CICS de produção do SNG c. Ajustar, se necessário, o (DEBUGLEVEL) para reduzir ou aumentar registros na log (parâmetro está descrito no manual) d. Ajustar o número de bytes das strings de negócio (AUDITDATALENGTH) que serão armazenadas no audit. Por serem dados sensíveis ao negócio, é recomendável iniciar com tamanho grande para analisar os envios e respostas e depois diminuir por segurança Como é possível copiar de um servidor para outro, a estrutura de pastas será mantida. NOTA: Antes de se 'startar' o WQSNG no servidor da produção a 1ª vez, exclua os logs. Após o 'start', será necessário encaminhar a LOG para que a Workers gere a chave de ativação da licença da produção. Observação: Planejar rotina para backup e limpeza de LOGs para evitar que o servidor fique sem espaço em disco no futuro.