Manage 2000 on LINUX Anyone?

The Manage 2000 8.1 sp5 cutoff went off on scheduler last Friday.  Now Lane has doffed his Release Control hat, and I am setting up work space for Manage 2000 8.1 service pack 6 development.

In other news... "Support for HPE's Itanium-powered Integrity servers, and HP-UX 11i v3, will come to an end on December 31, 2025".  So what does that mean for the 20 or so Manage 2000 sites running on HP?

Well, we on the Manage 2000 development team have taken notice.  Lane has Manage 2000 8.1 sp4 running on a LINUX RHE machine and the rest of us are banging away on it.  VSI-Fax is one of our last major hurdles to supporting Manage 2000 on LINUX.  Esker will not support the traditional local Vsi-Fax install on RHE 8.  That pretty much strands Manage 2000 FXJ capabilities.   I will be trying to build a bridge to the Esker 'On-Demand' web service API.  And Bud is looking into another option hosting Vsi-Fax on Windows and accessing the database from a LINUX machine. One way or another we'll get there.

RHE is the Red Hat Enterprise flavor of LINUX.  It has the chops to become the foundation for larger Manage 2000 sites going forward.  I am expecting this to be mostly Itanium sites needing to move to a supported platform by the end of 2025.  But, I will not be surprised if some larger Windows Server sites eye the LINUX option favorably, if for no other reason than 85% of ransomware attacks still target Windows systems.  

Yep, just gets interesting-er and interesting-er.

NetBasic Where No One Has Gone Before, MV.Net on SQL Server?

There have been numerous expeditions over the years connecting and leveraging the Microsoft .Net world with the Multi Value world: BlueFinity, NovoMotion, various ETL products.  But none so bold as the ProsolGrp NetBasic expedition.

Grant Hart and Allan Williams brought NetBasic to the recent NovoRoiSystems User Group Meeting to share what they have been working on.

NetBasic is on another plane from other .Net <-> Multi-Value technologies. It is the .Net SQL Server whale swallowing up the Multi-Value Jonah. And Multi-Value Jonah is living quite comfortably inside the SQLServer beast.

By creating a managed code Multi-Value runtime with serialization kept non-normalized in a single SQL table cell, NetBasic keeps all the benefits of Multi-Value while taking on all the benefits of the SQL Server environment and .NET.

From within the runtime the user is in a Multi Value environment. From outside the runtime the user is in a SQL .Net environment.  Yes, it is a TARDIS.









To be useful from other SQL client technologies normalizing views make the underlying dynamic arrays appear as normalized tables.  This allows the runtime online transaction processing to avoid normalization overhead while keeping the consumers of the data happily fed with flat tables.

NetBasic code gets converted to C# and then to a managed assembly. Multi Value indexing is implemented as SQL indexing. Dynamic array records are stored whole on top of the SQL Table structure as a single cell.

The underlying structure of the dynamic array records can evolve and SQL Server does not care one whit, providing continuous support for changing and growing business applications. The Multi Value OLTP code runs merrily along avoiding all the joining and normalizing overhead.  Only the normalizing views for SQL OLAP clients need regenerating after structural changes in the MV database.

IT can manage, backup, and replicate your Multi-Value database as just another SQL DB instance.

Application development can use the full range of MV and .NET development languages.

Users can continue to productively employ the MV application business rules that guide them in tracking your business. And management can employ SSRS and other SQL based management tools essential to decision making in today's world.

In Defense of the Multi-Value Database

Reading Andrew E. Wade's chapter "Business Objects in Object Databases" of Andrew Carmichael's anthology of OO practitioners "Developing Business Objects" from 1997 I am struck by the parallels between the advantages of Object Oriented databases and Multi-Value databases over RDBMS for complex business modeling such as ERP systems.

RDBMSs provide a simple, flat, tabular view of all information. The user must map his application data structures, whatever they might be, into those tables. Other traditional database systems require similar mapping down to simple, flat records. The user must work at the level of only the table data structure and only a small set of simple operations (select,project,join). Now, if the application data structures is naturally simple and flat, and the application operations are also simple, this mapping is straightforward and not an issue. On the other hand, when the application structures and operations become complex, the RDMBS approach forces the user to deal with this directly. An ODBMS offers the ability to model an application in terms of objects, which may have any user-defined structure and any user-defined operations. Applications that require nested structures, dynamically varying sized structures, many-to-many relationships, and complex operations can map these directly to objects. Not only is the support far more efficient, far faster at run time, but the user may work at higher levels of abstraction. Instead of translating the application down to records and tuples with joins, the user can work directly with objects such as customers or manufacturing processes, and the natural, application-defined operations on these. The result is easier and faster for the developer and the end user. ...

When to Use an ODMS

... Second, if the application's information is complex and interconnected, an ODBMS can provide much better performance and ease of use. To contrast, if the information being modeled consists of simple, flat, fixed-length field, that fit nicely into tables, an RDMBS can be a fine fit. On the other hand, if the information contains complex structure, nested structures, dynamically varying sized structures, including images, audio, and video, all these can be represented directly as objects. Saving the need to translate not only eases the developer's load, but also eliminates the need to translate at run time, making it faster. To some users, the interconnections in their information model are even more important. In an RDBMS, such relationships are represented by creating secondary data structures, foreign keys. At run time, the system searches down two tables, comparing key values, until it discovers two that match.This search-and -compare process is called a join, an it's the weak point of relational technology. Even with the help of indices, it's slow, and the bigger the database, the slower it gets. In an ODBMS, there is no need to create and manage secondary data structures... Referential integrity, a difficult issue in traditional database systems, comes along automatically and easily. Moreover, the traversal is direct, with no need to search or compare, resulting in performance that is orders of magnitude faster. The more relationships, the more the application will benefit from an ODMBS.

Although to my way of thinking the most critical advantage of Multi-Value databases is their elasticity. They accomodate change. And change is the greatest challenge to software development and software field operations. One example of this is the ability to add domain specific vocabulary to a database in the field. The I-Descriptor feature in file dictionaries allows one (among other things) to describe how the system should retrieve a single foreign field. This is, effectively, a class definition for a field level join. Once defined the foreign sourced field may be used as if it were local for query and record selection purposes. Some users shy away from creating new custom dictionaries, but I see this as teaching the database how to be more useful to the users, how to be more functional in the users natural business vocabulary. Some argue that Multi-Value is dead. I hear this mostly in context of sales and marketing. But the absolute dominance of the healthcare sector by Intersystem's Cache and its predecessor MUMPS would seem to contradict this assertion. Critics will point out that Cache is not Multi-Value, but it most certainly is NOT first normal! In fact, one can argue that the Multi-Value database design is a subset of Cache's architecture. I would argue that the default Multi-Value Telnet based UI is the major problem for sales and marketing. Cache supports HTML as an immediate client protocol. This has been a conspicuously missing piece in U2 and other Multi-Value vendors offerings. While there are many ways to mix-in HTML client protocols such as UO, RBO, BlueFinity, or developing your own data components as we did on the Manage 2000 team, these all introduce tons of extra complexity. On most Multi-Value platforms there is no native MV Basic way to simply and directly code HTML UI's.

Through the Looking Glass

Well I am getting ready for move number 3 since EPICOR bought out ROI Systems. Friday I pack up my cubicle for relocation to the 11th floor. Somehow the square footage of cubible allocated per programmer continues to dwindle. I am hoping the accountants are not shooting for equilibrium based on square foot costs in Monterey. On the upside the hallways are very wide and luxurious!

As I reflect on email queries from client web programmers obviously schooled in SQL and not so familiar with the Unidata world or the Manage 2000 toolset, it is clear to me that the REPORT.BUILD interpreter and the roiHyperQuery control offer extremely cheap efficient options for exposing ERP data out to the world. Only it is difficult to help them 'see' it. The expectation that knowing sqlCommand is enough is too stultifying. Is it worth learning another layer beyond Microsoft technology? When that layer provides CrossRef and Function Security and F1 help and edit patterns and defaults maintainable in dictionaries on the application server, and dictionary driven queries, and interactive UI screens based on REPORT.BUILD prompt definitions, the answer to me is clearly yes. But you have to expect to spend some time coming up to speed. There is a lot of tooling knowledge to learn.