1

Introdução

A idéia de publicar alguns livros com a coletânea de posts que já escrevi para o meu blog
no developerWorks (www.ibm.com/developerworks/blogs/page/ctaurion) vinha me
martelando há algum tempo. As minhas observações sobre os acesso ao blog mostravam
que depois de algum tempo os posts eram “esquecidos”, uma vez que o ritmo de inserção
de novos posts tem sido intenso. Gosto de escrever e um blog me dá a liberdade que as
colunas nas revistas especializadas (escrevo para Computerworld Brasil, Mundo Java,
Linux Magazine e Espírito Livre), por razões editoriais, não permitem. De maneira geral
levanto um post a cada três ou quatro dias. Como escrevo os posts de acordo com o
momento, muitas vezes o texto pode até parecer meio deslocado para quem não esteja
acompanhando sistemáticamente o tema. O volume de material acumulado, acredito, é
bem razoável. O blog começou em janeiro de 2007 e em julho de 2009, quando comecei a
preparação desta série de livros, já somava mais de 400 posts.

Surgiu a idéia: por que não agrupar os posts por temas e publicá-los para acesso online?
Uma conversa com meu amigo, desenvolvedor e escritor, Claudio de Souza Soares, definiu
o projeto. Sim, vou publicar os posts em forma de livro eletrônico.

A primeira etapa foi agrupar os posts por assuntos, identificando as relevâncias entre eles.
As tags me ajudaram nisso. Assim, cada assunto ou conjunto de assuntos se tornará um
livro. Procurei manter os posts, na medida do possivel iguais aos publicados originalmente.
Claro que corrigi alguns erros ortográficos, que passaram em branco quando os posts foram
inicialmente levantados.

Este ebook aborda um tema pelo qual tenho muito carinho: os mainframes. Comecei minha
carreira profissional lá pelos idos da década de 70, exatamente em um IBM /360 modelo 40.
Uma máquina de 256 Kbytes! Maquinão, mas que hoje é uma memória simplesmente
ridícula. De lá para cá acompanhei, ora de perto, ora de longe sua evolução e a eterna sopa
de letras que tivemos de aprender ao longo destes anos. Após os /360, vieram os 370 com
memória virtual. Foi neste sistema que estudei bastante o assunto memória virtual, ainda
pouco conhecido. Lembro de inúmeros artigos e papers debatendo influência de fenômenos
como working set de programas e thrashing nos mecanismos de paginação. Em 1980
surgiram os sistemas XA (Extended Architecture) e o espaço de endereçamento passou de
24 bits para 31 bits. Em 1990 os sistemas ESA/390, já com 44 bits e em 2000 os zSeries,
que viram a introdução dos 64 bits e o sistema operacional z/OS. Trabalhei com diversos
modelos de mainframe, como alguns 360 e 370 (os modelos 148 e 158, por exemplo), os
4341 e 4381, os 3090...A história dos 360 pode ser encontrada em
ftp://ftp.software.ibm.com/eserver/zseries/misc/bookoffer/download/360revolution_040704
.pdf.

Convivi também com diversas variantes de sistemas operacionais...Primeiro o DOS/360,

com suas três partições fixas e depois com algumas de suas evoluções, como o DOS/VS e
o VSE. A sua última encarnação é o z/VSE de 64 bits. Uma retrospectiva histórica da
família VSE pode ser vista em http://www-
03.ibm.com/servers/eserver/zseries/zvse/about/history.html. Além do DOS também
experimentei alguns sistemas da outra família, o OS. Foram o OS/MFT, o VS1 e depois o

2
MVS. A sua última versão é o z/OS. E, claro, não poderia deixar de lado o VM/CMS,
sistema pelo qual me apaixonei à primeira vista! Acompanhei bem de perto sua evolução.
Um pouco de sua história vocês encontram no Wikipedia
(http://en.wikipedia.org/wiki/History_of_CP/CMS). Foi com o VM/370 que aprendi os
conceitos de virtualização e hypervisor. Também com VM/370 me aprofundei nos estudos
de capacity planning, indo mais a fundo nos algoritmos de melhoria de performance e
teoria das filas. Foi nestes sistemas que me aprofundei nos estudos de modelos que
simulavam o desempenho dos discos com tecnologia RPS (Rotational Positioning Sensing),
que melhorava a latência rotacional.

E os outros sistemas que faziam e fazem parte do mundo dos maiframes? O CICS, os
antigos DL1, IMS e SQL/DS. O bem conhecido DB2...Em banco de dados convivi também
com alguns SGBD que desapareceram como o Total. Também siglas de telecomunicações
como BTAM, SNA e VTAM. Aliás, quem for adepto da frase “recordar é viver”, sugiro a
leitura do livro “A History of Modern Computing”, de Paul E. Ceruzzi.

Os mainframes estão conosco há 45 anos. Sua longevidade tem uma explicação: são
sistemas que mantém grande parte das atividades comerciais do mundo funcionando. Sem
eles não teriamos os sistemas financeiros e de seguros. Nao teriamos sistemas de reservas
de passagens aéreas e nem processamento de cartões de crédito.

Vamos olhar estes dados:

Mainframes processam mais de 80% de todas as transações eletrônicas globais.

Mais de 95% de todos os dados do sistema financeiros/seguros mundiais são
processados em mainframes.

O valor do portfólio de aplicações em mainframe é estimado em cerca de 1 trilhão
de dólares. Substituir este código custará 20 trilhões de US$!

Estima-se que existam cerca de 200 bilhões de LOC de Cobol em produção (eWeek)
e que todo ano pelo menos mais 5 bilhões de novas linhas de código Cobol são
colocadas em produção.

CICS processa mais de 30 bilhões de transações por dia, representando valores de
negócios correpondentes a 1 trilhão de dólares por semana.

Existem mais de 20.000 licenças de CICS no mundo inteiro, com mais de 30
milhões de usuários finais usando o sistema.

Mais de 900.000 desenvolvedores tem seus salários pagos pela atividade de
manutenção/desenvolvimento de aplicações Cobol/CICS.

Portanto, estamos falando de sistemas que cumprem um papel de extrema importância na

sociedade atual. E como conseguiu esta importância? Várias razões, como um projeto
desenhado desde o início para escalabilidade e confiabilidade (um cluster Parallel Sysplex
de System Z pode processar até 13 bilhões de transações por dia, que é mais que a média
semanal da NYSE, Bolsa de Valores de New York), disponibilidade de 99,999%
(downtime de menos de 5,3 minutos por ano), com alguns clientes de Parallel Sysplex
reportando que operam há 13 anos sem um único downtime, menos consumo de energia (o
consumo de energia por unidade de capacidade decresceu por um fator de 16 desde 1995) e
fortes recursos de segurança. Neste quesito, destacamos o z/OS que é certificado como

3
EAL 4+ e as partições lógicas (LPAR) com EAL5. EAL signfica Evaluation Assurance
Level (http://en.wikipedia.org/wiki/Evaluation_Assurance_Level).

Todos os URL que aparecem nos textos foram acessados e checados durante a preparação
original dos posts, mas como a Web é extremamente dinâmica, existe a grande
possibilidade de alguns destes URL já não existirem ou terem sido alterados, pelos quais
pedimos antecipadamente nossas desculpas.

Lembro também que as opiniões expressas neste ebook e em toda a série de ebooks (como
o foram no blog) são fruto de estudos, análises e experiêncis pessoais, não devendo em
absoluto serem consideradas como opiniões, visões e idéias de meu empregador, a IBM,
nem de seus funcionários. Em nenhum momento, no blog e aqui, falo em nome da IBM,
mas apenas e exclusivamente em meu nome.

Cezar Taurion
Agosto de 2009

4
Gameframe: os mainframes como plataforma para games

No final de abril de 2007 a IBM lançou um press release que me deixou muito empolgado:
vai criar um gameframe, ou um mainframe híbrido, integrando a este sistema o processador
Cell Broadband Engine (Cell/BE). Este sistema é especialmente talhado para aplicações de
“virtual worlds” , sejam estes games MMOG (Massive Multiplayer Online Game), como o
Taikidom (www.taikodom.com.br) da brasileira Hoplon (www.hoplon.com.br ) ou
plataformas para social-networking como o Second Life e outros.

A Hoplon está participando do projeto e temos que parabenizar o seu principal executivo,
Tarquínio Teles, que é uma pessoa simplesmente brilhante. E quem sabe um dia o pessoal
do Second Life também não vai adotar esta tecnologia?

Mas, porque fiquei contente? Comecei minha carreira no /360 e o meu primeiro programa
foi escrito em Cobol. O segundo foi em Assembler (e os meus colegas dinossauros talvez
ainda se lembrem do livro de cabeceira da época, o Principles of Operation e sua sopa de
siglas, como PSW, CCW, TLB e outras).

Aliás, falando em dinossauros, os paleontologistas estão classificando os

informaticossauros em três categorias: os mais veteranos, que começaram suas carreiras no
vetusto 1401 como pertencentes ao do período Triássico. Eu, que comecei nos 360/370 já
me classifico como pertencendo ao período Jurássico. E tem a rapaziada mais nova que
começou no 4341/4381, 3090 e no Vax da Digital, que já são do Cretáceo...;-))

Mas, falando sério, porque este movimento de integrar o Cell/BE ao mainframe, criando
um gameframe? Primeiro, o mercado de games tem uma projeção de crescimento fantástica.
Em 2004, a receita global deste mercado já era de mais de 25 bilhões de dólares e algumas
estimativas apontam que em 2009 deverá estar na casa dos 55 bilhões de dólares. E em
breve os jogos MMOG deverão ultrapassar os jogos baseados em PC, principalmente pela
possibilidade de interação entre seus usuários, impulsionados pela disseminação da banda
larga. Jogar em grupo é bem mais agradável que jogar sozinho contra uma máquina...

Os jogos e as plataformas de mundos virtuais precisam de alta capacidade computacional

(muitas vezes são milhares e milhares de usuários simultâneos, demandando tempos de
resposta em milisegundos e qualquer latência afeta o comportamento dos personagens e
objetos) e é necessário uso intenso de processadores para simulação da física nos
movimentos dos personagens e objetos. Afinal, as leis da física devem também valer no
mundo virtual. Mesmo neste mundo, velhas leis como a da gravidade devem continuar
valendo.

Para ter-se um nível de realismo próximo da realidade, os processadores devem ter uma
capacidade fantástica. O Cell/BE com seus múltiplos núcleos é voltado à computação
intensiva. Hoje ele é o cérebro do PlayStation 3 da Sony e com sua integração ao
mainframe, com certeza vai abrir um novo espaço no cenário dos mundos virtuais.

Jogos MMOG e mundos virtuais demandam características próprias. Os jogadores e

usuários exigem tempos de resposta rápidos e ao mesmo tempo, quanto mais interessante o

5
jogo ou o mundo virtual, mais e mais usuários se conectam para interagir uns com os outros.
Em um ambiente de computação tradicional, quanto mais usuários conectados, menos
tempo de máquina cada um dispõe. Para jogos interativos, degradações na velocidade dos
jogos ou dos mundos virtuais é uma das piores situações, que pode levar ao desestímulo
dos seus usuários e ao fracasso da iniciativa.

Um ambiente de computação tradicional desenhado para este contexto demandaria uma

configuração de alto custo, pois teria que ser dimensionada para um número muito grande
de usuários (e parte do tempo estaria ociosa) e deveria também ser redundante, pois uma
pane no servidor simplesmente colocaria todos os usuários fora do jogo.

Como os investimentos iniciais seriam muito altos (os custos fixos também seriam altos) e
a receita chegaria muito devagar, pois estas aplicações são baseados em mercado de massa,
com um grande numero de usuários pagando valores muito pequenos pelo uso do jogo ou
do mundo virtual, o modelo de computação tradicional simplesmente inviabilizaria o
negócio. Claramente, o modelo exige computação sob demanda (on demand), onde o
mainframe, pela possibilidade de operar centenas de máquinas virtuais (e em Linux) sem
necessidade de conexões físicas, é uma alternativa extremamente válida.

O mainframe, ou melhor, gameframe, tem alta capacidade de I/O, tem latência mínima,
pois utiliza um recurso chamado Hypersocket para comunicação interna entre as diversas
máquinas virtuais e com o uso do Cell /BE tem também agora um processador
especializado em computação intensiva. Melhor que isso, só dois disso!

6
Discutindo TCO

Estive semana passada (junho de 2007) em Brasília, participando de um evento chamado

Comunidade IBM Systems. Este evento reúne as comunidades de clientes IBM em torno
das suas plataformas de hardware. Participei da track de mainframe, System z. Fiz uma
palestra sobre TCO (Total Cost of Ownership) e gostaria de compartilhar algumas das
idéias discutidas.

Lembro que na década de 90, quando no auge do então movimento de downsizing, os

defensores desta tecnologia eram chamados de dinossauros...A computação distribuída
estava no seu momento e pelo famoso “efeito manada” todo mundo embarcou nesta onda.
Muitas empresas fizeram a escolha certa, mas muitas outras talvez não optaram pela
decisão mais adequada. Não deveriam ter desligado seus mainframes. Epa, foi uma heresia
o que eu disse?

Bem, deixe-me explicar...Na época, a principal medida de comparação entre os mainframes

e os novos servidores distribuídos que começavam a se disseminar era o custo de aquisição.
Realmente, quando olhamos a distribuição de custos de TI na década de 90, o hardware era
o principal componente, chegando muitas vezes a 65%-75% dos custos totais.
Aparentemente fazia todo o sentido diminuir os custos de aquisição de hardware, trocando
os então caros mainframes por servidores distribuídos, muito mais baratos.

Mas, a substituição dos mainframes significou também uma mudança no modelo

computacional, de centralizado para distribuído. E este modelo distribuído trouxe novas
variáveis de custo, que antes eram pouco percebidas. Ao mesmo tempo, a tecnologia de
hardware evoluiu de forma fantástica e os preços caíram significativamente. Hoje, quando
analisamos a distribuição de custos vemos que a parcela hardware está em torno dos 25%-
30%, com a maior parte indo para pessoal, software e energia.

Sim, energia é um fator de grande importância e em breve deve se tornar uma grande
preocupação dos CFOs e dos CIOs. Para termos uma idéia da magnitude do consumo de
energia em TI, já temos estudos que mostram que este consumo por parte de servidores
dobrou entre 2000 e 2005. Segundo o Gartner Group, em 2010 metade das empresas
listadas na Forbes 2000 estarão gastando mais dinheiro com energia que com seus
computadores. Outros estudos mostram que somente nos EUA o gasto com energia
relacionada com TI já atinge 29 bilhões de dólares e que esta taxa deve crescer pelo menos
54% ao ano. Outro instituto de pesquisa, o Robert Frances Group declarou em 2006:
“Power and cooling costs will increase to more than one-third of the total IT budget”. E
pior, segundo o IDC, 46,8% dos CIOs não sabem quantos watts por metro quadrado seus
data centers estão consumindo. E os outros mais de 50% apenas “acham” que sabem...

Não é de se estranhar que já começa a se tornar consenso que reduzir o consumo de energia
será muito em breve uma das principais preocupações dos executivos de TI.

O ambiente distribuído foi implementado por máquinas com custo de aquisição bem
menores que os mainframes, mas traziam em seu bojo uma série de problemas,
desconhecidos ou subestimados na época. O software e o hardware destas máquinas não

7
tinham sido projetados para computação transacional, com carga diferenciada e intensiva
em I/O. Em conseqüência, foi necessário adotar-se um modelo de distribuição intensiva,
uma aplicação por servidor. O resultado foi uma grande ineficiência no uso dos recursos
computacionais. Um recente estudo do IDC mostrou que a utilização média dos cerca de 30
milhões de servidores de todos os portes que existem no mundo, situa-se em torno dos 15%.
O IDC estima que o excesso de capacidade instalada é de 140 bilhões de dólares.

Algumas estimativas, analisando a utilização por tipo de servidores, chega-se a uma média
de 5%-10% de utilização para servidores de base Intel ou AMD (ou 90%-95% de
capacidade não utilizada!), 15%-30% para servidores de tecnologia Risc (70%-85% de
capacidade não utilizada!) e, de forma bem diferenciada, em torno dos 80% para os
mainframes.

Claramente tem-se que pensar em uma solução para este desafio. Primeiro, devemos
quebrar percepções arraigadas, tipo “Mainframe é sempre mais caro que um servidor da
chamada plataforma baixa”. Se olharmos apenas o custo de aquisição, sim. Mas se
pensarmos em uma empresa com dezenas ou centenas de servidores e analisarmos seu TCO,
ou seja, quanto custa manter toda a infra-estrutura em operação em um período de 3 a 5
anos, considerando gastos com pessoal, energia, suporte, gerenciamento, softwares
aplicativos, upgrades, procedimentos operacionais, etc, veremos que nem sempre este
axioma será verdadeiro.

Tem uma frase muito interessante de Matt Eastwood, VP de Enterprise Platforms, do IDC,
que há poucos meses disse: “It’s becoming increasingly clear that the typical enterprise
computing infrastructure will require additional investment in order to deliver on these
objectives (business efficiency, improved customer satisfaction and accelerated revenue
growth). This next generation infrastructure will be denser, more energy efficient, easier to
manage, better integrated, more virtual, and much more resilient. For most organizations
this represents a long-term journey requiring IT investment in the new computing
capabilities necessary to meet the IT and business flexibility needs of tomorrow’s dynamic
enterprise. We are still in the early stages of this journey today”.

Analisando a frase acima podemos entender porque o conceito de virtualização está se

disseminando tão rapidamente. Recente relatório da Merril Lynch (Merril Lynch CIO
Survey) diz claramente que “74% of CIOs say they are moving toward bigger “scale up”
machines and thus away from scale out architectures”.
Virtualização é uma estratégia de compartilhar os recursos ociosos espalhados pelos
servidores da empresa, saindo do modelo “one application per physical server”. Mas, para
garantir disponibilidade e desempenhos adequados, o servidor que vai suportar esta carga
bem mais elevada e diferenciada tem que ter sido projetado para isso. É onde entra o
System z. Um grande atrativo destas máquinas tem sido sua capacidade de operar Linux,
consolidando em uma mesma máquina dezenas ou centenas de servidores físicos,
reduzindo-se o custo operacional e o consumo de energia.

Para surpresa de muitos, o IDC recentemente liberou um relatório onde diz que o Brasil é o
sexto mercado mundial de mainframes. O primeiro é claro, são os EUA. Segundo este
analista de mercado, o Brasil corresponde a 1,5% dos investimentos mundiais em TI e gera

8
mais de 11% da receita global de mainframes. E mainframes não são apenas para
dinossauros. A garotada também começa a se interessar por estes sistemas! O 1° Concurso
de Mainframes para estudantes no Brasil, aberto pela IBM, resultou em mais de 2000
inscritos, oriundos de quase 400 instituições diferentes.

Então, vamos pensar out-of-the box? Será que soluções que à primeira vista são excluídas
(mainframe é muito caro...) não deveriam ser repensadas?

9
OpenSolaris nos mainframes

Em agosto de 2007 passou meio desapercebido por aqui o anúncio conjunto que a IBM e
Sun fizeram nos EUA. Neste anúncio a IBM anunciava que estará distribuindo em breve o
sistema operacional Solaris (pelo menos para alguns mercados) em determinados modelos
de servidores de base Intel (System x) e BladeCenter. Vejam em http://www-
03.ibm.com/press/us/en/pressrelease/22163.wss. O acordo prevê que engenheiros da IBM e
Sun trabalharão em conjunto para garantir que haja perfeita integração entre o Solaris e os
periféricos acoplados aos servidores IBM. Afinal, um servidor não é somente feito de
processadores. Agora estes servidores estarão aptos a rodar o Windows, Linux e Solaris. A
IBM foi a primeira empresa a assinar um acordo deste tipo com a Sun. A outra empresa que
havia feito isso era a Fujitsu, mas em sua linha de servidores baseado em processadores
Sparc.

Na prática, este acordo é uma decorrência do sucesso do Linux. Quando a IBM anunciou o
suporte ao Linux em toda sua linha de servidores, muita gente imginou que perderiamos
espaço no mercado de hardware. Não foi o que aconteceu. O VP senior de Systems and
Technology Group da IBM, Bill Zeitler disse textualmente no anúncio: “We are doing
better on the whole now that we do give customers choice” e “When we decided to put
Linux on mainframes, we debated whether that would compromise us or open us to
competition we didn't have, but it opened us up to more customers and enabled us to
compete based on our merits. There will be times when customers look at us and at Sun and
decide Sun's hardware is better, but in my experience, you are better off meeting clients in
the way they want to be met”.

É verdade. Hoje, indiscutivelmente, quem define a melhor solução para si é o cliente e ele
quer ter opções de escolha. Não quer ficar dependente de uma única empresa e se sujeitar
ao seu ritmo de evolução tecnológica. Na minha opinião, o mundo dos sistemas
verticalizados, onde da aplicação ao sistema operacional você depende de uma única
corporação está com seus dias contados...

A variante aberta do Solaris, o projeto OpenSolaris (www.opensolaris.org) tem um kernel

rodando no processador Power, mas não existe nada ofical quanto a uma eventual adoção
nos nossos servidores “System p”. Bill Zeitler foi explícito ao dizer “That's certainly
something that I would like to see, but we'll just have to see if it makes sense”. Que sabe
um dia?

Bem quanto ao Aix, Bill Zeitler também comentou: “mature vendors respond to customer
requirements, and that is what we are doing. We will continue investing in AIX, but we
know lots of customers like Solaris. We don't see that as a compromise. It adds to our
commitment to interoperatibility in the marketplace”.

Mas, o que é importante é que OpenSolaris em System z (mainframe) já começa a rolar.

Uma empresa chamada Sine Nomine Associates já está trabalhando em um projeto para
portar este sistema para esta máquina. No anúncio Zeitler disse que clientes de mainframes
já solicitaram esta alternativa (“There are a large number of customers interested in Solaris
on the mainframe”)

10
e que portanto OpenSolaris em System z é algo que não deve ser descartado... Vejam
http://sinenomine.net/node/607.

Bem, nada ainda está formalizado, embora em recentes eventos de mainframes, como
System z and zSeries Expo, em Munique na Alemanha e WAVV 2007 (World Alliance of
VSE VM Linux), a Sine Nomine apresentou palestras descrevendo o projeto OpenSolaris
no System z. Vejam a apresentação em http://www.sinenomine.net/system/files/L04-
OpenSolariszSeries_0.pdf. Caso queiram acessar outras apresentações do WAVV 2007
acessem http://www.wavv.org/wavv2007/presentations/index.htm. Para a rapaziada dos
mainframes, tem palestras bem interessantes.

Interessante também é o que saiu na mídia sobre o acordo e uma eventual versão do
OpenSolaris rodando em mainframes. Vejam alguns relatos em
http://www.infoworld.com/article/07/08/16/Solaris-on-z-mainframes-next-on-the-agenda-
for-IBM-Sun_1.html e
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName
=mainframes_and_supercomputers&articleId=9031183&taxonomyId=159&intsrc=kc_top.

E quanto aos analistas de indústria? Muitos disseram que foram surpreendidos pelo acordo
(e quem não foi?) , como Charles King, da Pund-It Inc (http://www.pund-it.com/) que
afirmou “I could not have imagined this occurring when Scott McNealy was CEO of Sun, it
seems Jonathan Schwartz is taking the company in a more open and software-driven
direction”. Também disse que “IBM can only gain from the deal. It has limited its
partnership to System x and blade servers, so there is no conflict with IBM's Unix, or
System p platform. I don't see it as a huge income generator for IBM, but it portrays itself
as the provider of a wider array of solutions, and this puts IBM way ahead of the curve”.

Quanto ao System z, ele disse “There was a lot of doubt in the industry questioning the
value of it, but Linux gave mainframe a whole new life, and IBM pressed forward with
specialty processor for Java and Web apps. There is a ton of business out there from users
with huge, aging Sun Sparc rack servers – especially in the financial services and telco
space[s] -- where the mainframe has won as a consolidation platform. With Solaris
available, I can imagine IBM moving Sparc onto mainframe platforms”.

O IDC também opinou sobre assunto “You could have Solaris running on the mainframe
with virtualization capabilities, with logical partitions and multiple instances of Solaris
running, the way we've seen with Linux”.

Na minha opinião, no novo cenário da virtualização, faz todo o sentido colocar novas
alternativas como o sistema Solaris em servidores como System x e System z. Os clientes
precisam consolidar em máquinas mais robustas seus diversos sistemas operacionais hoje
esparsamente (e de forma custosa...) distribuídos pela empresa e a IBM oferecer uma gama
mais ampla de alternativas é uma “sacada” bem inteligente.

11
Os mainframes continuam saudáveis

Estive em mais um evento IBM Comunidades, em novembro de 2007, desta vez no Rio de
Janeiro. Curioso, mas embora more no Rio quase não faço palestras aqui. Que pena!
Na apresentação mostrei que o mainframe (nosso System z), apesar das más linguas,
continua forte e saudável.

Para exemplificar com alguns números, usei dados do evento “System z Summit
Symposium” que a IBM realizou em junho deste ano, em New York. O evento reuniu
analistas de indústria para debater o presente e o futuro do System z e mostrou muitos
números interessantes.

Por exemplo, pouca gente sabe que existem 10.000 mainframes em operação no mundo
inteiro, com uma capacidade instalada de mais de 11 milhões de MIPS. Para se ter uma
comparação em 2000 haviam 3,5 milhões de MIPS instalados e cerca de 9 milhões em fins
de 2005. Ou seja, em menos de dois anos, mais de 2 milhões de MIPS foram instalados!
Olhando-se por outro prisma, multiplicou-se por mais de três a base instalada de MIPS em
apenas 7 anos...Este crescimento mostra que o mainframe continua firme.

São duas as razões para este crescimento. Uma é a compatibilidade dos novos sistemas com
o software legado. Existem cerca de 200 bilhões de linhas de código Cobol em uso hoje e
cerca de cinco bilhões são adicionadas à esta base a cada ano! Uma estimativa econômica
de quanto custaria substituir esta imensa base de sistemas legados chegou a cifra
astronômica de vinte trilhões de dólares.

Aliás, o conceito de “backward compatibility” surgiu no mundo da computação com o

mainframe, com o então System 360. Esta máquina implementou pela primeira vez o
conceito de arquitetura computacional, criando uma camada de abstração ( “instruction set
architecture ou ISA) entre os programas e a máquina. Com este conceito podia-se
programar para uma máquina e rodar em qualquer outro modelo da mesma arquitetura, com
nenhuma ou pouca modificação. Abriu caminho para a futura linha de processadores Intel
x86 e outros processadores que vieram depois... Portanto, o suporte ao legado está no DNA
do mainframe!

A segunda razão é a constante evolução tecnológica. A IBM vem investindo intensamente

na evolução dos mainframes, com mais de um bilhão de dólares por ano em pesquisa e
desenvolvimento. Segundo Bob Hoey, VP de vendas mundiais do System z, como 65% da
receita de mainframes vem de software, não é surpresa que parcela similar seja investido na
evolução deste stack da arquitetura.

Um dos fatores de crescimento da base instalada são os chamados “specialty engines”,

processadores dedicados a determinadas tarefas, como o “Integrated Facility for Linux”
(IFL), o “System z Application Assist Processor” (zAAP) para aplicações Java, e o
“System z Integrated Information Processor” (zIIP) para acelerar funções do DB2. De
acordo com Jim Stallings, gerente geral da linha System z, a base de “specialty engines”
cresce mais rapidamente que a base total de processadores e no início de 2007, já haviam
sido instalados cerca de 1.7 milhões de MIPS em “specialty engines”, dos quais cerca de

12
1.2 milhões de MIPS foram para o IFL, rodando Linux. Segundo Stallings, cerca de 25%
dos MIPS vendidos hoje o são para Linux.

Bem, se quiserem mais informações sobre o System z recomendo acessar o portal

“Destination z”, em http://www-03.ibm.com/systems/z/destinationz/index.html.

13
ZaaP: Java em mainframes

Escrevo uma coluna no excelente revista Mundo Java (www.mundojava.com.br) e

contantemente recebo diversos emails muito interessantes. Um deles me indaga sobre o uso
de Java em mainframes. Sim, Java em mainframes!

A IBM, depois do sucesso do processador especializado IFL (Integrated for Linux)

acoplado ao processadores dos mainframes (System z) lançou um outro processador, desta
vez voltado a consolidar workloads Java nestas máquinas. Este processador chama-se
zAAP (System z Application Assist Processor). Este processador (podem ter vários no
mesmo computador) opera de forma assíncrona com os processdores comuns de uso geral,
e executam código dos programas Java. Com isso, reduz-se a carga nestes processadores de
uso geral, liberando ciclos de CPU para outros aplicativos. E, chamo a atenção, os
processos Java rodam no zAAP sem precisar de nehuma modificação. O zAAP necessita do
ambiente z/OS, sistema operacional nativo do System z.

O que se consegue com isoo? Uma maior consolidação do parque computacional. Você
pode ter no mainframe não apenas os sistemas legados (escritos em Cobol, por exemplo),
mas também os novos sistemas escritos em Java. E adicionando processadores IFL, você
consolidaria também seus inúmeros sistemas Linux. E em breve, com o suporte ao
OpenSolaris, aplicações que rodavam em máquinas Sun/Solaris poderão também ter sua
carga deslocada para o mainframe.

Ah, acessem http://www.ibm.com/systems/z/advantages/zaap/ e

http://www.ibm.com/systems/z/advantages/zaap/gettingstarted/index.html para maiores
informações. Vocês verão também que agora o zAAP permite a execução de serviços
“XML parsing”, o que adiciona mais um atrativo para o System z.

14
Curso de Pós-graduação em Mainframes!

Agora em maio de 2008 tive a oportunidade de fazer a aula inaugural do curso de pós-
graduação em mainframes, na UniverCidade, no Rio de Janeiro.

Até há algum tempo atrás, quem trabalhava com mainframes era visto como um dinossauro.
Aliás, eu também sou um dinossauro da família dos informaticossauros, pois comecei
minha carreira no /360 e o meu primeiro programa foi escrito em Cobol. O segundo foi em
Assembler (e os meus colegas dinossauros talvez ainda se lembrem do livro de cabeceira da
época, o Principles of Operation e sua sopa de siglas, como PSW, CCW, TLB e outras).

Mas o mainframe vem resistindo ao tempo e com sucessivas inovações acontecendo

constantemente. Por exemplo, existe um projeto de um gameframe, ou um mainframe
híbrido, integrado com o processador Cell Broadband Engine (Cell/BE). Este gameframe
será especialmente talhado para aplicações de simulações e “virtual worlds” , sejam estes
games MMOG (Massive Multiplayer Online Game), como o Taikidom
(www.taikodom.com.br) da brasileira Hoplon (www.hoplon.com.br ) ou plataformas para
social-networking como o Second Life e outros.

Outra novidade? Que tal o OpenSolaris em mainframes? Sim, já começa a rolar...Uma

empresa chamada Sine Nomine Associates já está trabalhando em um projeto para portar
este sistema para esta máquina. Vejam http://sinenomine.net/sites/default/files/L04-
OpenSolariszSeries.pdf.

Querem mais? Que tal Java no mainframe? A IBM, depois do sucesso do processador
especializado IFL (Integrated for Linux) acoplado ao processadores dos mainframes lançou
um outro processador, desta vez voltado a consolidar workloads Java nestas máquinas. Este
processador chama-se zAAP (System z Application Assist Processor). Este processador
(podem ter vários no mesmo computador) opera de forma assíncrona com os processdores
comuns de uso geral, e executam código dos programas Java. Com isso, reduz-se a carga
nestes processadores de uso geral, liberando ciclos de CPU para outros aplicativos. E,
chamo a atenção, os processos Java rodam no zAAP sem precisar de nenhuma modificação.

Na palestra mostrei que um dos principais obstáculos para uma maior disseminação do
mainframe é exatamente a percepção errônea que é um sistema obsoleto. E que pouca gente
usa...

Mas, alguns números nos mostram outro cenário: existem 10.000 mainframes em operação
no mundo inteiro, com uma capacidade instalada de mais de 11 milhões de MIPS. Para se
ter uma comparação em 2000 haviam 3,5 milhões de MIPS instalados e cerca de 9 milhões
em fins de 2005. Ou seja, em menos de dois anos, mais de 2 milhões de MIPS foram
instalados! Olhando-se por outro prisma, multiplicou-se por mais de três a base instalada de
MIPS em apenas sete anos.... Interessante que no ano passado, já haviam sido instalados
cerca de 1.2 milhões de MIPS nos processadores IFL, rodando Linux. Na prática, cerca de
25% dos MIPS vendidos hoje o são para Linux. Estes dados mostram de forma inequívoca
que o mainframe continua firme.

15
E para os próximos anos? O lançamento da nova linha de máquinas z10 (vejam em
http://www-03.ibm.com/systems/z/news/announcement/20080226_annc.html) e a nova
política industrial brasileira, apoiando fortemente a exportação de software, deverá
aumentar em muito a demanda por profissionais capacitados em mainframes, pelo maior
número de projetos off-shoring que deverão surgir..

Ok, querem mais informações? Vejam http://www.mainframe.typepad.com/ para terem

acesso a blogs que debatem mainframes, http://www-
306.ibm.com/software/os/systemz/en_US/index.html para acessarem o site da IBM sobre
softwares de mainframe, e http://www.ibmsystemsmag.com/mainframe/ para lerem uma
revista eletrônica sobre mainframes.

16
Mainframes: qual a percepção do mercado?

Uma recente conversa com um colega meu, CIO de uma grande corporação foi
emblemática da percepção de muitos executivos quanto aos mainframes. Ele, como muitos
outros profissionais é da geração formada durante o movimento de downsizing, que
consagrou o modelo cliente-servidor e que considerava “politicamente correto” desligar o
mainframe. Nesta época, início dos anos 90, todo e qualquer projeto de consultoria
recomendava a mesma coisa: troquem os caríssimos mainframes pelos baratos servidores
distribuídos. Claro que muitas decisões de troca foram acertadas, mas muitas outras se
revelaram inadequadas. O custo de propriedade de ambientes distribuidos se mostrou muito
mais caro que se imaginava.

Há tempos fiz um pequeno exercício onde analisei informalmente uma empresa que
houvesse desligado o mainframe no início dos anos 90 e quanto gastou em TI com seu
ambinete distribuído, considerando todos os fatores que envolvem o TCO. Comparei com a
alternativa de manter do mainframe (evoluindo com novos modelos) e claro, com um
consequente uso bem mais restrito de servidores distribuídos. O ambiente 100% distribuído
consumiu em 15 anos mais dinheiro que a alternativa de se manter um ambiente mixto.

É verdade que o custo de hardware há 15 anos atrás era destacadamente o maior do

orçamento de TI. Hoje não é mais. Mas a percepção quanto ao mainframe continua. Fiquei
surpreso em ver o quanto de desconhecimento da evolução dos mainframes ele tinha. E,
tenho certeza, não é só ele...Para muitos o mainframe é apenas um velho repositório de
aplicações Cobol e PL1, tripulado por profissionais à beira da aposentadoria...Bem, ele se
mostrou interessado quando falei que parcela substncial do crescimento de receita da IBM
com mainframes vem de novos workloads, baseados nos chamados “specialty engines”,
processadores especializados para determinadas tarefas.

Mostrei que no contexto atual, o movimento de consolidação e virtualização dos data

centers estão abrindo novas portas para o mainframe. O TCO para se gerenciar um parque
de centenas ou milhares de servidores é altíssimo, acrescido agora da variável energia, que
vem aumentando ainda mais os budgets das áreas de TI. E os “specialty engines”, o IFL
(Integrated Facility for Linux), o zAAP (System z Application Assist Processor) e o zIIP
(System z Integrated Information Processor) tem aberto vários caminhos para tornar o
mainframe a opção prefencial para o processamento de novos aplicativos! Estes
processadores tiram a carga dos processadores principais, otimizando a capacidade
computacional da máquina.

O IFL, por exemplo, surgiu em 2001 e é usado para consolidar centenas de servidores
Linux distribuídos pelos cantos da empresa em uma única máquina. O Linux no mainframe
consegue explorar todas as características únicas do hardware como sua reconhecida
confiabilidade, construída por features como processadores redundantes, elevados niveis de
deteção e correção de erros e conectividade inter-server de altissima velocidade. O nível de
disponibilidade do ambiente operacional do mainframe é muito maior que dos sistemas
distribuidos. E abrir uma máquina virtual Linux em um mainframe leva alguns minutos,
enquanto que comprar, instalar e configurar um servidor distribuido pode levar semanas.

17
O zAAP apareceu em 2004 e é orientado a rodar aplicações Java. Com este engine, as
aplicações Java, que consomem muita CPU, são executadas fora dos processadores
principais, os liberando para outras atividades. E o que é melhor, a aplicação não precisa ser
alterada para rodar no zAAP. Um resultado positivo é a redução do número de stacks de
programação TCP/IP, firewalls e interconexões físicas (e suas latências...) que são
requeridas quando os servidores de aplicação e de data bases estão em máquinas separadas.

E o zIIP, que foi lançado em 2006, volta-se para o processamento de aplicações baseadas
em banco de dados. O zIIP permite centralizar mais facilmente os dados no mainframe,
diminuindo a necessidade de se ter múltiplas cópias espalhadas por dezenas de servidores.
Com o zIIP o mainframe torna-se o data hub da empresa.

Bem, questionado quanto a citar alguns aspectos positivos da consolidação lembrei a ele:
menos pontos de falha, eliminação da latencia de rede, menos componentes de hardware e
software para gerenciar, uso mais eficiente dos recursos computacionais, melhor gestão de
cargas mixtas batch e transacionais, maior facilidade de diagnósticos e
determinação/correção de erors, recovery/rollback muito mais eficiente... O resultado? Um
melhor TCO!

Interessante que uma vez criada uma percepção, tona-se dificil mudar as idéias. Olhar o
mainframe sob outra ótica é uma mudança de paradigmas e mudar paradigmas não é facil.
Paradigma é como as pessoas vêem o mundo, ele explica o próprio mundo e o torna mais
compreensível e previsível. Mudar isso exige, antes de mais nada, quebrar percepções
arraigadas. Mas, por que não repensar o mainframe? Um estudo de TCO pode mostrar que
talvez as idéias e hábitos que tem mantido a TI da companhia nos últimos anos não sejam
tão mais válidos assim...

18
Revisitando o uso de games em mainframes

Em outubro de 2008 foi lançado o jogo online Taikodom, pela Hoplon Infotainment
(www.hoplon.com), empresa genuinamente brasileira. Esta empresa foi criada no ano de
2000, em Florianópolis e investiu cerca de 15 milhões de reais e quatro anos de árduo
trabalho para desenvolver o jogo. O Taikodom é um jogo interessantíssimo, onde os
participantes agem como se estivessem no século XXIII. Mas, o coração do jogo é uma
tecnologia chamada Bitverse, que permite criar ambientes de terceira dimensão, que podem
ser usados por exemplo, além de jogos em ações de ensino a distância. O Bitverse foi
escrito em Java, demonstrando de forma inequívoca a potencialidade desta linguagem para
jogos.

Uma característica diferenciadora do Taikodom é que ele opera em um mainframe System

z10 da IBM! Este é um ponto que chama a atenção. Porque em mainframe? Um jogo como
Taikodom, chamado de MMOG (massive-multiplayer online game) tem como
característica uma demanda massiva e escalável de jogadores. A cada instante pode variar
muito a demanda. O Hoplon, por exemplo, pretende conquistar pelo menos 100.000
jogadores em alguns meses.

O ambiente operacional de um jogo MMOG demanda não apenas uma máquina cliente
poderosa, com boa capacidade gráfica, mas também uma largura de banda bem rápida.
Além disso, a arquitetura dos servidores também deve ser desenhada para eliminar a
latência, que é o maior inimigo dos jogos online. A latência faz com que as ações do jogo
pareçam irreais, lentas, tirando o prazer de jogar. Os servidores nos jogos MMOG tem
adicionalmente a tarefa de gerenciar a interação entre os milhares de jogadores, garantindo
inclusive que suas ações estejam corretas. Os servidores, são, portanto, cruciais para que o
jogo opere adequadamente.

Uma técnica usada em muitos jogos e ambientes tridimensionais é a adoção de inúmeros

servidores fisicos separados (como no caso do mundo virtual Second Life). Isto acontece
porque um único servidor de pequeno porte não consegue dar conta de centenas de milhares
de jogadores ao mesmo tempo. O problema de se usar vários servidores físicos é a latência
que aparece quando a ação sai de um servidor para o outro. Quem usa ou usou o Second
Life nota isso varias vezes, quando os avatares parecem congelar em determinadas
situações. No Secomd Life cada ilha virtual está em um servidor diferente e o teleporte de
uma ilha para outra pode sofrer alguma latência. Outro aspecto interessante é que os jogos
MMOG podem explorar bem os chips multicore. As ações do jogo podem e geralmente
ocorrem em paralelo. Embora milhares de jogadores possam estar online o mesmo tempo,
eles não interagem todos entre si, mas apenas entre pequenos grupos.

O Taikodom está rodando em um mainframe híbrido (gameframe), combinando a

capacidade computacional desta máquina com o processador Power Cell B/E (broadband
engine), multicore. Uma curiosidade, em relação a servidores x86, o z10 equivale a
aproximadamente 1.500 servidores, apresentando até 85% menos de custo de energia e até
85% menos de espaço físico. Bem, no URL http://spectrum.ieee.org/aug08/6518 temos
uma coletânea de papers e discussões sobre o assunto gameframe e jogos MMOG.

19
Mas, geralmente quando se fala em games, imagina-se apenas entretenimento e lazer, para
adolescentes e “vadios”. Mas, o uso de ambientes tridimensionais está se disseminando
rápido e à medida que a geração Y se entranhe nas empresas, mais e mais veremos pressão
para termos estas tecnologias em nossas empresas. Aqui mesmo já discuti este assunto em
alguns posts como em “Virtual Worlds, Virtual Leaders”
(http://www.ibm.com/developerworks/blogs/page/ctaurion/20081008) e “Quem é esta
Geração Y”, em http://www.ibm.com/developerworks/blogs/page/ctaurion/20080921.

Games está se tornando coisa séria, de uso empresarial, para diversos usos como o
Energyvlle criado pela Chevron para divulgar sua política ecoconsciente
(http://www.economistgroup.com/our_news/press_releases/2007/the_economist_group_an
d_chevron_launch_interactive_energyville_game.html) ou America’s Army
(http://www.americasarmy.com/) criado pelo Exército americano para motivar
recrutamento. Existe inclusive um site especifico para discutir os chamados “Serious
Games” que é o Serious Games Initiative, acessado em http://www.seriousgames.org/.

A IBM lançou há algum tempo o INNOV8, um jogo (simulador) que mostra os

fundamentos do BPM (Business Process Management), que pode ser visto em http://www-
01.ibm.com/software/solutions/soa/innov8.html . O INNOV8 é orientado a universidades
que estejam ensinando BPM, é um jogo free, e faz parte do programa Academic Initiative
da IBM.

Bem, e como o Brasil está posicionado na indústria de games? Entrei no site da Abragames
e descobri uma pesquisa sobre a indústria brasileira de jogos eletrônicos
(http://www.abragames.org/docs/Abragames-Pesquisa2008.pdf). Alguns dados da pesquisa:

a) Existem 42 empresas que produzem games no Brasil.

b) O PIB (hardware e software) de jogos eletrônicos aqui é de cerca de 87,5 milhões de
reais.
c) 43% da produção dos softwares de jogos brasileiros é destinado à exportação. O
mercado interno é prejudicado pela pirataria e importação ilegal.
d) Artistas gráficos e programadores são os perfis profisisonais mais comuns na
indústria brasileira de games.
e) Em termos mundiais, o Brasil é apenas 0,16% da indústria global de games.
f) A industria brasileira de games está mais focada em consoles e celulares.

Claramente temos imenso potencial para crescimento! E falando em celulares, os mobile

games estão se popularizando cada vez mais. Nos EUA estima-se que este mercado será,
agora em 2009, de mais de 1,5 bilhões de dólares. Porque? Celulares cada vez mais
poderosos, com melhores recursos gráficos, disponibilidade de redes de banda larga (3G) e
base instalada crescente. Alguns estudos apontam que em 2010 o mercado de mobile games
terá um valor de mercado maior que os jogos de console e PCs.

E como se ganha dinheiro produzindo games? Por exemplo, o mercado de MMOG permite
basicamente dois modelos de receita: venda de assinaturas ou o que foi adotado npela
Hoplon, de entregar o jogo de graça, mas ofertar produtos pagos, como roupas, armas,
espaçonaves, etc. Estes produto são virtuais, mas custam dinheiro real!

20
Uma edição do IBM Journal of Research and Development dedicado ao Z10

O número de janeiro/fevereiro de 2009 do IBM Journal of Research and Development é

dedicado ao mainframe z10. Vejam a edição completa em
http://www.research.ibm.com/journal/rd53-1.html . E sempre é bom lembrar que 2009 é o
aniversário de 45 anos do lançamento do primeiro mainframe, o /360.

Li alguns artigos e um me chamou a atenção. Aborda o desenho da microarquitetura do

processador do z10. Este processador, de quatro núcleos, é fabricado com a tecnologia
CMOS da IBM, de 65 nanômetros e possui 993 milhões de transistores.

É um processador de 64 bits, de 4,4 GHz (comparem com os 1,7 GHZ do z9) que
apresenta um desempenho bem superior ao modelo anterior (z9), não apenas pelas
melhorias na densidade dos circuitos e na velocidade do clock, mas muito devido às
mudanças em sua microarquiteura. Vale a pena ler o paper.

Mas, aproveitando a deixa, falamos que o z10 é um processador de 64 bits. Chegar até estes
64 bits foi uma longa estrada. Os primeiros mainframes, os 360, tinham registradores de 32
bits, mas apenas 24 bits eram usados como endereçamento, limitando a memória a 16MB.
Aliás, esta capacidade de memória era algo inimaginável para a época, meados da década
de 60, do século passado. Lembro que quando comecei a programar, em Assembler 360, no
início dos anos 70, trabalhava no então CSD (Centro de Serviços de Dados) da IBM, no
centro do Rio, que possuia então 3 mainframes 360/40. Dois deles com 64K e um, o
famoso “quarentão”, com 256K. Um espanto. Imaginem então 16 MB! Na prática os 360
maiores tinham 1 MB e alguns raros “monstros” chegavam a 6 MB!

Depois vieram os 370, que implementavam memória virtual. Este recurso permitia que um
programa fosse maior que a memória real. Por exemplo, o programa poderia ter 4 MB,
embora a máquina real tivesse apenas 1 MB. Mas, o endereçamento restrito a 24 bits já era,
claramente, uma limitação para o início dos anos 80. Apareceu então o 370/XA, com
endereçamento de 31 bits. Pouco depois ficava patente que mesmo estes 31 bits eram
insuficientes e surgiu a arquitetura 370/ESA, que permitia segmentação de modo a um
programa acessar mais de uma região de memória de 31 bits.

E finalmente em 2001, apareceu a série z, com 64 bits. Ou seja, foram 37 anos de evolução
para chegar aos 64 bits.

Aliás, por curiosidade, na mesma semana recebia a edição de janeiro da Communications

of the ACM e estava lá um artigo “The Long Road to 64 bits”. Este artigo mostra a
evolução das arquiteturas dos computadores até chegar aos 64 bits. E especula se algum dia
teremos um computador de 128 bits de endereçamento...

Mas, continuando a conversa sobre mainframes, é indiscutivel que mesmo com a crise
econômica, o mainframe continua vendendo bem. Só para termos idéia, nos últimos cinco
anos a capacidade instalada de mainframes, medida em MIPS (milhões de intruções por
segundo) simplesmente dobrou. E, segundo alguns dados do Gartner Group a base instalada

21
de mainframes em todo o mundo já ultrapassa 14 milhões de MIPS. Ora e ainda tem gente
que fala que o mainframe está com os dias contados.

O Gartner fornece alguns dados adicionais bem interessantes: o número de IFLs

(processadores dedicados a Linux) já ultrapassou os 7.000, em mais de 1.300 clientes. O
Gartner estima que MIPS de IFL representam já cerca de 15% da base total de MIPS.
Portanto, mainframe não é apenas reduto de coboleiros...

Um ponto importante: a IBM vem investindo muito nos programas de educação para
mainframes, no mundo todo. Hoje pelo menos 500 universidades, inclusive várias no Brasil,
tem programas de educação em mainframe. O resumo da história: existem boas
oportunidades profissionais para quem conhece mainframes.

E faço um convite a todos interessados em conhecer um pouco mais da potencialidade dos

mainframes. Dia 17 de março de 2009, em São Paulo, a IBM vai organizar um evento para
prestigiar os participantes do concurso mainframe. Serão várias palestras muito
interessantes, premiação dos campeões e também provas de seleção de estagiários. Em
suma, vale a pena dar uma olhada no evento. Começa as 13 horas, no auditório da IBM, na
rua Tutóia.

E uma curiosidade: uma série de mainframes da linha z, lançados em 2003, foram

chamados de T-Rex, uma brincadeira com o apelido de dinossauro com que muitos
chamavam e ainda chamam os mainframes. E isto me lembra um fato interessante. Desde
criança ficava fascinado com dinossauros (e um colega, maldosamente, me disse que foi
por isso que comecei a trabalhar com os 360...) e li diversos livros sobre o assunto. Lembro
de quando o filme “Jurassic Park” foi lançado. Vi várias vezes no cinema e outras
incontáveis vezes no video e TV por assinatura. E ele comete um certo exagero ao ser
chamado de Parque Jurássico. Recordando, os dinossauros habitaram a Terra no correr de
três longos períodos: o triássico, de 250 a 210 milhões de anos atrás, o jurássico, de 210 a
140 milhões de anos atrás, e o cretáceo, entre 140 e 65 milhões de anos atrás. Ora, os
principais dinossauros do file, o T-Rex e os velociraptores são do perído cretáceo e não do
jurássico. O filme, deveria ser chamado de Parque Cretáceo. Enfim, são liberdades
artísticas...

22
Mercado de offshore: mainframes no topo da lista

Aproveitando um tempo de espera em aeroporto, li um recente relatório do IDC sobre o

mercado brasileiro de serviços de offshore. Este mercado, no ano passado (2008) gerou
2,21 bilhões de reais, sendo que quase 75% (1,64 bilhões) foram relacionados diretamente
com desenvolvimento, manutenção e testes de sistemas.

E que tecnologias foram mais usadas nestes serviços? Em primeiro lugar, Cobol, que gerou
554 milhões de reais ou mais de 33% de todas atividades de desenvolvimento e manutenção.
Depois, vem Java com 21% e em terceiro lugar, ABAP (SAP), com 14%.

E para que regiões do planeta estamos exportando serviços de offshore? EUA em primeiro
lugar com 80%, seguido de longe pelos países da América Latina com 8% e Europa com
7%. O relatório também apontou que a empresa que mais exportou serviços de offshore foi
a IBM.

Uma parte interessante do relatório é a que aborda quais as vantagens do Brasil em relação
a seus concorrentes mundiais. Os pontos que aparecem com maior destaque são os aspectos
geográficos (time zone e tempo de deslocamento), aspectos políticos e econômicos (regime
político estável e democrático, e estabilidade econômica), aspectos culturais (afinidade
cultural com os EUA) e boa qualidade e comprometimento dos profissionais. Por outro
lado temos também algumas desvantagens, como pouca maturidade de governança,
escassez de mão de obra qualificada, alta carga tributária, arcabouço trabalhista e carência
de profissionais com fluência em inglês.

23
Programando em mainframes e outros bichos

Saguão do aeroporto Santos Dumont, esperando mais um vôo para São Paulo. Reencontro
um amigo de longa data. Começamos a carreira profissional praticamente na mesma época,
meados dos anos 70. Conversa vai, conversa vem. E recordamos as experiências em
programação. Quase um livro de história...

Lembro que minhas primeiras experiências com programação, ainda na Faculdade de

Economia foram com Fortran. Tentei escrever alguns simplórios modelos econômicos, que
nunca funcionaram direito...Mas realmente era divertido mexer com aqueles bichos
chamados computadores (ainda havia gente que os chamavam de cérebro eletrônico...).

Mas, como atividade profissional, já no então Centro de Serviços de dados da IBM (o

antigo birô), cujo aquário ficava no centro do Rio, comecei carreira programando em
Assembler /360. Programar em Assembler/360 era quase como programar em linguagem
de máquina, só que usávamos mnemônicos ou simbolos que representavam as instruções da
máquina. Cada mnemônico era traduzido diretamente para uma instrução do processador.
Para programar em tão baixo nivel de detalhes, tinhamos que conhecer como o processador
funcionava lógicamente. Aliás, depois destes programas, só voltei a usar assembly quando
do surgimento dos primeiros microcomputadores, quando me atrevi a rabiscar alguns
programas para um processador de 8 bits, o Zylog z80.

Falando em microcompuatdores, estas máquinas também foram o campo de testes para

experimentar programas em C. Quase como escrever em assembly...

Depois, veio o Cobol. O mainstream da programação na época. Escrevi dezenas e dezenas

de programas em Cobol. Inclusive, ao longo dos anos seguintes acabei tendo alguma
experiências com dialetos desta linguagem. No início dos anos 80, como colaborador do
jornal Data News, o embrião do atual ComputerWorld, preparei uma análise dos
minicomputadores nacionais, fruto da então reserva de mercado de informática. Este
trabalho de análise buscou validar a funcionalidade e desenvolver alguns benchmarks
simples dos mini nacionais. Mas me deu a oportunidade de escrever programas Cobol para
várias destas máquinas, como SID5000, Cobra 500 e Bliss-Cobol.

Meu envolvimento com Cobol foi bem grande. Lembro que também escrevi muitos
programas Cobol para máquinas Burroughs...Cobol, apesar de ser uma linguagem da
chamada terceira geração, tem suas estruturas de dados e controle derivadas diretamente
das operações da máquina. Por exemplo, nas estruturas de dados, nos mainframes 360 e
370 se os dados usados em computações não estivessem em formato compactado, tornava
necessário que o compilador primeiro compactasse todas as variáveis envolvidas na
operação aritmética, para então fazer os computação, descompactando, no fim, o resultado.
Este processo desperdiçava os carissimos recursos dos sistemas da época: memória e
processador. Assim, durante um periodo de tempo, já então na Shell, uma das minhas
tarefas era analisar o código fonte dos programas Cobol e desenhar ações de otimização.

As estruturas de controle também geravam alguns desafios. O Cobol permite o uso de

instruções de desvio (jumps) chamados de GOTO. Estas instruções desviavam o fluxo de

24
controle para alguma posição, nem sempre facilmente visualizada, dentro do código e fazia
com que a tarefa de depuração do programa se tornasse algo terrivel. Nos anos 70 apareceu
um grande debate sobre esta questão e um pesquisador/professor chamado Edsger W.
Dijkstra escreveu um paper “GOTO Statement Considered Harmful”, onde dizia “the
quality of programmers is a decreasing function of the desnsity of GOTO statements in the
programs they produce”. Surgiu a programação estruturada e lembro que, adorando a idéia,
dei várias palestras e cursos sobre o tema. Foi um debate bem interessante.

Nesta época ainda tentei escrever programas para uma linguagem criada pela IBM, a PL/1.
Esta linguagem não decolou. Muito complexa e inchada. Mas, foi divertido escrever alguns
poucos programas em PL/1.

Muitos anos depois surgiram linguagens que ficavam muito mais distantes das máquinas
físicas, explorando o conceito de máquinas virtuais. Java é um exemplo tipico. O programa
Java roda dentro de uma JVM (Java virtual machine) que é um ambiente próprio. O
compilador Java não gera código de máquina, mas sim um código especifico para esta
máquina virtual. Caso seja necessario fazer com que o programa rode em outros
computadores, simplesmente escreve-se uma JVM para este computador. O código gerado
pelo compilador continua sendo o mesmo. Este conceito foi depois adotado pela Microsoft
em sua linguagem C#. Escrevi vários programas em Java. É uma das linguagens que gosto
mais. Aliás, existem mais de 200 linguagens de programação que geram código para
JVM....vejam em http://www.is-research.de/info/vmlanguages /.

E vieram as scripting languages. Para mim a primeira scripting language foi o JCL dos
sistemas operacionais de mainframe. Mas, usei bastante uma das primeiras destas
linguagens, a Rexx, que surgiu no VM/370. Depois, já com Unix usei o sh (Shell Script). E,
com Web me arrisquei a escrever algumas linhas de código em PHP e Python.

Nos anos 80 e 90 me interessei muito pela programação orientada objetos. Ministrei vários
cursos e foi a época em que aprendi a escrever programas em C++.

Juntando tudo, acabei brincando com várias linguagens...tempos bons! Ah, parece ser
muito...mas existem centenas e centenas de linguagens de programação. Uma lista delas
aparece em http://sk.nvg.org/lang/lang.html.

25
Autor

Cezar Taurion

Gerente de Novas Tecnologias Aplicadas/Technical Evangelist da IBM Brasil, é um

profissional e estudioso de Tecnologia da Informação desde fins da década de 70. Com
educação formal diversificada, em Economia, Ciência da Computação e Marketing de
Serviços, e experiência profissional moldada pela passagem em empresas de porte mundial,
Taurion tem participado ativamente de casos reais das mais diversas características e
complexidades tanto no Brasil como no exterior, sempre buscando compreender e avaliar
os impactos das inovações tecnológicas nas organizações e em seus processos de negócio.

Escreve constantemente sobre tecnologia da informação em publicações especializadas

como Computerwold Brasil, Mundo Java e Linux Magazine, além de apresentar palestras
em eventos e conferências de renome. É autor de cinco livros que abordam assuntos como
Open Source/Software Livre, Grid Computing, Software Embarcado e Cloud Computing,
editados pela Brasport (www.brasport.com.br). Cezar Taurion também mantém um dos
blogs mais acessados da comunidade developerWorks
(www.ibm.com/developerworks/blogs/page/ctaurion). Este blog, foi, inclusive o primeiro
blog da developerWorks na América Latina. Para contatos com o autor use
ctaurion@br.ibm.com ou ctaurion@gmail.com.

26