Mumpster
http://mumpster.org/

CPRS LOC
http://mumpster.org/viewtopic.php?f=26&t=338
Page 1 of 2

Author:  Laxmikanth [ Fri Mar 11, 2011 5:58 am ]
Post subject:  CPRS LOC

Hi Mumpsters,

Can anyone help me in finding out the lines of code of CPRS based modules in VistA?

There are 7 modules in VA VistA which supports CPRS.

Quick help is appreciated

Author:  whitten [ Fri Mar 11, 2011 10:06 am ]
Post subject:  Re: CPRS LOC

I don't know how many lines of code there are in CPRS,
but I know that the code is available for browsing here:

https://trac.opensourcevista.net/svn/cprs/branches/

perhaps you can use that site to determine the lines of code.

David
713-870-3834

Author:  Laxmikanth [ Tue Mar 15, 2011 4:28 am ]
Post subject:  Re: CPRS LOC

Thanks,

I have written a script to collect the Routines for each module supported by CPRS and count the lines in the given routine..

Module Name Lines of Code
Clinical Reminders 42175
Authorization/Subscription Utility 1943
Adverse Reaction Tracking 8643
Text Integration Utility 41067
Problem List 4592
Health Summary 19099
Consult/Request Tracking 15161
TOTAL 132680
AVERAGE LOC PER MODULE 18954

Going forward i would like to know the Limitations of converting this code to Java using any code converters.

whitten wrote:
I don't know how many lines of code there are in CPRS,
but I know that the code is available for browsing here:

https://trac.opensourcevista.net/svn/cprs/branches/

perhaps you can use that site to determine the lines of code.

David
713-870-3834

Author:  whitten [ Wed Mar 16, 2011 10:19 am ]
Post subject:  Re: CPRS LOC

Laxmikanth said:
> Going forward i would like to know the Limitations of converting this code to Java using any code converters.

Perhaps you could do a survey of the current state of the art and report back here.
A quick web search brought up these sites:

http://www.mumps-migration.com/

http://www.nextgov.com/nextgov/ng_20090414_9453.php

http://www.softwarerevolution.com/bluep ... open-vista

You should be aware, however, that the FileMan to Java conversion balloons the lines of code.

The ^DI simple dispatch program only has only 459 characters in it, with 153 characters of comments.

DI.m
DI ;SFISC/GFT-DIRECT ENTRY TO VA FILEMAN ;7/25/94 3:07 PM
V ;;22.0;VA FileMan;;Mar 30, 1999
;Per VHA Directive 10-93-142, this routine should not be modified.
G QQ:$G(^DI(.84,0))']""
C G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ) G ^DII
D G QQ:$G(^DI(.84,0))']"" G ^DII
P G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ)
Q G QQ:$G(^DI(.84,0))']"" S DUZ(0)="@" G ^DII
VERSION ;
S VERSION=$P($T(V),";",3),X="VA FileMan V."_VERSION Q
;
QQ ;
W $C(7),!!,"You must run ^DINIT first."
Q

When converted to Java, you get 2929 characters, including white space, and a program that doesn't really do anything more than what the MUMPS program did, but is significantly, (in my mind) harder to read and maintain. And honestly, since I happen to know this program is called from the command line at multiple entry points, the Java program isn't even an accurate mapping of the MUMPS code. It looks like you can't even call the Java code equivalent of DO P^DI . I guess this brings up the main issue I think needs to be addressed by any "language conversion" program, you need to know what the code means to be able to write an accurate translation of it, and why the programmer wrote it to be able to evaluate if the conversion actually worked. (Those who know me well know I could get on this soapbox easily, so I'll avoid distracting your post onto a discussion of code ontologies and knowledge representation)

I really would like to know what you find out, since it gives us in the MUMPS community a better handle on the capabilities of other languages and the various code transformation tools out there.

Best Wishes,
David

PS: here is the Java equivalent of the DI code:
DI.java
// Automatically generated by the JANUS Java Printer
import java.lang.*;
import java.io.*;
import java.util.*;
import tsrilib.*;
// SFISC/GFT-DIRECT ENTRY TO VA FILEMAN ;7/25/94 3:07 PM
// SFISC/GFT-DIRECT ENTRY TO VA FILEMAN ;7/25/94 3:07 PM
public class DI
{
public static String DI()
{
Mumps.Parm[] parms = new Mumps.Parm[0];
return DI(parms);
}
public static String DI(Mumps.Parm[] parms)
{
Mumps.Enter();
return Mumps.Return(DI_());
}
public static String DI_()
{
// Per VHA Directive 10-93-142, this routine should not be modified.
if (Mumps.Bool(Mumps.Not(Mumps.Follows(Mumps.Get(Mumps.VariableRef("^DI", ".84", "0")), ""))))
return QQ_1();
if (Mumps.Bool(Mumps.Not(Mumps.Follows(Mumps.Get(Mumps.VariableRef("^DI", ".84", "0")), ""))))
return QQ_1();
Mumps.ExclusiveKillBegin();
Mumps.ExclusiveKill("DTIME");
Mumps.ExclusiveKill("DUZ");
Mumps.ExclusiveKillEnd();
return DII.DII_();
}
public static String Q()
{
Mumps.Parm[] parms = new Mumps.Parm[0];
return Q(parms);
}
public static String Q(Mumps.Parm[] parms)
{
Mumps.Enter();
return Mumps.Return(Q_());
}
public static String Q_()
{
if (Mumps.Bool(Mumps.Not(Mumps.Follows(Mumps.Get(Mumps.VariableRef("^DI", ".84", "0")), ""))))
return QQ_1();
Mumps.Assign("DUZ", "0", "@");
return DII.DII_();
}
public static String VERSION()
{
Mumps.Parm[] parms = new Mumps.Parm[0];
return VERSION(parms);
}
public static String VERSION(Mumps.Parm[] parms)
{
Mumps.Enter();
return Mumps.Return(VERSION_());
}
public static String VERSION_()//
{
Mumps.Assign("VERSION", Mumps.Piece("V ;;22.0;VA FileMan;;Mar 30, 1999", ";", "3"));
Mumps.Assign("X", "VA FileMan V." + Mumps.Variable("VERSION"));
return "";
}
static String QQ_1()
{
Mumps.Write(Mumps.Char("7"));
Mumps.NewLine();
Mumps.NewLine();
Mumps.Write("You must run ^DINIT first.");
return "";
}
public static String Dispatch(String fun, Mumps.Parm[] parms)
{
if (fun.equals("DI"))
return DI(parms);
if (fun.equals("Q"))
return Q(parms);
if (fun.equals("VERSION"))
return VERSION(parms);
return Mumps.Fail("DI.Dispatch failed for ", fun);
}
public static String GoDispatch(String label)
{
if (label.equals("DI"))
return DI_();
if (label.equals("Q"))
return Q_();
if (label.equals("VERSION"))
return VERSION_();
return Mumps.Fail("DI.GoDispatch failed for ", label);
}
public static String TextDispatch(String label, String offset)
{
return Mumps.Fail("DI.TextDispatch failed for ", label);
}
}

Author:  Laxmikanth [ Thu Mar 17, 2011 9:51 pm ]
Post subject:  Re: CPRS LOC

Hey Whitten,

Thanks for your suggestion.

I have seen many sites where they say that Mumps to Java conversion is very easy and also converting the fileman and other datebase files can be done automatically ny their tools.

The code you have given contains the TSRI* library package which defines main conversion rules and techniques followed by the Janus tool ,without understanding that we cant define how mush feasible is the code conversion.
Currently iam in a process of understanding the process of conversion and also different ways of achieving it keeping in view the limitations of it.

I have gone through the all sites you have give but still looking for more to start this project of coversion.

Your ideas will definetely help me.

Author:  tlwiechmann [ Fri Mar 18, 2011 9:27 am ]
Post subject:  Re: CPRS LOC

I have a question - why??

Author:  Laxmikanth [ Sun Mar 20, 2011 11:05 pm ]
Post subject:  Re: CPRS LOC

Well Terry, we have requirement from client to change the CPRS code to any modern language other than Mumps..
tlwiechmann wrote:
I have a question - why??

Author:  tlwiechmann [ Mon Mar 21, 2011 7:25 am ]
Post subject:  Re: CPRS LOC

I've never been a VistA guru, so if I'm wrong here someone please correct me.

As I understand the general architecture, it goes something like this:

MUMPS System<->File Manager<->Kernel <--> CPRS
|<--------- Server-------------------------------------->| |<--Client--->|

Where the database side of VistA is defined through File Manager and Kernel which are nailed to the underlying MUMPS system :
and
CPRS is a client GUI written in Delphi.

Which side are you contracted to rewrite - the client or server? Your answer confuses the two.

I can certainly understand rewriting the client side in some other GUI or Web based technology - Delphi is not exactly mainstream.

However, converting the VistA (server) side to Java ... it makes no sense. The code base is completely dependent upon the underlying MUMPS language and, more importantly, database structure.

Author:  Laxmikanth [ Mon Mar 21, 2011 10:03 pm ]
Post subject:  Re: CPRS LOC

Yeah...

At first we need to convert the CPRS supported modules(7 in total) and then looking at the feasibility the entire Mumps Code including the Fileman to Java...using some automated tools as told by TSRI.

We need an much more detailed architecture view and the challenges in converting the CPRS supported modules.

tlwiechmann wrote:
I've never been a VistA guru, so if I'm wrong here someone please correct me.

As I understand the general architecture, it goes something like this:

MUMPS System<->File Manager<->Kernel <--> CPRS
|<--------- Server-------------------------------------->| |<--Client--->|

Where the database side of VistA is defined through File Manager and Kernel which are nailed to the underlying MUMPS system :
and
CPRS is a client GUI written in Delphi.

Which side are you contracted to rewrite - the client or server? Your answer confuses the two.

I can certainly understand rewriting the client side in some other GUI or Web based technology - Delphi is not exactly mainstream.

However, converting the VistA (server) side to Java ... it makes no sense. The code base is completely dependent upon the underlying MUMPS language and, more importantly, database structure.

Author:  tlwiechmann [ Tue Mar 22, 2011 5:05 am ]
Post subject:  Re: CPRS LOC

:shock: Wow!

Page 1 of 2 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/