Fileman

Back in the Saddle

After a year of working to provide market research for VA's emerging Fileman Evolution projects - especially after OSEHRA's December sprint to upgrade MSC Fileman 22.2 in support of VA's test-plan contract with Leidos, and the January VISTA Community Meeting in Sacramento - my health finally collapsed for six weeks of February and March. I returned to the office just in time to watch VA's next Fileman 22.2E testing contract sail over the plate before I could respond to it, much to my dismay and disappointment.

MSC Fileman 22.2 Patches

One of the characteristics of the final stage of packaging a new version for a VISTA application is that we must paradoxically freeze development without freezing development.

We must freeze development because the distribution sent to the world has to be a specific, tested version of the software. Getting to that point requires constraining development toward satisfying the results of testing, not introducing new disruption late in the packaging process, when there won't be sufficient time to test it. In this pro-testing era, most people get this issue pretty well.

FLAP and Fileman's Architectural Role

To say that File Manager is VISTA's database management system is a gross understatement, so gross that it is more misleading than helpful.

Traditional database systems run side by side with the applications, offering data-related services (like creating, reading, updating, and deleting records - the services with the unattractive acronym CRUD - along with many, many other such services). In other words, most DBMSes have a peer-to-peer relationship with the applications that use them to manage their data.

FLAP and Fileman Code Convergence

One of the two top strategic goals for FLAP Phase One (which ran from October 2012 through March 2013) was code convergence, to create a shared, common Fileman codebase that all VISTA dialects could run, to maximize our ability to exchange data and software with one another, to ensure that innovations anywhere became innovations everywhere as quickly as possible, and to reduce the amount of reinventing the wheel we had to do.

The main VISTA dialects we aimed at converging for Phase One were:

1) VA VISTA

2) IHS RPMS

3) WorldVistA EHR

4) vxVistA, and

Non-routine Software Elements Part 1: Data and Definitions

Yes, but what is VISTA made of?
 
So at the MUMPS level, VISTA is made of two kinds of software elements, routines and globals. Routines are readily version-controlled and managed (in theory) using industry-standard tools, but globals are not. Globals need to be flattened and exported in some way that focuses on the database files we are storing in those globals.
 

Pages

Subscribe to RSS - Fileman