GT.M is MUMPS. The biggest difference from other MUMPS in my view is that it attempts to fit in more natively with its host operating system and doesn't try to pretend that it is a complete programming environment of itself, as MUMPS generally was 20-30 years ago.
After configuration, you could use GT.M almost exclusively in a familiar MUMPS-is-everything kind of mode, but why would you? That would ignore most of the power and capabilities of a modern operating system like Linux - and all of the wonderful tools developed for and in other languages. Greg Kreis wrote: >Thanks for the run down. I am creating the acculturation CD that >bhaskar recommended. Sounds like quite a different culture to adopt. >Must have been fun to map the Kernel to this platform.... ;-) ;-) > >Jim Self wrote: > >>Greg Kreis wrote: >> >> >>>I can understand that the Volume concept is handled by the idea of a >>>path in Linux, right?] >>> >>> >> >>It's been more than 20 years since I worked on DSM, so their concept of UCI >>(User Class >>Identifier) and volume sets is not very fresh in my mind. Still, I am pretty >>sure the >>answer is no. >> >> >> >>>Hmm... Are the globals just Linux files? >>> >>> >> >>No, again. Globals are stored in special data files with .dat extention. The >>default >>installations put all globals into a single mumps.dat file but in production >>systems you >>would generally break out large globals into separate files, like >>patients.dat and >>mail.dat, or groups several related medium sized globals together in one >>file. The >>different .dat files can have different ownership and permissions settings >>and different >>settings for journalling as well so some could be configured read only for >>most users or >>optimized for use as temporary scratch space, etc. >> >> >> >>>If so, >>>wouldn't the directory take the place of the UCI? >>> >>> >> >>A globals directory is actually a special file (mumps.gld, by default) that >>describes a >>set of .dat files and how globals will be mapped to them. >> >> >> >>>But I guess the next >>>question is how is this exposed inside GT.M? >>> >>> >> >>The current global directory is held in the variable $zgbldir and the current >>routine >>mapping is in $zroutines. You can NEW these variables and SET them to >>different values to >>temporarily reference a different mapping of globals and/or routines. They >>are initialized >>with the environment variables gtmgbldir and gtmroutines. >> >>I think I recall that you can also reference a global directory explicitly >>via extended >>global syntax (i.e. ^[gbldir]gloname), but I haven't had occasion to use that >>in a very >>long time. --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
