Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!plus5!rhg%regina
From: rhg%regina@plus5.UUCP
Newsgroups: mod.std.mumps
Subject: your newsletter comments
Message-ID: <896@plus5.UUCP>
Date: Fri, 4-Oct-85 13:41:34 EDT
Article-I.D.: plus5.896
Posted: Fri Oct  4 13:41:34 1985
Date-Received: Sat, 5-Oct-85 06:51:18 EDT
Sender: hokey@plus5.UUCP
Reply-To: sask!regina!rhg (Robert Greenfield)
Organization: Plus Five Computer Services, St. Louis
Lines: 45
Approved: hokey@plus5.uucp

hokey,
	regarding the several ideas that you proposed recently:
	1)  x3.64 is now widely recognized as a starting point, 
but it does not solve all of our problems.  this is shown by the 
wide introduction of 'code extentions' such as NAPLPS and Teletex.
	2)  internally, i.e. the storage problem, there are no
differences between x3.4 1968 and x3.4 1977 and ISO 646, nor the
various other national standards such as the French, German,
Swedish, etc.  the differences come up in the graphic rendition
of these codes which depend (mostly) on the i/o devices
themselves.  i say 'mostly' because of the recent trends toward
dowloadable fonts, looks, etc.  thus i see no need, whatsoever
for a $characterset special variable, because it has no meaning.
	3)  the issue of collating outside of the 7-bit ascii
set has been introduced into fortran 77.  prior fortrans have
depended upon the native collating sequence of the machine, i.e.
a non-standard collating sequence was built into the fortran
language.  now fortran 77 requires the addition of ascii
collating sequence relational operators IN ADDITION to whatever
normal, usual, non-standard operators are built into the
language.  e.g.
	normal fortran   x.lt.y where both x and y are character
strings.  answer depends on 'native' collating sequence.
	required ascii   llt(x,y) where both x and y are
character strings.  answer depends on ascii collating sequence.
	the above semantics are correct, there may be minor
syntactic and naming errors since i didn't look up the exact
function names.
	cobol has also added a mechanism to employ various
collating schemes as an option.  this too is a trend away from
native collating sequences.
	i am not sure that it is a good idea to move mumps away
from the ascii collating sequence (which is one of the long
standing strengths of the language) toward various non-standard
native sequences such as EBCDIC.  this is especially true when
other standardized languages are now finally moving toward ascii
standardization and away from native sets.
	respectfully, bob
PS:	WITHIN SEVERAL DAYS I CAN ALSO BE REACHED ON AN IBM MACHINE
ON BITNET - RHG at UREGINA1   .  AFTER A LONGER PERIOD OUR UNIX
MACHINE (THIS ONE - regina) WILL PROBABLY ALSO HAVE A BITNET CONNECTION.
THE USE OF BITNET WILL LOWER OUR COSTS AND WILL GREATLY SPEED MESSAGES
ALONG SINCE IT EMPLOYS LEASED LINE SERVICE.  YOU MAY WISH TO CONSIDER
LINKAGES TO THE WASH U IBM MAINFRAMES TO GAIN THIS ADVANTAGE FOR
YOURSELVES TOO.


Brought to you by Super Global Mega Corp .com