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.

Less well understood is that development can never stop. The code is never good enough. That's not a scope-creep programmer talking; that's just the honest truth. Our needs will always outrace our ability to meet them, so we must always be innovating. Any "agile" methodology that fails to recognize this - or even scoffs at it, creating a default condition of stasis rather than evolution - is not agile at all. Agility is in part about speed of production, about giving our software lifecycle a fighting chance to address our continuously changing needs by continuously working to meet them. This means we cannot afford to stop development, not even during testing, verification, or packaging up a release for distribution.

The resolution to this paradox is that we split our efforts into parallel paths. Whenever work on the current version or current patch reaches the crossover point where its innovation has to be bent toward satisfying testing and verification so it can be stabilized and distributed, a new version or patch must be started in parallel to carry the torch of agile innovation forward.

That's happening right now, as MSC Fileman 22.2 nears distribution. As I finish the code cleanup and begin packaging it, bending the work toward stabilization, the need for Fileman innovation is no less pressing, so we are simultaneously starting work on our first two patches.

The first patch, which under the new OSEHRA VISTA numberspacing will be known as DI*22.2*10001, resulted from the cleanup of the first lines of all Fileman's routines I wrote about previously. I replaced the dozen nonstandard formats for dates and times - half of which Fileman's own date/time validation tools could not understand - with a single standard format for dates and times, ISO 8601, the only right choice of standards here, since it's the dominant international standard and is used in the Internet for all modern systems. Ironically, Fileman does not yet support most of the ISO 8601 formats - particularly those containing times - so we need to upgrade Fileman's date/time tools to do so. The development work is being done by Murat Khemesh and the FLAP Jordan team in Amman.

The second patch, DI*22.2*10002, will include changes to Fileman subroutines identified by Afsin Ustundag in his analysis for OSEHRA's ongoing Code Alignment Phase One, in which he identified numerous subroutines across VISTA that include a mix of argumented and argumentless quits, suggesting confusion about how those subroutines are called (except for error processing, a given subroutine should only be called one way, and its quits have to match the way it is called). A few of the routines he identified were in Fileman, so we're cleaning those up to quit cleanly and consistently. The development work was done by George Timson.

I have little doubt that more MSC Fileman 22.2 patches will be launched during the next couple weeks. As they are, and as these two progress through the patch-development process, I'll write about them and their progress here, starting with upcoming posts about each of these first two patches.

like0

Comments

MSC Fileman 22.2 Patches

George Timson's picture

Rick, you say
> (except for error processing, a given subroutine should only be called
> one way, and its quits have to match the way it is called)
I am not sure that is true. Note the definition of the special variable
$Q in the 1995 Standard:
$Quit returns 1 if the current PROCESS-STACK frame was invoked by an
exfunc or exvar, and therefore a Quit would require an argument.
Otherwise, $Quit returns 0 (zero). When a process is initiated, but
before any commands are processed, the value of $Quit is 0 (zero).
This wording implies to me that the subroutine could find out 'how it is
called' by examining $Q, and I am sure that somewhere (but not in
FileMan) I have seen that done.

Speaking of 'standard', I would be glad to see, ASAP, your patch
DI*22.2*10001, replacing "the dozen nonstandard formats for dates and
times".

Thanks,

--George

On 2/5/2015 8:01 AM, toad wrote:
>
> 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.
>
> Less well understood is that development can never stop. The code is
> never good enough. That's not a scope-creep programmer talking; that's
> just the honest truth. Our needs will always outrace our ability to
> meet them, so we must always be innovating. Any "agile" methodology
> that fails to recognize this - or even scoffs at it, creating a
> default condition of stasis rather than evolution - is not agile at
> all. Agility is in part about speed of production, about giving our
> software lifecycle a fighting chance to address our continuously
> changing needs by continuously working to meet them. This means we
> cannot afford to stop development, not even during testing,
> verification, or packaging up a release for distribution.
>
> The resolution to this paradox is that we split our efforts into
> parallel paths. Whenever work on the current version or current patch
> reaches the crossover point where its innovation has to be bent toward
> satisfying testing and verification so it can be stabilized and
> distributed, a new version or patch must be started in parallel to
> carry the torch of agile innovation forward.
>
> That's happening right now, as MSC Fileman 22.2 nears distribution. As
> I finish the code cleanup and begin packaging it, bending the work
> toward stabilization, the need for Fileman innovation is no less
> pressing, so we are simultaneously starting work on our first two patches.
>
> The first patch, which under the new OSEHRA VISTA numberspacing will
> be known as DI*22.2*10001, resulted from the cleanup of the first
> lines of all Fileman's routines I wrote about previously. I replaced
> the dozen nonstandard formats for dates and times - half of which
> Fileman's own date/time validation tools could not understand - with a
> single standard format for dates and times, ISO 8601, the only right
> choice of standards here, since it's the dominant international
> standard and is used in the Internet for all modern systems.
> Ironically, Fileman does not yet support most of the ISO 8601 formats
> - particularly those containing times - so we need to upgrade
> Fileman's date/time tools to do so. The development work is being done
> by Murat Khemesh and the FLAP Jordan team in Amman.
>
> The second patch, DI*22.2*10002, will include changes to Fileman
> subroutines identified by Afsin Ustundag in his analysis for OSEHRA's
> ongoing Code Alignment Phase One, in which he identified numerous
> subroutines across VISTA that include a mix of argumented and
> argumentless quits, suggesting confusion about how those subroutines
> are called (except for error processing, a given subroutine should
> only be called one way, and its quits have to match the way it is
> called). A few of the routines he identified were in Fileman, so we're
> cleaning those up to quit cleanly and consistently. The development
> work was done by George Timson.
>
> I have little doubt that more MSC Fileman 22.2 patches will be
> launched during the next couple weeks. As they are, and as these two
> progress through the patch-development process, I'll write about them
> and their progress here, starting with upcoming posts about each of
> these first two patches.
>
> --
> Full post: http://www.osehra.org/blog/msc-fileman-222-patches
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/4732

like0

$Quit

Rick Marshall's picture

George, you're right of course about $quit. A MUMPS subroutine can find out how it was called and issue the right quit, if it wants to support multiple calling forms. Although this can be used generally, its intended use is to support error processing, since an error handler invoked by the trap could be called from a function or a procedure, and has to be able to determine which to issue the right quit.

For everyday applications, though, $quit is considerably less useful, since we generally prefer simpler architecture in which each subroutine is either a procedure or a function but not both.

like0

Nonstandard Dates & Times

Rick Marshall's picture

The changes to all of Fileman's routines to standardize their first lines - including replacing the variously formatted timestamps used on those first lines, will be included in the main MSC Fileman 22.2 release, since it was part of the cleanup I've done over the past few weeks in preparation for bundling and distributing MSC Fileman 22.2.

DI*22.2*10001 won't take away any of ^%DT's wonderful existing functionality, just add the ISO 8601 formats to the range of choices it offers. My next blog post will go into detail about it.  :)

like0

MSC Fileman 22.2 Patches

Ignacio Valdes's picture

Any UTF-8 work? -- IV

On Thu, Feb 5, 2015 at 10:57 AM, toad <rick.marshall@vistaexpertise.net>
wrote:

> The changes to all of Fileman's routines to standardize their first lines
> - including replacing the variously formatted timestamps used on those
> first lines, will be included in the main MSC Fileman 22.2 release, since
> it was part of the cleanup I've done over the past few weeks in preparation
> for bundling and distributing MSC Fileman 22.2.
>
> DI*22.2*10001 won't take away any of ^%DT's wonderful existing
> functionality, just add the ISO 8601 formats to the range of choices it
> offers. My next blog post will go into detail about it. :)
> --
> Full post: http://www.osehra.org/blog/msc-fileman-222-patches
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/4732
>

like0

UTF-8

Rick Marshall's picture

UTF-8 will be part of the next version, MSC Fileman 22.3, which we'll begin work on soon, VA willing.

like0