Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:

1. Native Flash Storage

IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.

Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.

But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.

2. Row and Column Access Control

This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.

"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."

Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.

Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.

3. JSON

IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.

JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.

Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)

The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.

4. Node.js

IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.

You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.

The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.

5. REST Web Services

IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.

If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.

If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.

Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

Java en el System i

La JVM de IBM vs el JDK clásico. Cap 13, pag 591

Continuando el comentario (y recomendación de su  lectura) del Red Book sobre modernización del System i, dos palabras sobre Java en  el i.

Siempre se discute la lentitud de Java y su manejo de espacio de memoria, pero deberíamos decir que esto depende mucho  de la implementación y del aprovechamiento de las herramientas disponibles. Particularmente, IBM ha hecho un cambio radical en la JVM: el reemplazo por la implementacion de IBM,  Por experiencia, hemos pasado por casos que comenzaron con fallos y caídas, y fueron ajustados y optimizados hasta pasar a un funcionamiento absolutamente normal. En el capítulo 13 del red book, se comenta sobre la lentitud de Java (13.3.2 Myths surrounding Java: Java is slow)

Is Java really slow? It depends on what you compare it to. (...) you must choose the correct tool for the job. If what you need is high performance, you must select a lower-level language, such as C/C++ or RPG, but if you are dealing with huge and complex applications, it might be better to use a language with more flexibility, such as Java.
The reputation for slowness that Java usually carries is related to the JVM and not the language itself. The Java language is dependent on multithreads and large amounts of memory. Many people who are accustomed to running other languages starve their Java applications, which causes terrible performance. On the IBM side, the Classic JVM was not designed for IBM POWER architectures. It was ported from the original Oracle version, which resulted in performance issues. However, IBM Technology for Java is designed for the platform and it has been highly optimized by IBM to leverage the Power architecture. With this new version of Java, you can take advantage of the multithreading nature of Java, which was not possible before. Lastly, processor technology has improved greatly over the past few years. Processors are geared toward multithreading, which is a significant boost to Java based applications. 

Disponible desde 1998, ha pasado mucho desde su introducción en el System i, progresando hasta ser hoy una alternativa confiable. IBM comenzó ofreciendo soporte a la JVM clásica de Java, hasta que decidió atacar los problemas de adecuación a la plataforma, desarrollando su propia versión, tanto de un conjunto de clases y servicios que explotan los recursos nativos del equipo (IBM Toolbox for Java), como de una propia JVM, que ajusta la versión clásica desarrollada hoy por Oracle:

Java on IBM i can take advantage of the 64-bit architecture of the systems to provide a scalable solution from single processor machines all the way up to multiprocessor machines. The Classic JVM was unique in its implementation of asynchronous garbage collection, which allowed the JVM to continue processing application requests during the garbage collection cycle.
Nevertheless, this uniqueness of the Classic JVM became a disadvantage. For many developers and vendors, it required much work to port their applications to the IBM i, which disabled the portability features of the Java platform. This also resulted in more expenses to IBM and slower releases of the new Java versions and updates. In addition, the Classic JVM was based on porting code that was not tuned to the features built within the IBM PowerPC architecture. Starting in V5R4, IBM i started to move away from the Classic version of Java and support for Classic is now stabilized. Today, Java is delivered on IBM i only through the IBM Technology for Java version.  (...) Initially the IBM Technology for JVM was implemented only on 32-bit architecture, but since IBM i 6.1, the 64-bit version is available for use. This gives more flexibility for developers, allowing them to fit the JVM according to their needs.

Este es un aspecto importante a tener en cuenta: las nuevas ediciones del sistema operativo implementan sólo la versión de Java de IBM. Así, Java 7 es implementada solamente en la versión de IBM. Sin embargo, esto no debería alterar la ejecución de código, sino explotar la posibilidad de usar de manera nativa servicios y posibilidades del sistema operativo y de la base de datos. El "IBM Toolbox for Java" y su equivalente open source JTOpen ofrecen un excelente medio de interactuar con los recursos del sistema.

En nuestro caso, el desarrollo de aplicaciones web con Webclient, que utiliza java como capa intermedia, nos ha dado oportunidad de comprobar la posibilidad de usar java sobre el System i. Básicamente, nuestras aplicaciones se ejecutan sin diferencias (salvo extensiones que concientemente explotan facilidades del sistema) sobre servidores Websphere en System i, iSeries o como se le llame, y sobre servidores Tomcat o Jetty (en este caso sólo para pruebas). Y quisiera decir que, además, las herramientas de análisis de problemas y performance que Websphere ofrece, son superiores al momento de tener que estudiar problemas. Probablemente, la posibilidad de usar Java nativamente es una de las mejores garantías de modernización y explotación del equipo, convirtiéndose en un puente entre el mundo móvil, web y de recursos infinitos que propone IOT, y la potencia de procesamiento y de manejo de datos del i.

Plex en el System i

Y a propósito de modernización en el System i (o 400, o iSeries, o...), ¿cómo está Plex? En un breve inventario, podemos decir que el RPG ILE  está soportado, así como el SQL ILE RPG. Pero construcciones complejas no lo están, tanto en cuanto a las posibilidades extendidas del ILE (Integrated Language Environment) como en cuanto a la generación de servicios disponibles en alguna plataforma (servicios web, tal como hoy es posible usar WCF en .NET, especialmente), o deseables por su propia importancia, como las extensiones para acceso web, móvil, el soporte de cloud computing, la ampliación del uso del SQL, la integración con Linux, Mac, Windows... ¿qué hay del soporte de PHP, Ruby, o la inclusión de Node.js en el sistema?
Algunas de estas características o facilidades están ya disponibles a través de terceros: CM First permite mover desde el System i a aplicaciones web y móviles tanto modelos de 2E como de Plex, así como se lo puede hacer con Websydian. Servicios web fueron abordados ya hace tiempo por Websydian. En cloud computing  CM First ha iniciado desarrollos con EC2 DE Amazon. Existen múltiples patrones desarrollados por miembros de la comunidad de Plex, tanto para el uso de SQLRPG, como para el uso de servicios web, entre otros. Desarrollos corporativos a veces compartidos y a veces apenas conocidos por la comunidad de usuarios.
Pero lo más importante es que existen varias solicitudes en curso de actualización del soporte de ILE, que aparecen como candidatos a ser incluídos inicialmente en la versión 7.2, aunque más probablemente en la 8. Entre ellas, una ampliación de la generación de código para SQLRPG, el manejo de datos varchar, el paso de la creación de DDSs a DDL. ¿REST? En algún momento Simon Cockaine preguntó a la comunidad sobre su uso, lo que puede incluírlo o no.
Visto en conjunto, una respuesta irregular pero no muy lejana de las posibilidades de la plataforma. El uso del API del OS/400 permite un flexible acceso a los recursos, aunque se extraña una respuesta más avanzada de quienes debieran conducir el producto.

Futuro del 400..(o como se llame en 2020)

Linea de tiempo planificada para el System i - (En IBM System Magazine)

Steve Will, Arquitecto Jefe del System i,  publica en IBM System Magazine (30 de marzo) un artículo explicando la planificación de futuras versiones del System i (AKA AS400, i Series, System i...), que extiende el ciclo de vida de los sistemas hasta dos próximas versiones como planes inmediatos, llevando su ciclo de vida hasta más allá de 2025: la corriente versión aparece planeada hasta 2020/2021, y confirma que están trabajando en dos siguientes versiones (Next i+1/Next i+2). La primera, con cambios que expanden características ya en desarrollo, y la siguiente, determinada por cambios mayores no contenibles en la primera.

(...) we have two major releases under development right now. The 7.2 release came out less than a year ago, and we’ve been working hard on its following major release – called “i next” on this chart. But, we have items that we know cannot fit into “i next” but which require a major release, so we are working on the one after that, “i next +1.” 

 Lo más importante del artículo de Will es la indicación del compromiso de IBM con el sistema, y de su potenciación en el marco de la evolución tecnológica actual:

The key to understanding this next chart is to recognize when there is a known, committed date and when there is just a direction. A known date is represented when the horizontal line has a vertical end. For example, IBM i 6.1 was released in 2008, and its announced end of service is in 2015; both ends of that line are vertical. But while IBM i 7.2 came out in 2014 (vertical left end) the end of service date is indicated by an arrow, meaning we have not announced anything.

However, if 7.1 and 7.2 are each supported as long as 6.1 and V5R4 were, then 7.2 is going to be supported out into the 2020s.

And, very importantly, I told you that we have two more releases actively under development right now. When will they be released? Well, the ends of those lines are arrows, so we’re not saying yet. The availability dates could still change, but clearly, we don’t tend to deliver new releases any sooner than two years these days, and sometimes it’s longer than that. So, “i next” and “i next +1” will come out sometime, and if they also are supported for seven years, well, we’re more than 10 years out into the future now.

Furthermore, on the previous chart, we discussed that new capabilities are coming out in between releases. This means that the “Support” chart does not indicate only “support” but also a timeline for delivery of new function via TRs.

 Frente a la socarrona afirmación (repetida frecuentemente) de la obsolescencia del equipo, creo que realmente tendríamos que pensar más en la obsolescencia de las perspectivas con que se planean desarrollos sobre la plataforma: cada vez me siento más inclinado a abandonar definitivamente cualquier referencia al "400", considerando la distancia entre aquello que estaba disponible en el 400 hace veinte años, y lo que es posible hacer hoy en el "i":

We’re adding new capabilities in virtualization, cloud, I/O, DB2, mobile, open standards and much more. Staying current with new technology is a clear indication we are investing and plan to be around for a long time.

Windows 9, ¿a vueltas y revueltas?

Un post de CA en Google+ pone sobre aviso:

We've already said goodbye to Windows XP and now we're saying goodbye to Windows 8. What's next for Windows devotees?

El post remite a una nota de Alex Wilhelm en TechCrunch del 10 de agosto (Saying goodbye to Windows 8) que básicamente adelanta una relativa vuelta atrás de la marcha hacia mobile en la siguiente versión, Windows 9, Threshold, o como finalmente se llame:

If Windows 8 was a dramatic lurch towards mobile computing, especially on tablets, Windows 9 appears to be heading for a more equitable balance between desktop muscle, and mobile capability. That fits into the larger picture of the computing environment, where PCs are stabilizing after a dramatically difficult period, and tablet growth is cooling.
Microsoft needs to ensure that its desktop-facing operating system manages to support the still-large demand for desktop-focused PCs well. That doesn’t meant that Windows, as part of Microsoft’s vaunted ‘one Windows‘ strategy can abandon tablets, but it does mean that the focus needs to be more even.

¿Es una vuelta atrás completa? Imposible, particularmente si tomamos en cuenta el cambio de arquitectura ya producido (WinRT):

So back to the desktop? Not entirely. Microsoft isn’t backing down from the Windows Store. It isn’t abandoning the Start Screen. Live Tiles do not appear to be going anywhere, on Windows or Windows Phone. Instead the company seems to be at once focusing on providing a Windows 7-quality desktop experience in Windows, while also tying that desktop life to its new mobile-friendly interface, and apps.
That’s why it’s widely expected that Metro apps will be able to run in a windowed-fashion on the desktop in Windows 9, better bringing the Windows Store into the most popular side of Windows.

¿Se trata de un movimiento inesperado (o mejor dicho inesperable)? Creo que no ¿Favorece a sus clientes y usuarios este camino errático? Seguramente tampoco.
Hay mucho tiempo para estudiar la transición...de la transición.
Más información de interés sobre Windows 9 en TechRadar.

Microsoft End-of-service: prepare su cronograma

Comentado por Mary Jo Foley esta semana: Microsoft comunica el fin de soporte de varios de sus productos para este 2014, y los planes para los próximos años. Es oportuno estar al tanto de este cronograma, para organizar las propias estrategias: Windows 7, Windows Server 2008, Exchange Server 2010 y Windows Phone 7.8  pasan a soporte extendido en enero de 2015 (El soporte extendido dura 5 años e incluye actualizaciones de seguridad gratuitas y soporte técnico con revisiones de pago. Además, Microsoft no aceptará solicitudes de cambios de diseño o nuevas características durante la fase de soporte extendido, según indica el propio anuncio de Microsoft). Foley recuerda que este año también pasan a "soporte extendido" Office 2010 y Sharepoint 2010:

Support for Office 2010 with Service Pack 1 ends on October 14, 2014, as does support for SharePoint 2010 with SP1. Support also is ending for Forefront Unified Access Gateway 2010 with SP3 and Visual Studio 2012 Remote Tools, Test Professional, and Express for Web, Windows 8 and Windows Desktop.

pero además, que finaliza todo soporte para Windows Server 2003:

Complete end of support for Windows Server 2003 is approaching next year, as well. On July 14, 2015, Microsoft's extended support period for that product cuts off, which means the company won't be issuing patches, updates or fixes of any kind for that operating system (unless users have pricey Custom Support Agreements in place). A number of small businesses are still running Windows Server 2003. Microsoft officials are hoping to convince them to move to Windows Server 2012 R2 and/or Azure

Es decir, en sólo un año más, todo la comunidad de instituciones, negocios e individuos que mantiene algún tipo de licencia de Microsoft, se encontrará en la encrucijada de quedar fuera de soporte (o recibir un soporte reducido) , o escalar a un nuevo modelo de sistema operativo, con todas sus conexiones e implicaciones. No se trata de cambios graduales, sino de largas listas de incompatibilidades, ausencias de soporte y documentación, sorpresivas incidencias por recursos perdidos, ignorados, desaparecidos. En el nuevo modelo al que todos los usuarios se asoman hay un corte radical con una escasa posibilidad de integración del patrimonio preexistente de aplicaciones y herramientas. No es algo que salte a la vista, pero es algo que está presente donde se enfoque la atención.
Es decir, activamente conozca el alcance de los cambios, y planee una ruta; examine su patrimonio y estime su plan de acción futuro...Quizá, si su patrimonio está muy comprometido, sea hora de estudiar otra alternativa global.

Migrando a System i 7.1

En un proyecto en el que trabajo, en poco tiempo más (midiendo en meses) migraremos un conjunto de sistemas IBM i (AKA AS/400, iSeries, al menos en su base), de 6.1 a 7.1, mientras que IBM ya anuncia i 7.2 . El cambio no representa  inconvenientes mayores: probablemente no haya demasiado que tocar en aquellas aplicaciones que generamos con Plex, que básicamente no debemos recompilar ni tampoco rehacer código.Únicamente deberíamos asegurarnos de que ningún API usada o procedimiento de lenguaje de control pudiera entrar en conflicto por obsolescencia. De acuerdo a la información adelantada por IBM, los problemas no vendrían por este lado. Es casi seguro que podremos seguir trabajando todas nuestras aplicaciones RPG, sus APIs, y nuestro CLs, sin modificaciones.
En cambio, tenemos asegurado trabajo de revisión con Java, quizá el área de mayores novedades en el software incluído para la versión 7.1, ya que, si consideramos que nos movemos desde 6.1, debemos tener en cuenta que la nueva versión abandona la máquina virtual estándar de Java (esta parte tampoco nos afecta, porque Websphere 7.0 ya la usa), y utiliza sólo la propia de IBM (J9). Esto sí requiere análisis y tests para aquellas aplicaciones que no se ejecutan con Websphere.  En el caso del servidor de aplicaciones, que es el que usamos relacionado con Plex, estimo que podremos mantener inicialmente la versión 7 de Websphere, que ejecuta Java 6, pero en algún momento debemos pensar en subir su versión a 8.1, que usa Java 7. Y esto implica que también deberemos planear la migración de Plex a 7.1. No es obligatorio, ya que podríamos mantenernos como hasta ahora, pero debemos pensar que también podemos llegar a estar presionados por los cambios en Windows, de 7 a 8.
A pesar de todos estos movimientos, no es mucho lo que impacta en nuestras aplicaciones, que se mantienen con cierta holgura en estos movimientos de versiones. Más bien, lo que debemos repensar es qué cosas podríamos reenfocar, sacando provecho de las nuevas posibilidades: gran parte de los cambios se manifiestan como extensiones. Mayor es el peligro si habláramos de dependencia de Windows, ya que el paso de 7 a 8 sí apunta a un cambio de arquitectura mayor. Pero de estos inconvenientes podemos hablar mejor en otro momento.
Dany Burger, en The Four Hundered, dedica un interesante artículo a los problemas de migración de i 6.x a i 7.1 y 7.2, que me motivaron a chequear nuestros propios riesgos a futuro. Como en otras ocasiones, es de reconocer y agradecer la política de cambio y migración de IBM y el iSeries (o como lo llames), que difícilmente te deje en una situación de callejón sin salida con una aplicación antigua: se puede evolucionar gradualmente sin tirar lo que ya está hecho.

RPG antes y ahora

Este año se cumplieron veinticinco años de la aparición del As400/iSeries/System i o cualquier otro nombre que se propongan agregarle. De su robustez y excelente diseño dan testimonio dos artículos recientes: uno dedicado a recordar sus primeros ensayos y nacimiento, y otro evaluando el estado actual del RPG como lenguaje moderno. El primero, escrito por Mel Beckman, recuerda su inicio como programador, participando en beta tests del equipo en una empresa cercana a Rochester. Sólo rescato dos párrafos:

Despite the plethora of early bugs, we RPG programmers quickly began to see their frequency decreasing as the S/38 OS, called CPF (Control Program Facility) stabilized. S/38’s single-level store, object-oriented architecture, and integrated database really did seem to make programs more reliable, heading off the most common coding gaffs and preventing wholesale machine crashes. As the S/38 matured, it gained a reputation for solid reliability in the finance and healthcare industries, which are still strong markets for the system’s descendent, today’s IBM i. Throughout the S/38’s evolution to AS/400, iSeries, and ultimately Power hardware architectures, IBM has been able to preserve customer’s investment in business logic and data storage.
I had no idea then just how powerful the S/38’s innovations would turn out to be. They enabled IBM, and its many customers, to transport an immense amount of binary code and data into the future – not just twenty-five years, but thirty years, with very few disruptions. IBM promised, with both the S/38 and the IBM i, to protect users’ business investment in applications, processes, and logic.
In the intervening decades, many other systems have come and gone, dragging their user populations into oblivion with them. Only IBM i has preserved a continuous architectural path that is still going strong today. In 2013 it’s clear that IBM alone kept it’s promise.

El segundo artículo es un editorial del IBM System Magazine, escrito a propósito de las celebraciones de los 25 años del equipo (sistema operativo + recursos + hardware), puntualiza el estado actual del RPG, que de ninguna manera es ya lo que inicialmente fue (generador de reportes):

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.
While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.
In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.
If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.
Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.
Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.
Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

Como los autores dicen, mientras hemos visto pasar y desaparece equipos, lenguajes y arquitecturas, el diseño conceptual del AS400 sigue vigente y en primera línea. Centenares de miles de instalaciones lo demuestran. Quizá aún a pesar de algún directivo de la propia IBM, que a veces parece dudar de su producto.

Otro enfoque crítico sobre Windows 8

A las diversas razones que exponen distintos analistas acerca de los problemas críticos que podría experimentar Windows 8, Tim Worstall agrega otro: Windows Metro exige que los viejos usuarios de Windows deban aprender una nueva manera de relacionarse con su sistema operativo. Si se debe aprender algo nuevo, pudiera ser que se optara por algo con un costo menor o directamente gratuito:

Yes, it looks like a good enough tablet operating system. And it’s also quite fine as a desktop operating system. But there’s a problem with the way in which every user now has to learn to use the operating system all over again. And what should worry Redmond a great deal more than some journo like me remarking upon this is the way that at least one fund manager has sold his stock in the company as a result of his confusion over their plans.
(...) The essential point is that at the heart of the Microsoft value equation is their near lock on desktop operating systems.
Even if we all stopped writing new code for Windows (as, to some extent is true, we have done, much writing is now being done in Python and so on which is not platform or OS specific) right now then there are vast numbers of legacy systems out there that will continue to require Windows licenses for decades to come.

But Windows 8 asks everyone to relearn how they interact with a computer. Yes, there’s still that legacy systems tailwind helping the company. But if everyone now has to learn a new OS then why would everyone learn the new Windows? The very change they’re bringing in means that people will be open to changing to a non-Windows platform.

I could argue this from an entirely personal perspective. Sure, I use a computer as the essential tool for making my daily bread and butter. I use Windows simply because that’s what every cheap computer on the market comes pre-loaded with. Plus I’ve near 20 years experience of using one form of Windows or another (no, really, I had Windows 1.0 at one point). But I don’t actually use “Windows” if you see what I mean. I use something that opens a word processor, I use something that will allow a browser to run. And that really is about it. I’m sure my experience of computing is similar to the vast majority of people out there too. We’re no more interested in which OS we use than which spark plugs are in our car’s engine. As long as it works then we’re happy.

Which is the danger of presenting us with an entirely new way (the Metro interface which pretty much insists that you access as if you’re on a tablet) of interacting with the computer. If we’ve got to learn all this new stuff well, why not go off and use some other OS that doesn’t force us to do so? Or one that we don’t have to pay for?

It’s entirely possible even that Metro, the tablet interface, really is a better and more intuitive method of interfacing with a computer. But who cares? Maybe changing where the pedals on a car are is a really good idea too. But can you imagine trying to bring in such a change while still keeping your market share?

 Windows 8 consiste en una paradoja: En su mercado consolidado, el escritorio, Windows 8 no solo no agregará más nada sustancial (Win32), sino que lo considerará "legacy", con todo lo que ello implica. Y sus novedades, su nueva visión (WinRT), las pondrá en un mercado, el móvil, en el que  tiene un peso prácticamente nulo, y donde debe hacerse un lugar entre dos grandes competidores. Una apuesta al filo de la navaja.

Win 8/Metro, en su camino

Microsoft acaba de anunciar su tablet, que a simple vista confirma dos hechos, uno muy obvio, y otro, su consecuencia o "daño colateral". Lo primero, que el objetivo de Windows 8/WinRT/Metro es competir por una posición hegemónica en el mercado de dispositivos móviles, por delante de su preocupación por el mercado de computadores de escritorio (de servidores, ni hablar). Lo segundo, la manifestación visible de la dualidad a la que Microsoft se ve sometida: habrá dos entregas de tablets: una con "Windows 8" (Win32), y otra con "Metro" (WinRT); más aún, el tablet vendrá con un teclado flexible, apareciendo en las presentaciones "como si" fuera un portable ultrafino: ¿todo el mercado a mano? No tanto en la opinión de algunos críticos, al menos. Jason Perlow o Steven J. Vaughan-Nichols en ZDNet, Dave Thier en Forbes. El más extenso, Perlow, que no solo nota los problemas de la dualidad de oferta, sino también lo inconveniente que resulta que Microsoft salga a competir con su universo de socios fabricantes:

(...) The Surface tablets in and of themselves look like nice devices. Beautiful construction, decent specs. But absolutely nothing was said about price or availability. Only that the Windows RT/ARM version will ship around the Windows 8 retail release timeframe (October) and the Pro/Intel version will ship 3 months after that.
To quote Microsoft, “suggested retail pricing will be announced closer to availability and is expected to be competitive with a comparable ARM tablet or Intel Ultrabook-class PC. OEMs will have cost and feature parity on Windows 8 and Windows RT.”
So let me get this straight, Microsoft. You made journalists schlep across the country, no, the planet, for a product that might not ship for months? You’re lucky they didn’t burn the venue down.
Okay, no ship date, no prices and… no compelling 3rd-party applications or even Office to show on it whatsoever. So we have no idea how well it performs, and how well supported it will be by 3rd-party software developers. No partnerships to speak of. Nada.

No demonstration or even any claims of how good the battery life on each model is.

Nothing to say whatsoever about the nature of what display technology they are using, whether it is OLED or LED/LCD backlight or something else. Great, so one is a 720p and the other is a 1080p. Details, please.

Gee, that doesn’t exactly make folks want to stop in their tracks from buying iPad 3s, does it?
(...) Okay. Back to the the dual-architectures thing. They decided to launch a tablet product with their own brand, but bifurcate the message? Which one are we really supposed to buy, then? ARM for consumers? x86 for prosumers and enterprises?
And oh yeah. That niggling little OEM thing.
Does that mean that a “Surface” branded Microsoft tablet is bloatware free? Why should we as consumers buy an OEM device now, if the Microsoft is going to be the “Pure” Windows 8 experience, a la Google’s Nexus, and will be “price competitive” with the OEMs?

(...) And if the Pro version of the Surface is powerful enough, with Intel Core i5 Ivy Bridge CPUs, why do we need Ultrabooks if we can just clamp a keyboard cover to a Surface Pro?
Am I the only person who beleives this thing is a total jump the shark cluster-you-know-what for Microsoft?
Right now, Microsoft’s OEMs — with the exception of whatever “lucky” company got the nod to do the contract manufacturing for this product — must be absolutely livid. To produce their own ARM and x86 Windows 8 systems, they have to pay exorbitant licensing fees.
Windows RT is going to cost an estimated $85 per copy to your average OEM. A Windows 8 Professional license on x86 will be considerably more.

I don’t care what the hell Microsoft says about partners having cost and feature parity, that’s $85 of pure margin advantage that Microsoft has and the OEM doesn’t.

But since Microsoft now produces its own hardware, that $85-$150 per copy the OEM would otherwise have to pay is pure profit which gives them an unfair advantage.

And wait until we start seeing the BOMs for Surface added up by companies like iFixit and see how much cheaper Microsoft can go than the OEMs with their own competing Windows 8 tablets when manipulating the supply chain as well.

What are the OEMs supposed to do? Well I suspect that if you are someone like a Lenovo or a Hewlett-Packard, you probably are seriously going to re-think whether or not you really want to produce tablets with similar specs to the Surface RT and Surface Pro.

You now have to out-value the Surface devices, or you have to play the Enterprise game with beefier, more expensive Windows 8 convertible tablets with higher-res screens and faster CPUs and SSDs that nobody other than select Fortune 500 firms may want to buy, because they’d rather do business with a hardware partner they already buy systems from.
And the Ultrabook concept may no longer be sexy to the majority of its target market anymore. Intel can’t be particularly crazy about that.
And the Asus and Acers of the world? How are they going to compete on margins with this thing, unless they are being chosen as the actual contract manufacturers? Something tells me that the bulk of the contract biz on the Surface is going to end up with Foxconn, Quanta and Samsung, not these folks.
Personally, if I was Steve Ballmer and the bigwigs at Microsoft, I would have done it a bit differently.
“Surface” as a brand name actually is pretty good. It sounds futuristic and new. So why just not make “Surface Tablet” the brand name for all convertible Windows 8 tablets? Or have Surface replace “Windows” as the name of the OS going forward?
Why not give the OEMs access to the manufacturing technology for the special “VaporMG” casings and the keyboard cover? Why create such a potentially hostile situation by biting the hand of the companies that license your software which is currently your bread and butter income stream?
What, you really want them to start pushing Ubuntu and Android and other Post-PC solutions for real now? Because now you just asked them to.
All of this reeks of suicidal thinking from a company that wants to deep six its long-established manufacturer ecosystem.
It does not reflect the actions of a company that tried so hard to shed long-held industry perceptions of being a monopolist, and worst case, it could potentially re-ignite federal antitrust activity that Microsoft has spent more than ten years digging itself out of.
Yeah, I’m cranky. But I’m not crazy.
Will Surface result in untenable, stressed relationships with Microsoft’s traditional OEM partners and Intel, and a renewal of its status as industry monopolist? Talk Back and Let Me Know.

La exagerada muerte del RPG

Continuando lo dicho hace poco, y a propósito de lo mismo, sigue discutiéndose en un grupo de LinkedIn acerca de la insólita opinión de un editor sobre el RPG. Insólita porque quien declara la muerte de la principal herramienta del iSeries (AKA AS400) es el director técnico de la publicación que se dedica al iSeries. Insólita, porque se une a otras voces de su competencia, dando razón a sus argumentos. Mucho ya se ha anticipado, y se puede retomar a través de las discusiones enlazadas. Sin embargo, ahora quisiera destacar algunos de los argumentos positivos en favor del RPG que en esta más que interesante discusión se están desarrollando todavía.
Antes que nada, quiero destacar lo que Scott Klement ha dicho al respecto: cuando hoy se habla de RPG, se debe hablar de RPG IV, o ILE. Desde este punto de vista, el lenguaje no sólo se muestra muy activo, como pudiera decirse también de otros muertos de buena salud (COBOL) sino que además ha vivido una importante evolución respecto a sus antecesores (III, II) que lo convierten en una herramienta poderosa en el marco del iSeries. Como Scott ha dicho, decretar la muerte del RPG (ILE), es como declarar muerto al iSeries...algo que su competencia desearía, y está lejos de suceder (salvo que IBM esté dispuesta al suicidio).
Lo que sigue, son algunos puntos destacados en esta discusión:
Nathan Andelin sobre OOP:

Saying that RPG isn't object oriented is a red herring. OO is generally characterized by "encapsulation", "polymorphism", and "inheritance". By far the most prominent characteristic of OO is encapsulation, and nothing meets that characteristic better than ILE RPG.

It's not that RPG is not object oriented. It's just that polymorphism and inheritance are not as fully implemented in the compiler as in a language like Java. However, RPG programmers are free to implement their own interfaces that support polymorphism and inheritance to the degree of their choice. I've written about that in the past and posted sample code over the years. 

La referencia de Andelin a RPG y OOP es más extensa, y probablemente sea mejor ver pos separado. Invito por ahora a seguir su explicación, distribuída en más de una de sus intervenciones.

El mismo, sobre la potencia del RPG asociado al iSeries:

Our user interfaces are written in HTML, CSS, and JavaScript, while the majority of our server-side code is RPG. Following are some reasons one might consider using RPG for web applications:

RPG has more efficient database interfaces. Most applications NEED record level access as well as SQL for database I/O. RPG uses less CPU and I/O, has less latency, and performs much better than more mainstream languages, etc.

RPG web applications can maintain state just like 5250 applications, which takes a burden off programmers as well as garbage collectors. Users can even launch multiple instances of the same application without worrying about the state of each. Users can end jobs and free resources by clicking an Exit link.

You can launch RPG programs that perform database I/O and browser I/O and run under IBM i user profiles. You can use IBM i security interfaces to specify authorities of each. User IDs are automatically recorded in journal entries for changes made to IBM i databases and other objects.

RPG jobs can take advantage of IBM i workload management; utilizing subsystems, memory pools, run priorities, time slices, library lists, job descriptions, job logs, output queues, spool files, etc.

With RPG you can activate thousands of IBM i jobs to support thousands of concurrent users where each job can have its own runtime environment. Contrast that with so called “modern” languages that run under environments where you have to set up a separate virtual machine for each environment.

Workload management under IBM i is much more advanced and offers much more control than managing workloads with LPARS and comparable virtual machines. A hypervisor doesn't know the characteristics of workloads that run under a VM that it's managing. It may know whether a VM is requesting resources or not but it has no understanding of priority. IBM i is more effective at managing workloads.

Rather than setting up multiple virtual machines for separate organizations, or for separate development, test, or production environments, you can use separate subsystems, and separate library lists. RPG saves programming time, system administration, and computer resources, which ultimately saves money.

Giuseppe Tintor, sobre el uso de RPG en la capa servidora:

I use Java to write web application (jsp, servlet) but the databse access is done through RPG programs only; RPG il called from Java using pcml interface so I'm sure that the database is completly closed to external users and nobody can run sql, query or excel inquiries on files. None is aware that behind a web page there is RPG and none notice performance problems! I think that RPG is the perfect tool to manage database access on AS/400.  

 Una línea de discusión abierta sobre la capacidad del iSeries de sostener múltiples trabajos simultáneos toca no sólo al RPG, sino al soporte del propio sistema operativo; la comparación con un servidor Windows puede incomodar a administradores de éste servidor. A propósito de una pregunta de uno de los participantes (Is the concept of an active job in the IBM i the same as the concept of an “active job” in a PC server? As I understand it, one user in the IBM i is at least one job. In the PC world, one job can accommodate numerous users – dependent on the PC server’s resources, of course. (...) Tens of thousands? I know the IBM i QMAXJOB shipped value is 163520 but do you have experience with your system reaching that many users (tens of thousands) ? If I’m not mistaken, the client I work for only has a little more than 1500 users. Even then, their IBM i which is at V7R1 is already experiencing performance degradation. (I think I need to ask my manager about that again.) [preguntado a Andelin por Allan Roberto Garcia]):

You asked, "Is the concept of an active job in the IBM i the same as the concept of an “active job” in a PC server?"

It's a good thing that I reread your question a couple times and put some thought into it because I think I profoundly misunderstood it the first time.

At first, I thought you might be talking about the concept of a "process" under IBM i vs. a "process" under Windows. When you open Task Manager under Windows and navigate to the Processes tab you see a screen that looks fairly similar to the WRKACTJOB display under IBM i. Right?

Windows Task Manager shows you a list of .exe files "running". WRKACTJOB shows a list of "active jobs" under IBM i. I think you would find a lot of similarities between what an "active job" might be doing under IBM i, and what a Windows .exe might be doing. Wouldn't you agree?

One key difference would be that you would NEVER see tens of thousands of running .exe files under Windows. The runtime environment would be destabilized long before that could occur. But under IBM i, tens of thousands of "active jobs" would NOT be a problem.

So, while there may be many similarities between the work being done by Windows .exe files and IBM i active jobs, the design of the runtime environments are profoundly different. Windows cannot support complex workloads reliably. Complex workloads under Windows must be divided between multiple physical or virtual machines in order to run reliably (being generous with respect to Windows reliability).

One of our customers has more than 10,000 active jobs running daily on a 4-core, 32 Gig RAM IBM i server. Consider the number of active jobs that a 256-core, 8 Terabyte RAM IBM i server might be running.

Sorry for that analogy, or comparison. I don't think that's what you were really asking about. But I do think there is a relationship.

You say, "In the PC world, one job can accommodate numerous users – dependent on the PC server’s resources, of course."

Would that "one job" you're referring to be the ASP.Net server? It wouldn't have to be. It might be a PHP server. It might be a JEE application server. Actually there are many options.

Under the IBM i framework we use, one active job might be supporting multiple concurrent users. In that case, multiple concurrent requests might be queued. The program would be responsible for managing each user's state. There would be "restore state" and "save state" operations for each request.

Our framework also supports a "launch method" where a new job is loaded and run for each user who clicks on its associated menu item. We don't limit the number of menu items that a user may have "active" at the same time. User state is automatically maintained. The active job ends when the user clicks the "Exit" link.

We also support a launch method where a specific set of users may be supported by one active job; participants in a meeting for example. When the meeting ends, it ends for all users.

We run into use cases for each type of "launch method". They each have advantages and disadvantages. It's just nice to be able to support each.

I should say something about managing complex workloads under the IBM i native environment vs. application servers such as ASP.Net, JEE Application Servers, and PHP.

In the case of the latter, you will almost always find that the only way to scale those environments and make them run reliably is to separate them into multiple physical or virtual machine instances, and front end them with load balancers, which normally requires numerous skilled people to manage.

Under IBM i, we scale by launching active jobs into subsystems, each of which may be linked to separate HTTP server instances; possibly linked to separate client organizations; keeping their workloads separate.

Overall, IBM i workload management is WAY superior to load balancing between virtual machines.

La discusión aún continúa. Sólo he destacado algunos puntos. Otros, tales como el modelo OOP, o el desarrollo de aplicaciones web contra funciones servidoras RPG están desarrolladas, ejemplificadas, y ofrecen excelentes perspectivas. Una gran respuesta a quienes dan por muerto lo que no conocen.

El futuro de Chrome

Tengo una PC portable obsoleta, de la que me niego a desprender porque en su momento me dió buenas prestaciones, ahora escasa  en velocidad de su procesador, memoria y disco disponible, pero con una capacidad de conectividad que sigue siendo importante. Durante un tiempo pensé en instalarle algún Linux light, pero nunca me terminó de convencer la alternativa. He pensado en usarla como "servidor" para tests en casa, o para restringirla a un browser y un editor de texto...En meses recientes, sin embargo, se ha presentado una posibilidad más interesante: instalarle el sistema operativo de Chrome, aparentemente más o menos light, como para ayudarme con el hardware que tengo, y orientado especialmente a la nube. Hoy, un artículo de ZD Net refuerza la idea de Chrome como un sistema operativo hegemónico, y con razones nada despreciables. Esto es lo que Christopher Dawson afirma en ZD Net (5 reasons everyone will be using Chrome OS in 3 years):

Google’s first round of Chromebooks met with mixed reviews and far greater adoption in schools where their easy management and fast boot times made them more popular than with consumers. Google and Samsung announced yesterday that next-generation Chromebooks were rolling out, along with a major release of Chrome OS and new devices call Chromeboxes. All in all, it was a big day for Chrome OS, and yet, as Larry Dignan pointed out, the pricing on Chrome OS devices remains too high for serious consumer or enterprise adoption.
However, in computer-land, three years is forever, and in that period of time, I expect that Chrome OS will be all over the enterprise, consumer spaces, schools, and SMBs. In fact, I expect that it will be ubiquitous in the way that Linux and Java are: we don’t even know we’re using them on our phones, in our TVs, in our DVRs…everywhere. Here’s 5 reasons why.

1. It’s going to be cheap

Yes, Larry’s right. These devices are too expensive right now. But Moore’s Law tells us that this will change. Fast. And Chrome OS doesn’t need the latest hardware to run quite well, particularly now that it can take advantage of GPU acceleration. Sure, the original Atom-based Chromebooks were a bit pokey, but enhancements to the OS itself have taken big steps to address the issue. The latest generation of Chrome OS devices aren’t exactly using quad-core beasts. They’re leveraging commodity hardware, paving the way for serious price drops in the relatively near future.
Chrome OS is also being tested on ARM hardware and is unencumbered by much in the way of licensing since it’s based on the open source Chromium OS project.

2. It’s flexible

Have you used the Chrome Web Store? There’s a lot of really useful software just a click away that runs right within the browser. Whether you are using Chrome OS or the Chrome web browser, the experience is the same and the developer ecosystem is pushing hard on the boundaries of what we thought was possible in terms of web applications. The variety of applications already available in the Web Store is impressive, to say the least, just a year and half after its launch.
If Netflix, Facebook, Angry Birds, and Autodesk applications can all run happily in Chrome OS, there won’t be much to differentiate it from a full-blown desktop OS in the months and years to come. Or from an embedded OS. Or a mobile OS. It all depends on the applications OEMs choose to develop, surface, and install for users.

3. Because Chrome OS and Android will merge

As early as 2009, Sergey Brin predicted that Android and Chrome OS would likely draw closer to each other and then merge. The Chrome browser for Android is hinting that this is getting closer to reality, as are various bits of information emerging about Android 5, most of which point to at least the beginnings of unification.

Android is already dominant in mobile devices and runs on everything from televisions to refrigerators to tablets. Chrome has the largest browser marketshare now. When Chrome, Chrome OS, and Android all start looking very much like each other and all dominate their respective markets, it’s not a big stretch to start calling Chrome OS ubiquitous.

4. It’s Google

If Google has proved anything, it’s that they have enough money to keep hammering away at a market until they own it. They proved it with Android on mobile phones. They proved it with their Chrome browser. They proved it with search and related ads. They’ve had their share of missteps and projects like Google+ remain out with the jury. However, if the project is ultimately about growing their core business (namely advertising) and getting ads in front of more people, they’re absolutely dogged. And while their war chest isn’t quite up to Apple’s standards, they can win wars of attrition with just about anyone. Besides, what would you rather see on that connected television? A familiar web browser with snappy app interfaces and a cool Web Store or some kludgy Java interface that doesn’t look a thing like what you use on your desktop, laptop, mobile phone, or tablet to access content?

5. Because the web will be all you need

This is already true for most users. In developing countries, the only personal computing device that many people own is a simple mobile phone with basic web access. Elsewhere, cloud-based applications continue to displace desktop applications and increasing numbers of users spend their days staring at a web browser instead of any particular application. Microsoft’s Office 365 acknowledges the need for at least a hybrid approach to the cloud and most of the interesting software we read about now comes in the form of cloud-based web applications or mobile apps.

Even Adobe, the last reason I bother using a full-blown PC, started shipping Muse (a rich WYSIWYG web development platform) this month and, while not a web application itself, leverages the Air runtime environment to be small, light, and fast.

The next version of Bethesda Software’s massively popular and visually stunning Elder Scrolls series? An MMORPG. No, it won’t be 100% browser-based, but without the web, fans would just be sitting in front of their aging XBOXes. Goodbye game consoles, hello cloud.

This webification movement has taken off in the last 18 months. It isn’t hard to imagine what the next three years will do to the way we think about personal computing. So while Chrome OS got off to a slow start, it’s only a matter of time until Google can take advantage of this inflection point at which we find ourselves.

Creo que el elemento determinante entre los argumentos, es la futura confluencia de Android y Chrome, facilitando un enfoque de la informática absolutamente ubicua, dado el uso de Android en toda clase (y aumentando) de aparatos de la vida diaria o la industria. Su introducción en el mundo multimedia hogareño es sólo el principio.
Windows 8 sin duda es una salida a hacer frente esta perspectiva próxima, con la gran desventaja de que el factor movilizador de este cambio de paradigma ha estado en telefonos inteligentes y tabletas. Y este es un mundo donde Microsoft está prácticamente ausente.

¿Windows 8 en el filo de una navaja?

Por primera vez, leo en un comentarista la posibilidad de que Windows 8 pudiera convertirse en una falla catastrófica de Microsoft. En realidad, una relectura de la gran cantidad de información publicada en los últimos días muestra signos no muy tranquilizadores. El más reciente, la campaña algo acuciante en busca de desarrolladores y empresas que soporten Metro y Windows Phone 7 y 8, en sus aplicaciones y lenguajes, y la continuada ratificación de la limitación o extinción de soporte de .NET y Silverlight, respectivamente. Por largo tiempo, se percibía que la irrupción masiva de dispositivos móviles representaba una amenaza cierta a la hegemonía de mercado de Microsoft. Si Metro era la respuesta de la empresa a este desafío, hoy da la impresión de que pudiera ser un fiasco mayor, que comprometa su posición en todos los frentes. Pareciera que fue lanzado sin abrir suficientemente su arquitectura a proveedores y socios de negocios, de tal forma que hoy pudiera no contar con suficientemente respaldo de quienes deberían soportarlo. Así sucede aparentemente en el mercado de ARM. Dice Patrick Moorhead en Forbes:

As we head toward the availability of Windows 8 in Q4, the amount of information available about X86-based platforms dwarfs that of ARM-based platforms from NVIDIA, Qualcomm, and Texas Instruments.  One example is the Consumer Preview (CP).  The Windows 8 CP on X86 (Intel/AMD) was and still is openly available for any consumer on the planet to try, without exaggeration.  In contrast, there’s Windows 8 on ARM (WOA) where, without an NDA, no one can even touch a system.  There can be a few reasons for that, including secrecy, the unique ARM software images required, it just isn’t ready yet, or a combination of all.  With approximately six months until launch, is Microsoft ready for Windows 8 on ARM? (...) Microsoft has written a lot about this on their Building Windows 8 blog, but the questions still remain on specificity.  Specifically which hardware peripherals work well, which ones work but without all features and which ones just don’t work.  This means USB printers, webcams, scanners, digital cameras, SD-cards, game controllers, displays, headsets, speakers, etc.  Sure, drivers are being written now and will be updated well after launch, but without anything definitive, what are OEMs and channel partners to plan?  The channel needs to prepare appropriately with the right peripherals that are compatible with WOA systems. (...) We’re six months from launch and channel partners and OEMs should know this already to prepare for the holidays.

Más aún, está claro que Windows 8 no será compatible hacia atrás para ARM: <<For some it may be an obvious thing to state, but Windows 8 on ARM will be a completely blank canvas with no compatibility mode for any software running on previous x86 versions of Windows. If a developer wants an older app to run on Windows 8 ARM, they need to develop a new version specifically for the platform>>
Mary Jo Folley escribe el 3 de abril acerca de la llamada de Microsoft a escribir aplicaciones y adaptar lenguajes a WinRT, destacando que <<Microsoft officials have been encouraging developers to consider HTML5/JavaScript and C++ when writing new Metro-style apps. However, as Development and Platform Evangelist (DPE) Jerry Nixon recently noted, it’s the managed languages and .Net that seem to be where most of the Windows 8 developer interest is — at least when measured in terms of developer questions and comments on the MSDN forums (...) I guess it shouldn’t be too surprising, however, that devs prefer using what they already know>>. La propia comunidad de desarrolladores de Microsoft se encuentra desorientada, y probablemente defraudada, sometida a un cambio no esperado, y sometida a la presión de la obsolescencia de todo su desarrollo previo.
 En fin, estos son algunos elementos de los últimos días que marchan en una dirección concurrente. Bajo estos antecedentes, Adrian Kingsley-Hughes, agrega el problema del hardware, para componer un escenario más que complicado para Microsoft:

ZDNet’s Mary Jo Foley wonders when are we going to start seeing ‘reimagined’ hardware that will make using the touch-centric Windows 8 less painful and more compelling.

“The problem is,” writes Foley, “without these next-gen PCs and tablets, it’s hard for me - and I’d think others, too - to really grok how Windows 8 is going to work from running it on PCs and tablets that were designed for a non-touch-centric operating system like Windows 7.”

Yeah, that is a bit of a problem. Especially given that we’re probably six months or so away from Windows 8 being released. So, where is all this cool new hardware?

Don’t hold your breath for it just yet.
We can be certain of one thing. There will be Windows 8-specific hardware, in the form of tablets, ultrabooks and touch-enabled PCs, available at the launch of the operating system. The problem isn’t going to be the availability of hardware, but the price point of the hardware.
Touch adds dollars to a system — especially to the price of a PC, where the market hit rock bottom a long time ago — and it is adding cost at a time when both consumer and enterprise buyers are most sensitive to price. To make matters worse, OEMs currently have no idea how the mass market will react to Windows 8. It could flop like Vista, in which case demand for touch-enabled hardware is going to be very soggy and OEMs will be left struggling to offload hardware. Alternatively, it could be a runaway success like Windows 7 was, in which case it will be harvest time for the OEMs.
Problem is, failure is still very much an option, and the idea of Windows 8 being a catastrophic failure is a massive turn-off for hardware makers; doubly so when they are expected to pour significant capital into design, development and production of Windows 8-specific systems. Failures of devices such as Motorola’s Xoom and RIM’s PlayBook are still on the minds of all OEMs.
Another problem is the incumbent desktop and notebook PC. While Microsoft is undoubtedly embracing touch computing with both hands, we’re still not sure what the game-plan is here. Microsoft has made a lot of noises about how touch is the future because it is better and easier to use, but many others and I still remain unconvinced.
The keyboard and mouse are far too entrenched in computing to be swiped away overnight. I firmly expect that the majority of systems that will ship with Windows 8 over the new operating system’s lifespan will be traditional, non-touch systems featuring keyboards and mice, and the OEMs must also suspect this.
Then there are Windows 8 tablets. It’s here I feel that Microsoft’s new operating system will shine the brightest, but it’s still far too early to say that there’s any guarantee of success. The biggest problem facing OEMs here is that they have to deliver a product that competes favorably with the iPad when it comes to a number of metrics - form factor, weight, battery life and, probably most significant of the lot, price.
If the OEMs can’t get all their ducks in a row here, it could be a bloodbath.
Why are we not seeing some OEMs take a leap of faith now and start releasing touch-enabled hardware powered by Windows 7 in advance of Windows 8? Simple. That would be a bloodbath too. Windows 7 is an appalling choice for touch-enabled hardware. This means that OEMs don’t really have the option of shipping touch-enabled hardware now with the promise of a free upgrade down the line to Windows 8.
Windows 8 will reimagine hardware, just not that much. There will be touch-enabled systems available, but they will command a premium price and appeal to a niche market. The traditional desktop and notebook will continue to be the main platform for Windows 8. There will also be Windows 8-powered tablets, but it remains to be seen just how well these will stack up against the iPad.
Uncertain times lay ahead for the OEMs.

 En estas condiciones, consultoras y empresas planeando su estrategia futura, deberían ser muy prudentes en sus movimientos.

Windows Metro y sus clientes corporativos

Acabo de ver una presentación sobre la evolución del mercado de aplicaciones móviles, que muestra una tendencia abrumadoramente inclinada hacia el crecimiento de la venta de recursos móviles (tablets y teléfonos) en perjuicio de un mercado estancado de computadores de escritorio. Ninguna novedad, así como tampoco lo es que el contenido de las aplicaciones varía radicalmente del que poblaba los PCs de escritorio. Se trata de una verdadera explosión del alcance de las aplicaciones, que escalan al uso diario de cientos o miles de millones de personas. El hecho es que la computación corporativa o de negocios pasa a ser una fracción relativamente estable del mercado total, y, comparativamente, con un crecimiento mucho menor que el resto. Esta es, a mi juicio, la razón que explica el estilo del nuevo Windows 8: salir a luchar por una porción dominante en el mercado de móviles. ¿Estará a tiempo todavía, o estará condenado a compartir una porción dividida con la competencia ya suficientemente establecida? ¿Podría haber sido más adecuado, a partir de un núcleo común, desarrollar dos líneas de producto que respetaran las diferencias de estos dos mundos?
El problema está en el universo corporativo: ¿contempla Windows 8 genuinamente este mercado? Por ahora, por lo que veo, no: Fundamentalmente, lo único que se ha destinado a este mundo es Win32, al que se ha declarado obsoleto. Todas las herramientas y lenguajes disponibles apuntan a soportar lo nuevo, básicamente pensado para dispositivos móviles, poco aptos para el trabajo de escritorio. Ni siquiera, al menos por ahora, es posible arrancar una estación Win 8 en modo "tradicional": usted debe iniciar en Metro, y luego cambiar manualmente de modo: se avecina una pesadilla para todos los administradores de servicios de escritorio que tengan scripts de inicio de sistema...Microsoft desprecia las grandes diferencias que existen entre una estación de trabajo y un aparato de comunicación móvil.
¿Será esta la versión final corporativa? Creo que todavía habrá importantes cambios, y, quizá veamos todavía, en "el Service Pack 2", algo más próximo a lo que este mercado requiere. Entretanto, haga sus cálculos financieros para solventar el cambio, o estaciónese en Windows 7.
Mary-Jo Foley comentaba hace poco lo incómodo del nuevo panorama:

While many love the tiled Metro start screen and are looking forward to using it on touch tablets and PCs, many others aren’t keen on it — especially business users who are convinced that Metro will be nothing but a nuisance, especially on non-touch-enabled hardware, and that they’ll do most of their work in the Desktop app on Windows 8.
Paul Thurrott of Windows SuperSite told me a while back that he believed Microsoft would allow users to get around Metro using a group-policy setting, but when I ran that past my contacts at Microsoft, I was told this would likely not be the case. So in the end, it looks like So who knows at this point whether business users who don’t want Metro may get their wish, after all.
(...)
The other big looming question that many business users want more information about is what they will and won’t be able to do when it comes to managing their Windows 8 on ARM (WOA) tablets and PCs.
Microsoft posted a document for download on February 29 (not sure if intentionally or not) that outlined Consumer Preview features for business users. In that document, Microsoft corroborated word that WOA tablets won’t be able to join an Active Directory domain. Some sites have reported that the document also said that Microsoft wouldn’t allow WOA tablets to be managed at all using Microsoft’s own management tools.
(...)
Charles Fitzgerald, a former Microsoft exec now working at VMWare, noted that the domain join limitation means Microsoft won’t be able to one-up the iPad on this front. (And lack of manageability was one of the themes that Microsoft has advised its salesforce to use in selling agains the iPad in businesses.) From Fitzgerald’s March 1 post:

Lack of domain join “means Windows 8 ARM tablets are going to be consumer devices that don’t integrate with the Microsoft enterprise infrastructure any better than the iPad, so Microsoft loses what should have been a major selling point. You will have to sacrifice battery life and go with x86 to get enterprise features and manageability. This is a big blow to Microsoft’s tablet proposition for the enterprise and WOA may be DOA as a result.

Foley todavía dejaba lugar en su comentario a las novedades que la participación de Microsoft en CeBIT pudiera tener para mejorar este panorama. Hasta donde se puede ver, no ha habido cambios notables.

Java y Metro/WinRT

Windows 8, en su versión orientada a futuro, es Metro/WinRT. Francamente, no sé si Metro será un nuevo Vista, condenado a ser cambiado a una nueva versión tras ser descartado masivamente; sin embargo, creo que está claro que este será el nuevo sistema operativo de Microsoft, con mayores o menores parches o variaciones, después de un mayor o menor paso de tiempo. Y también está claro que el API de Win32 tiene sus años contados, que será considerado "legacy", y que no se deben esperar mejoras futuras sobre él. En estas condiciones, que creo que son irreversibles desde el punto de vista de Microsoft, WinRT debe ser considerado como el futuro del mercado Windows dependiente.
Si esta premisa es cierta, la pregunta siguiente es acerca del universo de productos, lenguajes o herramientas construídas sobre y para esta plataforma: seguramente, algunas que ya hoy han quedado obsoletas, o cambiarán radicalmente, o deberán repensar una tecnología que las suplante, como sería el caso de Flash. Otras, las más, enfrentan un camino complicado. Particularmente, en este momento pienso en Java; no sé si tendrá sentido crear una máquina virtual pensando en Metro como interfaz de usuario (tiles, pantalla táctil), que pudiera quedar a futuro como algo más asociado al usuario final, a tablets, a dispositivos móviles en general. Pero seguramente sí debe comprobarse que una máquina virtual puede ejecutarse sobre WinRT. No he visto todavía ningún pronunciamiento de Oracle ni de otros responsables del estándar, y probablemente pase algún tiempo antes de que haya alguno; habrá problemas de políticas (qué excelente momento para cerrar Windows a la competencia...), antes de resolver cómo enlazar la máquina virtual. por ahora, solo es posible encontrar algunos sencillos intentos de ejecutar java, algunos logrados, pero doy por entendido que estos casos lo han hecho sobre el escritorio (Win32). La siguiente es una pequeña lista de  casos en este sentido:
Ejecutando Java en DOS, claramente sobre Win32,
Lo mismo, en una edición temprana.
Un intento de  instalar Eclipse.
Un intento algo inadvertido, quizá sobre Metro, pero que cae hacia Win32.
Un intento con muchos problemas.

Sin embargo, lo más sustancioso está en otros casos tempranos enfocando Metro/WinRt. Particularmente uno en Google Groups (The Java Posse), discutiendo los problemas de arquitectura (aunque para nada hay que despreciar otro argumento discutido allí: "The real reason is Microsoft pathetically trying to exclude competitors and competing technologies, trying to impose HTML5 for everything"):

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in  Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough  for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the applet tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if applet [tag] works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the [object] tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode? What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on [object], I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too? Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much
closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8. 

Otra interesante apertura es la expuesta en Iced in code:

The big question now is where does JavaSE fit in all this bold re-imagining? Oracle/Sun have done a great deal of work over the past few years to get Java to work pretty well on Windows and become as natively integrated as possible, but with the re-working of Windows, Java will be confined to the “legacy” application section for the time being, and will not be able to play with the new cool kids in the “Metroverse”. I wonder what steps Oracle  is going to take to make Java still a viable product in the new Windows 8 platform, or will they simple give up and require us all to move to platform specific programming again, like C#?

y alguna acotación de lectores:

First, Oracle should under all circumstances make Java SE compatible with the new platforms like tables, macbooks and metro to keep their concept intact – OR – find a way to easily let Java SE applications run as “apps-likes” under another Java distribution made specificly to these platforms.
Second, Metro is nothing more (or less) than a simple “start-web-page”. Windows 8 is very similar to Windows 7, with program and filesystem seperated – where android and apple are more likely to melt these two things together. Therefore I doesn’t like andorid and apple as their operationsystem are defining the limitations. Some people would call that user-friendliness, I partially agree with that.
I believe that Windows 8 Metro will be an extension to their current desktop on traditional computers, but not a future replacement making the desktop legacy – and we won’t see anything like this within the next 10 years. But Windows 8 Metro will be the beginning of web and computers melting together – and this will eventually make the desktop computer look more like a tablet – and a tablet will look more like a desktop computer – and that will happen!

Uno de los casos que chocaron con WinRT.
Una discusión que refiere a Intel y ARM.

En fin, faltando una respuesta oficial de Oracle, comienza a abrirse el juego. ¿Va usted sopesando el impacto de Windows 8 en sus inversiones en licencias, plataformas, aplicaciones?