Keyboard input

Keyboard input

[Gregory M. Stelmack]

Is there any way in Ada to read single keystrokes from the keyboard? Not the
GET from TEXT_IO which requires a carriage return before sending the data, but
as soon as a key is pressed have it sent? We have a whole Ada class that would
like to know, and no one here can help figure it out. So, I ask the net.
We've checked books and can't figure it out.

This is for a Data Structures class where we want to write our own I/O
routines to validate data. But to do what we want to do, we need keys as soon
as they are hit.

There should be an easy way to do it, but we can't find it. Any ideas? E-mail
if its simple so this group doesn't get cluttered due to my ignorance...

Thanks, 
-- Greg Stelmack
-- Email: stelmack@sol.csee.usf.edu
-- USmail: USF Box 1510, Tampa, FL 33620-1510
-- Amiga: the only way to compute!

Re: Keyboard input

[Terry J. Westley]

In article <39@screamer.csee.usf.edu> stelmack@screamer.csee.usf.edu (Gregory M. Stelmack) writes:
>Is there any way in Ada to read single keystrokes from the keyboard? Not the
>GET from TEXT_IO which requires a carriage return before sending the data, but
>as soon as a key is pressed have it sent? We have a whole Ada class that would
>like to know, and no one here can help figure it out. So, I ask the net.
>We've checked books and can't figure it out.
>
>Thanks, 
>-- Greg Stelmack
>-- Email: stelmack@sol.csee.usf.edu
>-- USmail: USF Box 1510, Tampa, FL 33620-1510
>-- Amiga: the only way to compute!

This is typically a function of the terminal driver, not Ada.  In Unix
(SunOS), you have to call ioctl to put the terminal in "raw" mode and
call fcntl to request that the SIGIO signal be delivered to your process.
If SIGIO is being used for anything else (such as socket communication),
you've got a conflict that must be resolved.  I've also done it for VxWorks.

I can see where one could implement a different Text_IO that does this, but I
doubt if any vendors supply it automatically.


Terry J. Westley
Arvin/Calspan Advanced Technology Center
P.O. Box 400, Buffalo, NY 14225
acsu.buffalo.edu!planck!hercules!westley

Re: Keyboard input

[Gregory M. Stelmack]

Thanks to the net for all of your help with this question. Since this is for
programs for a class and portability is not a concern, I'll try some of the
UNIX suggestions and talk to the professor about them.

Thanks to all who responded!

-- Greg Stelmack
-- Email: stelmack@sol.csee.usf.edu
-- USmail: USF Box 1510, Tampa, FL 33620-1510
-- Amiga: the only way to compute!

Re: Keyboard input

[Charles H. Sampson]

In article <1990Sep19.192717.13113@planck.uucp> westley%hercules@planck.UUCP (Terry J. Westley) writes:
>In article <39@screamer.csee.usf.edu> stelmack@screamer.csee.usf.edu (Gregory M. Stelmack) writes:
>>Is there any way in Ada to read single keystrokes from the keyboard? Not the
>>GET from TEXT_IO which requires a carriage return before sending the data, but
>>as soon as a key is pressed have it sent? We have a whole Ada class that would
>>like to know, and no one here can help figure it out. So, I ask the net.
>>We've checked books and can't figure it out.

>This is typically a function of the terminal driver, not Ada.  In Unix
>(SunOS), you have to call ioctl to put the terminal in "raw" mode and
>call fcntl to request that the SIGIO signal be delivered to your process.
>If SIGIO is being used for anything else (such as socket communication),
>you've got a conflict that must be resolved.  I've also done it for VxWorks.

     Lots of operating systems give the programmer the ability to read
individual keystrokes, in addition to reading entire lines.  I've always
assumed that the "usual" Ada approach to inputting single characters
(above) was an implementation decision:  If the individual keystrokes
are read, the system's line-editing features (backspace, start over, etc.)
are either lost or must be duplicated in the Ada program.  If they're
lost, the program becomes very user-unfriendly.  For example, if the
user enters "A-backspace-B", more than likely only the "B" appears on
the screen, but the Ada program has seen all three characters and might
even emit an error message about them, which looks like it's complaining
about the "B".  Implementors, is my assumption about your decision right?

                             Charlie Sampson

Re: Keyboard input

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / sampson@cod.NOSC.MIL (Charles H. Sampson) /  4:20 pm  Sep 20, 1990 /

>     Lots of operating systems give the programmer the ability to read
>individual keystrokes, in addition to reading entire lines.  I've always
>assumed that the "usual" Ada approach to inputting single characters
>(above) was an implementation decision:  If the individual keystrokes
>are read, the system's line-editing features (backspace, start over, etc.)
>are either lost or must be duplicated in the Ada program.  If they're
>lost, the program becomes very user-unfriendly.  For example, if the
>user enters "A-backspace-B", more than likely only the "B" appears on
>the screen, but the Ada program has seen all three characters and might
>even emit an error message about them, which looks like it's complaining
>about the "B".  Implementors, is my assumption about your decision right?

Sure, sure, sure... But what if he Ada programmer, like the initial poster,
*WANTS*  to  do  their own  single  character I/O   and handle any editting
process,  perhaps   to provide  a different,   more  friendly or consistent
editting process, huh?  How does he/she do it?

P.S.	I hate when people don't answer the question posed
P.S.S.	I'm  also not answering the  question but  I don't know the answer.
	Perhaps the solution is  to call the OS  routine (read or getc) but
	that isn't Ada or portable.

Re: Keyboard input

[Naasif Gierdien]

In article <39@screamer.csee.usf.edu>, stelmack@screamer.csee.usf.edu (Gregory M. Stelmack) writes:

> Is there any way in Ada to read single keystrokes from the keyboard? Not the
> GET from TEXT_IO which requires a carriage return before sending the data, but
> as soon as a key is pressed have it sent? We have a whole Ada class that would
> like to know, and no one here can help figure it out. So, I ask the net.
> We've checked books and can't figure it out.
> 
> This is for a Data Structures class where we want to write our own I/O
> routines to validate data. But to do what we want to do, we need keys as soon
> as they are hit.


I've had the same problem trying to read single keystrokes from the keyboard.
The main difference is i'm running Janus ADA on a standalone
IBM 286/386 compatable. I also have access to the Meridian
ADA Compiler and libraries but being a relatively new user
to ADA i'm not yet sure what it can do. 

> There should be an easy way to do it, but we can't find it. Any ideas? E-mail
> if its simple so this group doesn't get cluttered due to my ignorance...
> 

At least you're not the one :-)

My second question is :-

I want to be able to put higher order ASCII values ( greater than 127 ) 
to the screen..using the same ADA and hardware as above.

Any suggestions please post here or email me. (Please excuse my ignorance :-)

Re: Keyboard input

[Naasif Gierdien]

In the previous article i forgot to include my email address :-)


 _____________________________________________________________________________ 
| Naasif Gierdien                                                             |
|           _    _    _     ____    \_/                                       |
|    /   / /_\  /_)  /_)  /  /      ( )                                       |
|   (_/_/ /  / /__) /__) /  /      (   )       ".....More INPUT....."         |
|                                                                             |
| Internet: naasif%eyrie@labtam.oz.au                                         |
| UUCP    : ...!uunet!labtam.oz!eyrie!naasif          #include <disclaimer.h> |
|_____________________________________________________________________________|

Re: Keyboard input

[Michael Feldman]

In article <920031@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
>>/ hpclapd:comp.lang.ada / sampson@cod.NOSC.MIL (Charles H. Sampson) /  4:20 pm  Sep 20, 1990 /
>
>Sure, sure, sure... But what if he Ada programmer, like the initial poster,
>*WANTS*  to  do  their own  single  character I/O   and handle any editting
>process,  perhaps   to provide  a different,   more  friendly or consistent
>editting process, huh?  How does he/she do it?
Actually, your PPS has the answer.
>
>P.S.	I hate when people don't answer the question posed
>P.S.S.	I'm  also not answering the  question but  I don't know the answer.
>	Perhaps the solution is  to call the OS  routine (read or getc) but
>	that isn't Ada or portable.
Indeed the solution is to call a routine from the operating system,
preferably by writing exactly the IO routine you need in C (for instance)
and making it Ada-callable by using pragma INTERFACE.

I'm not sure what you mean by "it isn't Ada or portable." If you mean that
it should have been included as a standard I/O package, you may be right;
I think I'd agree. But the fact is that is was _not_ included, and every
Text_IO implementation I'm aware of uses buffered input which requires a
CR to transmit the buffer contents. Some implementers have provided
additional I/O packages; some have not.

There are _lots_ of things that people could say should have been included
in the standard; undoubtedly your list would not be exactly the same list
as mine. That's the way it goes; the standard can't include everything in
the whole world. So we all cope by adding additional packages. If they
have to be written in another language and "pragma INTERFACE-d" to make
them Ada-callable, that is not sinful. Indeed, why else would this pragma
be in the language? At least the standard foresaw that OS services or
"foreign-language" programs would have to be called and provided the "hooks"
to do it. 

I would like very much to see a portable character-IO library -
portable in the sense that there would be an implementation-independent
package spec. The routine described by Rick Conn in a previous posting is
a good start in this direction. I will see if I have a copy and post it.
The package _body_ will necessarily be OS-dependent, because it's something
that can't be directly written in Ada.
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: Keyboard input

[Richard A. O'Keefe]

In article <2166@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
[about signle-keystroke input]
> I'm not sure what you mean by "it isn't Ada or portable." If you mean that
> it should have been included as a standard I/O package, you may be right;
> I think I'd agree.

I would like to know how such a package could be implemented under CMS
or TSO.  (Any "power of 2" fan know what CANDE will let you do these days?)
IBM's operating systems really don't believe in character transput to
terminals.  Perhaps IBM _ought_ to be ignored, but _could_ it have been?

-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.

Re: Keyboard input

[Michael Feldman]

In article <3808@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>[about single-keystroke input]
>
>I would like to know how such a package could be implemented under CMS
>or TSO.  (Any "power of 2" fan know what CANDE will let you do these days?)
>IBM's operating systems really don't believe in character transput to
>terminals.  Perhaps IBM _ought_ to be ignored, but _could_ it have been?
>
My impression (from only limited experience with CMS) is that single-character
I/O is difficult at best under CMS because the CMS device drivers (or "access
methods" in IBM parlance) assume non-scrolling terminals and line-oriented
input (hence the MORE...) message at the bottom of every screen. This is not
an Ada problem, rather an OS one. In fact, I tried using an _ASCII_ terminal
driver (provided, I think, for interactive APL users among others). Using
Text_IO to send escape sequences to the terminal, so that I could control
my own _output_ formatting, failed: the driver was willing to give up on the
MORE... dialog, but it mapped my nonprintable ASCII characters to blanks,
so the terminal-control sequences were ignored. 

I conjecture that a sufficiently adept assembler programmer could figure out
how to end-run the CMS device drivers and then write an interface package
to make it Ada-callable, but I don't think it would be easy. 

Given the differences between ASCII and EBCDIC character sets, I find it
amazing that a decent Ada could have been implemented at all on IBM mainframe
iron. There are in fact at least two quite decent systems out there, one
sold by Alsys, the other by IBM, supported, I believe, out of Toronto.

I take it you are using the IBM Ada "program product" for Ada on CMS. If so,
the system is really a TeleSoft product (I am not revealing any secrets here).
Anyone at TeleSoft know whether this sort of thing has been done?
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: Keyboard input

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / mfeldman@seas.gwu.edu (Michael Feldman) /  1:13 pm  Sep 22, 1990 /

>Indeed the solution is to call a routine from the operating system,
>preferably by writing exactly the IO routine you need in C (for instance)
>and making it Ada-callable by using pragma INTERFACE.
>
>I'm not sure what you mean by "it isn't Ada or portable." If you mean that
>it should have been included as a standard I/O package, you may be right;
>I think I'd agree. 

I think it's pretty simple: If  you  have to  resort to  using C instead of
Ada then it's not Ada is it?  What so  hard to understand  about that?  And
what happens when  you port this to a  system that  doesn't have C huh?   I
mean, what if the poor guy doesn't have anything but Ada?

>There are _lots_ of things that people could say should have been included
>in the standard; undoubtedly your list would not be exactly the same list
>as mine. That's the way it goes; the standard can't include everything in
>the whole world. So we all cope by adding additional packages. If they
>have to be written in another language and "pragma INTERFACE-d" to make
>them Ada-callable, that is not sinful.

Yeah it's not standard, it's not contained in TEXT_IO and all  that.  Also,
I've probably done more pragma INTERFACE'ing than you have.  But that don't
make it portable.    At best   it opens  up   opportunties for   portablity
problems. 

But still  how can you do this  in Ada?  (A:  You can't.) Well   what about
people who only have Ada? (A: They're stuck.)

Keyboard input on IBM mainframes

[Jerry Callen]

In article <2172@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
> [various stuff about the difficulties of doing character I/O
>  on IBM 370 mainframes]
>I conjecture that a sufficiently adept assembler programmer could figure out
>how to end-run the CMS device drivers and then write an interface package
>to make it Ada-callable, but I don't think it would be easy. 

IBM terminal I/O is fundamentally half-duplex. There is possibly a kluge you
could pull on 3270s using "trigger fields" to get data a character at a
time but the overhead would be unspeakable. Unless you are willing to
use somewhat non-standard hardware or hack the OS (ha!) it is just not
possible to do "raw mode" I/O on IBM 370 mainframes. Amdahl's UTS
(Unix for 370s) can do this with special software in the mainframe and
in the terminal controller, but for CMS and TSO it is for all intents
and purposes impossible.

>Given the differences between ASCII and EBCDIC character sets, I find it
>amazing that a decent Ada could have been implemented at all on IBM mainframe
>iron. There are in fact at least two quite decent systems out there, one
>sold by Alsys, the other by IBM, supported, I believe, out of Toronto.

Actually, it's not very hard; you just have to translate everying coming in 
and going out. Bits is bits is bits...

-- Jerry Callen
   jcallen@encore.com

P.S. There's a third "quite decent" Ada for IBM mainframes, from Intermetrics.
	 I don't know if it is actually a product or not. I used to work
	 on it, so I can hardly provide an unbiased assessment. :-)

Re: Ada on IBM mainframes

[Michael Feldman]

In article <12790@encore.Encore.COM> jcallen@encore.Com (Jerry Callen) writes:
>
>P.S. There's a third "quite decent" Ada for IBM mainframes, from Intermetrics.
>	 I don't know if it is actually a product or not. I used to work
>	 on it, so I can hardly provide an unbiased assessment. :-)

This compiler existed at one time; perhaps it still does. However, I cannot
find a reference to it in the June 1990 list of validated compilers, and that
list shows only IBM (via TeleSoft) and Alsys supporting IBM mainframes. I
guess Intermetrics let its validation lapse or something. Is that system
still being maintained? Anyone out there know?

---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: Keyboard input

[stt]

Re: Single-character Terminal I/O, Portability, etc.

This really has nothing to do with C vs. Ada.

This is an O/S interface issue.  If you are talking
Unix, then there is a "standard" (almost) way of
accomplishing "raw" I/O.  If you are talking about`
some other operating system, then it will certainly
be different, if possible at all.  If you are talking
Posix, there are a number of options for "non-canonical"
terminal processing, which provide essentially all of
the capabilities you would want.  There is now a proposed standard
Ada binding to these capabilities (package POSIX_Terminal_Functions).

As far as portability, you will have to survey the O/Ss of
interest, come up with an interface which you can
implement everywhere, and then implement it as appropriate.
Ultimately, I suspect there will be some assembly language
involved, either written by you or by the vendor, since
neither C nor Ada compilers will normally generate
direct O/S system calls.  Of course, if you are using Unix,
then a C library is provided which already has the necessary
interfaces.  Most compiler vendors on Unix provide a similar
library for Ada.  Ideally, they will begin to converge
on the Posix proposed standard for providing these capabilities.

In any language, if you refuse to ever go outside of the language
to interface with the O/S or external subsystems, you may end up
talking only with yourself.  In any case, it usually only takes
a few lines of Assembler or other language.  You may not notice
it in C since you don't have to announce your intentions
with a "pragma Interface" to call an assembler routine, but you
can rest assured that most C system-call libraries are implemented
in assembler by someone.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: Keyboard input

[Edward Falis]

I've been reading this topic with some interest: it's not an easy one
to address, given the language definition. With our products, we've
taken several approaches to solving the problem, but they're not
portable in the sense of using the same source for different target
environments.

For our 68K and 386 Unix products, we use the form parameter to designate
whether terminal input should be on a per line or per character basis.
This is probably the most "Ada" solution. On our MS-DOS products, an
Ada interface to MS-DOS INT21 functions is provided, and the manuals 
explain how to use this interface to do character by character input.
For our embedded application oriented products, the choice is made
in the board support packages, and the interface for the application
is through the standard I/O packages.  Unfortunately, for the two
IBM 370 OS's we have no solution at this time.  - Ed Falis, Alsys

Re: Keyboard input

[Michael Feldman]

In article <920032@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
>>/ hpclapd:comp.lang.ada / mfeldman@seas.gwu.edu (Michael Feldman) /  1:13 pm  Sep 22, 1990 /
>
>I think it's pretty simple: If  you  have to  resort to  using C instead of
>Ada then it's not Ada is it?  What so  hard to understand  about that?  And
>what happens when  you port this to a  system that  doesn't have C huh?   I
>mean, what if the poor guy doesn't have anything but Ada?

It's a bit hard to understand why you are flaming. Let's see if we can cool
tempers a bit. 
>
>Yeah it's not standard, it's not contained in TEXT_IO and all  that.  Also,
>I've probably done more pragma INTERFACE'ing than you have.  But that don't
>make it portable.    At best   it opens  up   opportunties for   portablity
>problems. 

Undoubtedly you've done more interfacing than I have; I'm only a professor.
But I have done _some_ and understand what the issues are. I took the
question as a serious one; obviously you meant it rhetorically because you
knew the answer already.

>But still  how can you do this  in Ada?  (A:  You can't.) Well   what about
>people who only have Ada? (A: They're stuck.)

Or they can make a library call, if the library exists for their
implementation. If it doesn't, they are stuck. That's why there should be a
standard library (i.e. portable) for this. Unfortunately, I don't think
this is possible, as the discussions on this group regarding the virtual
impossibility of doing it on IBM mainframe iron point out. There are some
things that just ain't portable. Period. No matter what language. This
problem will persist until the end of time, or until OS designers all agree
on a standard, whichever comes first (undoubtedly the former will).

I don't want to get into a flame war over languages. Let's see if we can get
an even-tempered discussion going. In my experience there are always things
one can dream up to do that a high-level language doesn't support directly.
The standard way to do this, it seems to me, is to jump into assembler, say,
or use C to make direct calls to an operating system DEPENDENT library. 

There are C libraries for DOS machines that are different from the functionally
similar ones on Unix; there are Unix libraries for functionalities that
don't even exist in DOS (signals come to mind). A direct call to a Unix
routine will NOT be portable if the same routine doesn't exist in DOS. 
We can go the other way, too: interrupt calls that work on DOS won't
work under Unix, especially if the underlying CPU's are different.

Indeed the Unix folks are embroiled in lengthy discussions on "merging" 
the main dialects of Unix. The preamble to the POSIX standard indicates that 
POSIX is not likely to be 100% compatible with ANY existing Unix. 

Since POSIX defines the programmer's interface to "something like Unix" - 
meaning a bunch of C-callable routines - it will be possible to write a
C call which won't work on _some_ system that isn't POSIX-compliant.

The bottom line is that complete portability is, for most nontrivial programs,
an ideal to strive for but, in the end, only an ideal.  We may bemoan this 
state of affairs, but we have to agree that it _is_ the state of affairs and 
is likely to continue to be so in our lifetimes.

None of this is to defend the agonizingly slow development of standard
Ada libraries that go beyond TEXT_IO. I know some of the folks working on
numerics and understand some of the issues there, but I still wish we had
a standard Ada library more-or-less equivalent to <math.h> (although <math.h>
ain't entirely portable either!). I wish we had a standard library for
string handling (the string stuff in <stdio.h> ain't bad for starters, but
could be improved upon). 

And I certainly wish we had a standard library for single-keystroke I/O. 
But we don't. And even if we did, there'd always be machines for which it
would be useless (IBM iron again). The point I tried to make in the note
that was so bitterly flamed is that Ada, like all the other languages,
has hooks (like pragma INTERFACE) to let us write these other packages.
And it is not sinful to use the hooks.

I wish that the Ada compiler community would agree on specs for these
packages and build them already.
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: Keyboard input

[John Prentice]

>I think it's pretty simple: If  you  have to  resort to  using C instead of
>Ada then it's not Ada is it?  What so  hard to understand  about that?  And
>what happens when  you port this to a  system that  doesn't have C huh?   I
>mean, what if the poor guy doesn't have anything but Ada?
>
If the system has only Ada, then in all likelyhood, all OS functions will
be accessible via Ada subprogram/task entry calls, and there will be no need
for C routines.  If the operating system is written in Ada and designed to
support Ada, then C code written for such a system might well have to resort
to calling various Ada routines.
>
>Yeah it's not standard, it's not contained in TEXT_IO and all  that.  Also,
>I've probably done more pragma INTERFACE'ing than you have.  But that don't
>make it portable.    At best   it opens  up   opportunties for   portablity
>problems. 
>
As long as there are different HW architecures and different OSs, then
complete portability is a myth.  C code is often highly portable accross
similar architures using Unix, but this portability is not an intrinsic property
of C; it is a funtion of the similar HW and common OS. 

In general, the goal of writing "portable" code is to minimize and localize 
non-portable code.  In terms of intrinsic language properties, Ada is no
worse off than C (perhaps better).  The Ada package provides a very nice
mechanism for isolating low-level dependencies behind a common interface.
Also, Ada's tasking facilities (for example) can support multi-processing or 
multi-programming without a need to make calls to the underlying OS, again 
enhancing portability. 

Re: Keyboard input

[Chris Holl @adonna]

Posted for Brian Nettleton:
-----------------------------------------------------------------------------
In article written 06:58 Mon Sep 24, 1990 by mfeldman@seas.gwu.edu he states:

>My impression (from only limited experience with CMS) is that single-character
>I/O is difficult at best under CMS because the CMS device drivers (or "access
>methods" in IBM parlance) assume non-scrolling terminals and line-oriented
>input (hence the MORE...) message at the bottom of every screen. This is not
>an Ada problem, rather an OS one. In fact, I tried using an _ASCII_ terminal
>driver (provided, I think, for interactive APL users among others).

Prof. Feldman is essentially correct here, I haven't seen any single-
character I/O through standard IBM terminal controllers.  However, the 
problem isn't with the OS so much as the hardware.  IBM 3270-series 
terminals are block-mode devices.  Keystrokes modify a local buffer.
The user can alter the contents of the local buffer.  Transfer of data 
to the CPU doesn't happen until the user hits enter.

We've had some success doing character I/O through a different IBM 
peripheral called a 3705 Communication Controller (or any 37xx 
Communication Controller).  What we did was to get the mainframe 
to talk to a MC68000 board for a (now unsupported) 370 to 68k cross-
compiler, but the RS-232 cable could have as easily been connected to 
a terminal and single-character I/O made to work well.

-Brian Nettleton

TeleSoft

Re: Ada on IBM mainframes

[ryer]

Intermetrics chose not to validate our IBM MVS compiler on the 1.10 suite,
due to cost vs. benefit.  We are currently working on 1.11 and will re-
validate the compiler this winter.  Meanwhile, we are still selling the
compiler (which does correctly handle the 1.10 suite, certificate or
not), and our customers have not seemed to have a problem with it.

The compiler is very "MVSy", with interfaces to CICS, many form-string
options, EBCDIC<->ASCII translation wherever required, etc.

Mike Ryer
Intermetrics, Inc.