Thursday, March 22, 2012

Informix Roadshow 2012: Lisboa

This article is written only in Portuguese, given it's local nature (announcing the Informix Roadshow 2012 in Lisbon)
Este artigo está escrito apenas em Português


Informix Roadshow 2012 em Lisboa


A IBM vai realizar o Informix Roadshow 2012 em Lisboa nos próximos dias 2 e 3 de Abril. O evento terá lugar no IBM Forum Lisboa e contará com a apresentação de Scott Pickett (world wide technical sales). Será portanto apresentado em Inglês.

Os convites estão a ser enviados, bastando enviar um email para ibmdm@pt.ibm.com para efetuar a inscrição. Caso não receba o convite não hesite em contactar-me. Garanta que recebe a confirmação da inscrição. Os lugares são limitados.

O evento conta como habitualmente com uma componente de laboratório, de forma a que não se resuma a apresentações. Naturalmente para além das apresentações e dos laboratórios haverá também oportunidade de contacto com os elementos da IBM e com outros clientes e parceiros, utilizadores de Informix.

A agenda do evento incluí:

  • Últimas funcionalidades na versão 11.7
  • Informix Warehouse Accelerator (lab)
  • Storage Provision (lab)
  • Flexible Grid
  • Melhorias de segurança
  • Compressão
  • Genero
O IBM Forum Lisboa enconta-se nas instalações da IBM no Parque das Nações:


View Larger Map







Thursday, March 08, 2012

Too little, too late? / Muito pouco, muito tarde?

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português


English Version:

I recently got an advice on how to make better use of Twitter... And so I did... I increased the number of people or accounts I'm following and today I was flooded by messages about the launch of one of the database competitors. If you've been paying attention to the net you probably know which one I'm talking about... I've seen some references before and I decided to investigate a little further what were the new features causing all this buzz around it... I must grant credit to the company behind it, since it was not difficult to get information and find several articles and papers and people talking about it.

I think that in the IT field we tend to close ourselves around what we know better. I've seen it in Oracle DBAs, in people working with Informix (you should know it's much harder to find an Informix DBA than a DBA from any other database since we tend to have several hats and play several roles) and with people working in different environments (z/OS is a classical example). And apparently it also happens with people working with SQL Server. I'd say that only this can explain all this enthusiasm... Let me explain why, by picking two of the flagship features of it's new version (I'll be using the terms I've found on the Internet in blogs, articles and so on):
  • AlwaysOn
    Believe it or not this is a form of replication that allows databases to be put together in groups that use a primary server and one or more secondary servers. The replication can be synchronous, or asynchronous. The secondary servers can accept read only queries. It includes some sort of connection redirection and something I could not exactly understand that allows temporary statistics to be computed on the secondaries and stored in temporary spaces...
  • ColumnStore indexes
    This is interesting.... It combines several technologies like in-memory database, columnar storage and star model optimization. This allows incredible time savings, but has some drawbacks, like not being able to update a table with an index of this type (several workaround are mentioned, but all of them have serious implications). It's up to the optimizer to decide if it will use this kind of index or the traditional query plans.
I'm sure that if you're an Informix user, or someone paying attention to the Informix scene, you have a smile on your face by now... And I would not need to explain why. But for the people who are a bit more distracted, or as I mentioned above live on a closed world, let me explain why Informix people have a smile on their faces at this point in the article:

In 2007 (yes, five years ago), IBM introduced version 11.1, code named Chetah, and one of the features was something called MACH-11. This did not cause half the buzz that we're seeing today, but in very short words, it was the ability to configure a set of Informix instances (where we can have several databases) with a primary server, a "close" secondary server, called HDR (which can by synchronous), and several remote secondary servers (RSS) which receive the logs. The communication between these can be encrypted (there are known customer cases using the Internet to ship their logical logs to the other side of the world). Note that the single node HDR existed since version 7 (can't remember the year, because it was before I joined Informix). The HDR was always readable. The RSS are naturally also readable. In 2009 (if memory serves me well, yes, 3 years ago) IBM introduced version 11.5, called Panther where MACH-11 was extended: We can now configure the secondary servers to accept write instructions which are transparently sent to the primary server. A new piece of software was introduced, called the Connection Manager, that can redirect clients based on pre-defined criteria (or SLAs) which are mapped to the several kinds of servers (or to specific server names). Finally, the statistics gathered on the primary are automatically available on the secondary servers, so there is no need to re-calculate them on the secondary servers. All this works in shared nothing architecture which allows for big geographic dispersion and naturally allows for disaster recover... Oh... and it's terribly simple to setup and use, and it's included even in the free product versions (with some restrictions). And I could continue, writing that in 2010 IBM launched version 11.7 which included the concept of flexible grid, ideal for truly distributed systems that need to dhare data.

Last year, (Q1) IBM announced the addition of new technology to the Informix product line, which targeted BI environments with a star schema design that needed very fast response times for analytical queries. This has the name of Informix Warehouse Accelerator, and combines several technologies: in-memory database, columnar storage and full cluster capabilities (for horizontal scaling). It duplicates the data into the accelerator memory and the Informix optimizer redirects the queries that can be accelerated and that would benefit from that acceleration. You can keep using the base tables as usual, you don't have to change the application layer, and you can control through SQL if you want to use the most recent data (stored in the traditional row storage) (slower) or the possibly older data stored in the accelerator (faster). Note that this creates full star (fact tables and dimensions) data duplication for full power acceleration.

So, although as expectable there are a few technical differences that can make us prefer one or the other, the biggest difference between some of these features seems to be the year they were launched... And yes, the buzz generated around them... and that with Informix you have more platform choices. At times like this I tend to agree with people that complain about IBM (they used to complain about Informix) marketing... Maybe, just maybe, IBM should concentrate on marketing instead of product development... That seems to be what others do with apparently good results... But again, if you're an Informix user, I'm sure you prefer the opposite.



Versão Portuguesa:


Recentemente fui aconselhado sobre como tirar mais partido to Twitter... E assim fiz... Aumentei o número de pessoas ou contas que sigo, e hoje fui inundado de mensagens sobre o lançamento de um dos fornecedores de base de dados concorrentes. Se tem prestado atenção à Internet deve saber a qual me estou a referir... Já tinha visto algumas referências antes e decidi investigar um pouco mais quais eram as novas funcionalidades que causavam toda esta movimentação... Tenho de reconhecer e dar crédito à empresa por detrás do produto, pois não foi difícil obter informação e encontrar vários artigos, papers e pessoas a escrever sobre o assunto.


Tenho para mim que as pessoas na área das TIs tendem a fechar-se sobre aquilo que conhecem melhor. Tenho visto isto em DBAs Oracle, em pessoas que trabalham com Informix (deverá saber que é muito mais difícil encontrar um DBA Informix que um DBA de qualquer outra base de dados, dado que tendemos a usar vários chapéus e desempenhar várias funções) e também em pessoas que trabalham em diferentes ambientes (o mundo dos mainframes é um exemplo clássico). E aparentemente isto também acontece com pessoas que trabalham com SQL Server. Diria que essa é a única explicação para tamanho entusiasmo... Deixem-me explicar porquê, pegando em duas das funcionalidades mais badaladas por esses blogs e twits que se referem a este lançamento (vou usar os termos originais em Inglês, que encontrei na Internet):

  • AlwaysOn
    Acredite-se ou não, parece ser uma forma de replicação que permite colocar várias bases de dados em grupos que usam um servidor principal e um ou mais servidores secundários. A replicação pode ser síncrona ou assíncrona. Os servidores secundários podem aceitar queries só de leitura. Incluí algum tipo de redirecionamento de conexões e algo que não consegui compreender totalmente mas que permite que sejam calculadas estatísticas nos nós secundários que são guardadas em espaços temporários.
  • ColumnStore indexes
    Isto é interessante... Combina várias tecnologias, como base de dados em memória, armazenamento em colunas e optimização de modelos em estrela. Isto permite enormes poupanças de tempo, mas traz algumas desvantagens, como não permitir alterações (INSERTs, UPDATEs, DELETEs) em tabelas com este tipo de índices (são apresentadas várias formas de contornar a limitação, mas todas com sérias implicações). Cabe ao optimizador decidir se deve usar este tipo de índice ou usar os planos de execução tradicionais.
Tenho a certeza que se é um utilizador de Informix, ou se tem estado atento ao mundo Informix, deverá ter um sorriso na cara por esta altura... E não necessitaria de explicar porquê, podendo encerrar já aqui este artigo. Mas para as pessoas mais distraídas, ou como disse acima, para quem viva num mundo mais fechado, vou explicar porque é que os utilizadores de Informix estarão a sorrir neste momento.

  Em 2007 (sim, há cinco anos atrás), a IBM lançou a versão 11.1, com o nome de código Cheetah, e uma das suas funcionalidades foi o MACH-11. Isto não causou metade do alarido de hoje, mas em breves palavras, é a capacidade de configurar um conjunto de instâncias Informix (onde podemos ter várias bases de dados) com um servidor primário, um servidor secundário "próximo", chamado HDR (que pode ser síncrono) e vários servidores secundários remotos (RSS) que recebem os logs. A comunicação entre os servidores pode ser encriptada (há casos conhecidos de clientes que usam a Internet para enviar os logical logs para o outro lado do mundo). Note-se que o nó secundário único (HDR) existia desde a versão 7 (não sei o ano, pois foi antes de entrar na Informix). O HDR sempre disponibilizou acesso para leitura. Os RSS incluíram desde o início a capacidade de aceitar queries para leitura. Em 2009 (se a memória não me falha, sim, há três anos atrás) a IBM introduziu a versão 11.50, chamada Panther onde o MACH-11 foi melhorado. Podemos agora configurar os servidores secundários para aceitar instruções de escrita que são enviadas de forma transparente para o primário. Uma nova peça de software foi introduzida com o nome de Connection Manager, que permite redirecionar os clientes baseado em critérios pré-definidos (ou SLAs) que são mapeados nos vários tipos de servidores (ou em identificadores específicos de cada servidor). Finalmente as estatísticas calculadas no servidor primário estão automaticamente disponíveis nos servidores secundários, por isso não há necessidade de as re-calcular nos secundários. Tudo isto funcionam numa arquitetura shared nothing o que permite uma vasta dispersão geográfica e automaticamente disponibiliza disaster recovery. Ah... E é terrivelmente fácil de criar e usar, e vem incluído até nas versões gratuitas do produto (com algumas restrições). E poderia continuar, dizendo que em 2010 a IBM lançou a versão 11.7 que introduziu o conceito de flexibale grid, algo verdadeiramente pensado para ambientes distribuídos mas com necessidade de partilhar dados.



O ano passado (Q1) a IBM anunciou a adição de nova tecnologia á linha de produtos Informix, cujo alvo foi ambientes de BI com modelos em estrela que precisem de tempos de resposta muito rápidos em queries analíticas. Tem o nome de Informix Warehouse Accelerator e combina várias tecnologias: base de dados em memória, armazenamento de colunas, capacidade de trabalhar em cluster (para crescimento horizontal). Duplica os dados para a memória do acelerador e o optimizador do Informix redirecciona as queries que podem ser aceleradas (se daí vier proveito). Podemos continuar a fazer o uso normal das tabelas de base e não é necessário mexer na camada aplicacional, e podemos controlar através de SQL se queremos ver os dados mais recentes (guardados no formato de linha tradicional) (mais lento) ou a versão possivelmente mais antiga guardada no acelerador (muito mais rápido). Note-se que isto duplica completamente o modelo em estrela (tabela de factos e as dimensões) para atingir uma maior performance (toda a query é resolvida no acelerador).


Portanto, embora como seja expectável, existam algumas diferenças técnicas que nos façam gostar mais de uma abordagem ou da outra, a maior diferença entre algumas destas funcionalidades parece residir mais no ano em que apareceram... E sim, no ruído à volta... e no facto de em Informix podermos escolher a plataforma. Em alturas como esta sinto-me tentado a concordar com quem se queixa do marketing da IBM (já se queixavam da Informix). Talvez, quem sabe, a IBM se devesse concentrar mais no marketing do que no desenvolvimento dos produtos... Parece ser o que outros fazem e com aparentes bons resultado... Por outro lado, se é um utilizador Informix tenho a certeza que prefere o contrário.

Tuesday, March 06, 2012

Sessions for all / Sessões para todos

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The session list for the 2012 IIUG user conference is available... And just a quick glimpse at it makes me even more sad for not being present. If you still have the chance to go, don't hesitate.
I was just looking at the session list to decide a few sessions to highlight, but I can't! Honestly... I could point a few that don't raise my interest, mainly because I have the idea I know enough about that particular topic. But the vast majority makes me recall my biggest problem when I attended the conference: decide between two or three simultaneous sessions which one should I attend...

So, as usual, this looks YAYOGVFM (Yet Another Year Of Great Value For Money) :)
All the hot topics are covered:
  • TimeSeries
  • DataWarehouse the the Informix Warehouse Accelerator
  • Security
  • Mobile apps
And of course, this year's bonus: It's not in Kansas City! :)
This was my attempt of a joke. Kansas City is a good place for a conference since it's next door with the Lenexa Labs. I just hope that the traveling won't prevent the I&D team members and product architects to be present on the conference.

So, in short, if you can don't miss it!

Versão Portuguesea:

A lista de sessões para a conferência de utilizadores de 2012 do IIUG já está disponível... E basta uma vista de olhos rápida para que lamente não poder estar presente. Se ainda tem hipótese de ir não hesite.
Estava a ver a lista de sessões para destacar algumas, mas não consigo. Sinceramente... Poderia indicar algumas que não me despertam muito interesse, essencialmente porque tenho a ideia que são tópicos sobre os quais sei o suficiente. Mas a grande maioria faz-me recordar o maior problema que tive quando assisti á conferência: Decidir a que sessão assistir das três ou quatro simultâneas que existiam...

Portanto, como vem sendo hábito, parece MUADEVPD (Mais Um Ano De Excelente Valor Pelo Dinheiro) :)
Todos os tópicos mais badalados estão cobertos:
  • Timeseries
  • Datawarehouse e o Informix Warehouse Accelerator
  • Segurança
  • Aplicações móveis
 E claro, há ainda o bónus deste ano: Não é em Kansas City! :)
Isto foi uma tentativa de piada. Kansas City é um bom sítio para uma conferência dado que fica perto do laboratório de Lenexa. Espero muito sinceramente que a necessidade de viajar não impeça os membros da equipa de desenvolvimento e os arquitetos do produto de estarem presentes na conferência.

Em resumo, se puder não perca esta oportunidade!



Thursday, February 16, 2012

4GL WHENEVER ERROR

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

I believe this is the first time I cover a 4GL topic here. But a recent customer situation motivated me to write this. Hopefully most of the readers will just say "Yeah... Everybody knows that...", but it's not the first time I see people making the confusion I'm going to describe, and in my opinion that happens because it's not intuitive. Although it's perfectly documented, I suppose many people just follow the intuitive approach and fall into the problem.

I'm talking about the WHENEVER statement. It is used to define the behavior of the program when(ever) a defined condition (ERROR, SQLERROR, WARNING, SQLWARNING or  NOTFOUND) happens. The behavior can be CONTINUE, STOP, GOTO or CALL function. Seems pretty simple and handy... so why am I writing this? The usual confusion relates to the scope of the WHENEVER statement. At first glance you could think this was a program instruction, and the effect or scope of it would be until the program flow reached another WHENEVER statement. And this is the confusion many people make.
In reality it's not a program instruction, but instead it's a compiler directive. As stated in the documentation the scope is local to the module where it appears. If the module contains only function definitions, then all this functions will behave accordingly to the conditions used in the WHENEVER statement. The program flow is irrelevant.
This is better shown with a practical example (line numbers added for clarity)
 1  DATABASE sysmaster
 2  MAIN
 3        DEFINE v INTEGER
 4        CALL func_1() RETURNING v
 5  END MAIN
 6
 7  FUNCTION func_0()
 8        WHENEVER ERROR CONTINUE 
 9  END FUNCTION
10
11  FUNCTION func_1()
12        SELECT no_column FROM no_table
13        RETURN 1,2
14  END FUNCTION

Ok, this is a very simple 4GL program that uses sysmaster database. It has two functions:
  1. func_0
    Is never called, but contains a WHENEVER ERROR CONTINUE which tells 4GL to continue execution when it encounters an error
  2. func_1
    This contains two errors. It tries to access a table that doesn't exist and returns two values (and the CALL on line 4 expect only one)
If we compile and execute it we get:
cheetah@pacman.onlinedomus.net:fnunes-> c4gl -o test.4ge test.4gl;./test.4ge
Program stopped at "test.4gl", line number 4.
FORMS statement error number -1320.
A function has not returned the correct number of values 
expected by the calling function.
cheetah@pacman.onlinedomus.net:fnunes->

What happened? The first error to expect would be the SQL error... But 4GL ignores it and raises an error on the CALL line. Why? Because from line 8 onward the code ignores errors. But the CALL on line 4 is not protected against error. If we comment the func_0 function, and repeat we get:
cheetah@pacman.onlinedomus.net:fnunes-> c4gl -o test.4ge test.4gl;./test.4ge
Program stopped at "test.4gl", line number 12.
SQL statement error number -206.
The specified table (no_table) is not in the database.
SYSTEM error number -111.
ISAM error:  no record found.
cheetah@pacman.onlinedomus.net:fnunes->
This is the expected behavior, but note that we didn't change the program flow.

So, to be clear, WHENEVER ERROR acts at compile time, and means that from it's occurrence downwards, all the code within the module will be protected until another WHENEVER statement is reached. And it affects only the current module. It has nothing to do with the program execution map.

Just one last reminder: Never use WHENEVER without introducing code to test for errors (for CONTINUE condition). Otherwise your program may do unexpected things


Versão Portuguesa

Julgo que esta é a primeira vez que escrevo aqui de 4GL. A motivação deriva mais uma vez de uma situação vivida num cliente. Com sorte, muitos dos leitores dirão apenas "Sim... toda a gente sabe isso...", mas já não é a primeira vez que encontro a confusão que vou relatar, e na minha opinião tal acontece porque é algo pouco intuitivo. Apesar de estar claramente documentado, suponho que muitas pessoas apenas seguem o instinto e daí cairem no problema.

Estou a falar da instrução WHENEVER. É usada para definir o comportamento do programa sempre que uma determinada condição (ERROR, SQLERROR, WARNING, SQLWARNING ou  NOTFOUND) acontece. O comportamento pode ser CONTINUE, STOP, GOTO ou CALL de uma função. Parece muito simples e prático... Sendo assim porque estou a escrever sobre isto? A confusão habitual relaciona-se com o raio de acção da instrução. À primeira vista parece uma normal instrução de programa, e a sua acção extender-se-ia até que o fluxo de execução do programa encontrasse outro WHENEVER. E isto parece ser assumido por muita gente.
Mas na realidade não é uma instrução de programa, mas sim uma directiva de compilação ou compilador. Como é referido na documentação a sua influência restringe-se ao módulo onde é usada. Se um módulo só contém definições de funções, então essas funções comportar-se-ão conforme a instrução ditar. O fluxo de execução do programa é irrelevante.
É melhor mostrar isto com um exemplo (números de linhas adicionados por clareza):
 1  DATABASE sysmaster
 2  MAIN
 3        DEFINE v INTEGER
 4        CALL func_1() RETURNING v
 5  END MAIN
 6
 7  FUNCTION func_0()
 8        WHENEVER ERROR CONTINUE 
 9  END FUNCTION
10
11  FUNCTION func_1()
12        SELECT uma_coluna FROM nao_existe
13        RETURN 1,2
14  END FUNCTION

Isto é um programa 4GL extremamente simples. Usa a base de dados sysmaster e contém duas funções:
  1. func_0
    Nunca é chamada, mas contém um WHENEVER ERROR CONTINUE que força o 4GL a continuar a execução caso encontre algum erro
  2. func_1
    Esta função contém dois erros. Tenta aceder a uma tabela que não existe e retorna dois valores (a chamada CALL na linha 4 apenas espera um)
Se compilarmos e executarmos obtemos isto:
cheetah@pacman.onlinedomus.net:fnunes-> c4gl -o teste.4ge teste.4gl;./teste.4ge
Program stopped at "teste.4gl", line number 4.
FORMS statement error number -1320.
A function has not returned the correct number of values 
expected by the calling function.
cheetah@pacman.onlinedomus.net:fnunes->

O que aconteceu? O primeiro erro que esperávamos era o erro de SQL... Mas foi ignorado e o erro do CALL foi despoletado. Porquê? Porque da linha 8 em diante o código ignora os erros. Mas o CALL da linha 4 não está protegido. Se comentarmos a função func_0 e repetirmos obtemos:
cheetah@pacman.onlinedomus.net:fnunes-> c4gl -o teste.4ge teste.4gl;./teste.4ge
Program stopped at "teste.4gl", line number 12.
SQL statement error number -206.
The specified table (nao_existe) is not in the database.
SYSTEM error number -111.
ISAM error:  no record found.
cheetah@pacman.onlinedomus.net:fnunes->
Isto é o esperado, mas repare-se que não mudámos o fluxo de execução do programa.

Portanto, clarificando, WHENEVER ERROR actua na fase de compilação, e significa que daí em diante, todo o código desse módulo, ficará protegido contra erros até ao aparecimento de outro WHENEVER. Não tem portanto nada que ver com o fluxo de execução do programa

Apenas uma nota final: Nunca utilize o WHENEVER (com a opção de CONTINUE) sem introduzir código que teste os erros. Caso contrário o seu programa pode fazer coisas inesperadas