Stella Tools, actualización

Acabo de releer el artículo que le dedicara a Stella Tools, y creo que merece una actualización. Ya lo he hecho en el propio artículo, pero, para quienes no lleguen a el directamente, va este recordatorio: George Jeffcock, su autor, ha seguido trabajando en Stella, con gran aceptación de sus usuarios. Pero, lo más importante, ha creado una entrada en la Wiki de Plex, que puede constituír un buen punto de entrada para su uso y su entendimiento. Como se ha dicho antes, Stella es uno de los mejores ejemplos publicados y aprovechables de la potencia que ofrece el API del modelo de Plex. Nuevamente,  estoy convencido de que, a partir del API del modelo, es posible extender Plex en amplios frentes.
Sobre este punto, Lee Dare ha escrito una introducción, y una descripción algo más amplia.

Un tutorial sobre OCL

Jordi Cabot acaba de publicar una presentación sobre OCL (Object Constraint Language) que constituye un excelente tutorial sobre el metalenguaje. Creo que de lo que recuerdo, es el mejor. OCL es un conocido de todos cuantos hayan trabajado con UML en MDD, apreciado y criticado...El tutorial es muy útil para quienes estén tratando de ver el alcance del desarrollo por modelos, y ayuda claramente a entender cómo se pasa de un modelo visual a un cuerpo capaz de convertirse en código.
Desde el punto de vista de Plex, se puede decir sin dudas que el OCL tiene muchos puntos de contacto con el metalenguaje (metaoperaciones) que se puede utilizar en Plex para abstraer y extender el alcance de los modelos que se describan con la herramienta. Una mirada al tutorial, en nuestro caso, también es motivadora. Para recordar la potencia de las metaoperaciones.

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.

iSeries: Con amigos como estos...

El 16 de mayo, Mel Beckman,en Iprodeveloper, publicó un artículo decretando la muerte del RPG (Is RPG Dead?), con cuestionamientos definitivos al lenguaje más básico y fundamental del iSeries, (o AS/400, o System i, o como se lo quiera llamar), que desató una larga discusión cuyos ecos continúan. Una gran parte de la discusión puede seguirse en las respuestas de lectores al propio artículo, pero tambíen en la excelente -y elegante- respuesta de Scott Klement en mismo sitio, así como en otros medios (grupos de LinkedIn, en nuestro grupo de usuarios de Plex, en IDevelop (1, 2), y en blogs,entre otros.
Un aspecto notable de este cuestionamiento del que ha sido y sigue siendo el principal lenguaje de diálogo con el iSeries, es que fue escrito en una publicación, Ipro Developer, que está enfocada en el iSeries, en la que "RPG programming" es el primer ítem del menú que encabeza la página, y que fue escrita por Mel Beckman, quien, según el pie del mismo artículo, "is the senior technical director for iPro Developer". Y más notable aún, que, habiendo pasado casi un mes, no exista ni un deslinde de responsabilidades de la publicación, ni un descargo del director técnico (senior).
La afirmación de obsolescencia del RPG resulta peor todavía en el marco de los reclamos de la comunidad de empresas y consultoras usuarias del iSeries, que se vió obligada recientemente  a publicar manifiestos y sostener su difusión  ante la inactividad del propio IBM en su defensa. Resulta incomprensible que un sistema que ha representado y representa un importante volúmen de las ventas y licencias de IBM, adoptado por miles de grandes y medianas empresas de primera línea en todo el mundo, que defiende el buen nombre de la empresa por su fiabilidad, y que no ha dejado de actualizarse nunca, sea torpedeado por quienes viven de su existencia.
Pero, para establecer una defensa en regla del iSeries, nada mejor que lo que Scott Klement responde en su defensa:

Yet, Mel even goes so far as to suggest that C (from 1972) and C++ (from 1983) are more modern languages.  Are you kidding me?!   Like RPG, I code in C every day, it's a big part of my job.  And let me tell you, C is not nearly as modern as RPG.  It's not even close. C and C++ can't even do simple string operations without you having to code manual memory allocation, bounds checking, and extra code to make sure that a simple string concatenation doesn't turn into a security hole.  Its database access routines are nowhere near as simple or advanced as RPG's.  Its date operations are awkward and clumsy by comparison to RPG.  Don't get me wrong, I like C, especially for lower-level systems coding.  But it's nowhere near as modern as RPG, nor as well suited for writing business logic.
But, maybe Mel doesn't understand that when today's authors refer to RPG, we really mean RPG IV.  We don't bother including the "IV" every time we say it, because RPG IV today's RPG, and everyone should already know that!

What Features Are Important In Business Logic?

Before we go throwing around opinions about old, legacy, etc...  maybe we should define what is important to us?  What are important features for a language that's aimed at people writing business logic?

• Business logic uses numbers heavily.   Numbers represent quantities, prices, and weights.  These are key to almost every application in the business world.  Very few languages today support numbers with true decimal-based arithmetic (as opposed to integer and floating-point which are ubiquitous).  Java supports decimals properly, but only by working through complex classes.  RPG supports decimal numbers simply and easily, because they are the default numeric data type in RPG.
• Business logic uses databases heavily.  Almost every business application is database driven, and database access is deeply integrated into the RPG language.  Native record access is simple and powerful.  Even more powerful is SQL, which is an order of magnitude simpler to code in RPG than it is in many other languages such as PHP or Java.
• Business logic uses dates frequently.  Whether you're checking when a customer's payment is overdue, managing inventory turnover, determining when an order should be shipped, or when an employee was hired, you need to work with dates in a simple and effective manner.  Today's RPG does that.  Many other languages have APIs or classes for working with dates (this includes Java, PHP, C, C++, etc) but in RPG they are built right into the language, and that makes it simpler.
• Business logic uses a ton of string manipulation.  Concatenating, scanning, or substringing character data is something I do every day in every program I write.  This is easy in many of the languages that Mel considers modern (PHP, JavaScript, Perl, Python, Ruby), but some of them make string manipulation much harder than it should be (Java, C, C++).  Today's RPG, unlike its predecessors, makes string manipulation a snap.

I've coded in more than 20 programming languages.  Some are object-oriented (such as Java, C++, and JavaScript), some are procedural (C, RPG, Pascal, Fortran), and some are a mixture of the two (such as PHP.)  But when I sit down and figure out which language is  easiest for my business logic, it's invariably RPG.