J-APL(ID:8251/)for Japanese APL IBM Japanese language APL, running on DBCS PCs. Developed jointly by the scientific centres at IBM Madrid and Tokyo References: Introduction It is desirable, or now becoming to be requisite, that users be able to use their own national languages in programming languages: for example, in data, identifiers, and messages [l]. But to accommodate national languages other than occidental languages, such as Arabic, Chinese, Japanese and so on, programming languages should remove the present 256-character limitation that confines legitimate characters to traditional alphanumerics. The Japanese characters consist of several thousands of ideographic characters (Kanji), adapted from Chinese, as well as two Japanese phonetic alphabets, Kana (Hira-kana and Kata-kana). Each of the Kana character sets consists of 46 different symbols, each expressing a simple sound of the Japanese syllabary, with the addition of some diacritical marks and subscripted symbols. In the Japanese writing system we use a mixture of Kanji and Kana, where Kanji is used as the root words and Kana as inflections for most purposes, as well as Arabic numbers and Roman alphabets. Because of this complexity, we have had no reasonable way to type our own language, especially Kanji characters. In recent years, the use of Kanji in computers has greatly increased because of a breakthrough in Kanji typing methods: that is, a phonetic or Kana-to-Kanji conversion [2]. It permits the user to key a phonetic spelling from a standard typewriter keyboard using Kana, for which the computer supplies the corresponding Kanji character by looking up the Kanji dictionary stored in a diskette. The IBM Multistation 5550 is a personal computer equipped with the Kana-to-Kanji conversion method for Kanji input in the keyboard BIOS, as well as the Kanji output functions to the screen and printer. We implemented the APL system on the 5550, based on the IBM PC APL developed by the IBM Madrid Scientific Center [4], aiming at the Japanese national language support, which had been strongly required by mainframe APL users because of their need for business applications. Our basic idea is that a Japanese character should be dealt with as a single character scalar in APL, even if it needs two bytes for encoding in memory. To implement this, we had to extend the PC APL interpreter so that a new data type for the Japanese characters could be incorporated in the system, which we now call "Japanese APL". At the same time, to take advantage of the valuable Kanji I/O functions of the 5550 DOS/BIOS, we developed the supervisor and auxiliary processors for Japanese APL. Japanese APL on IBM Multistation 5550 was announced by IBM Japan and has been available to customers since December 1984. Extract: Concluding Remarks Concluding Remarks After observing the user experience of one year in programming the Japanese APL on 5550 since the first shipment to customers in December 1984, we believe that our APL implementation supporting the Japanese characters is well accepted, and users are going to enlarge their Kanji applications on 5550. Furthermore, we announced the Japanese APL Version 2.0 last September, which runs on a variety of Japanese personal computers such as 5550, 5540, 5560, and JK. APL2, on the other hand, has implemented the concept of extended characters for DBCS (Double-Byte Character Set) support, such as Kanji, in the mainframe environment 161. Its aim is supporting multi-national languages simultaneously, while the Japanese APL supports only Japanese. We hope the approach we adopted for the national language support in 5550 APL will be applicable to other languages that also need "wide" characters on the 5550, such as the Chinese and Korean languages, and in the near future, we will be able to realize the concurrent multi-national language support on personal computers. In 1972, someone told me that an advanced version of APL, which featured file 1/0, was being developed at the IBM Philadelphia Scientific Center. By that time APL had proven to be a very useful tool in our office. Immediately it was arranged with IBM Japan to look into the possibility of bringing an early version of this advanced APL to make it the basis for the acceleration of the mechanization of IBM Japan?s planning process. This IBM internal version of APL, which was called APL-SV, really opened up a new horizon for us. At this stage we received very competent technical assistance from people like Joy Tuttle and Alex Morrow in Adin Falkoff?s group at Philadelphia. Prior to joining the IBM APHQ staff, I was a planner of management information systems for the Data Processing Department of IBM Japan. There, I studied in depth the internal logic of the MIS/360 and its boolean indexing mechanism in search of a good information systems. In my new office, where I had strong management support, I decided to apply this experience to the new APL environment and eventually came up with a compact collection of functions, which made it possible for large corporate data files, such aa Order-Entry and Inventory, to be accessed interactively by multiple users at the same time and data retrieved selectively, sorted or merged between files without physically moving records in the files, using the boolean index data prepared monthly when these files are dowrdoaded to designated random access storage. The concept was somewhat similar to the inverted file mechanism employed by APLDI released from IBM later. In comparison to APLDP, this package could handle extremely large files in their original forms with the help of boolean index files created a relatively short period of time on selected key fields depending on the requirements of different user groups. As this 400 line compact utility package gained unexpected popularity in IBM Japan over GIS, MIS/360 etc., it was officially adopted as a standard end-user data retrieval tool by IBM Japan Information Systems. A group of users formulated automatically to assist each other in their problem solving. The package enjoyed the status of one of the indispensable tools to be used in the planning process at IBM Japan even long after I left IBM in 1983. This tool was intended to encourage the use of APL primitives, rather than to cover them. I also made it educational for those who wished to write useful tools, or applications, not only in the economy of coding but in workspace design with the use of function libraries, naming conventions, portability, extendibility etc. [...] In 1975 I was back at Systems marketing, IBM Japan, where my new mission was to market APL in Japan, based on our internal experience. The above-mentioned data retrieval system was made into a commercial package as CIP by IBM Japan and was named APL Data Retrieval And Report Generation System in February, 1976. The first 17 APL customer sites were thus established within a relatively short period of time. Amongst them were Okamura Mfg. (Office furniture manufacturer), Mitsui Ship Building, NKK, Sumitomo Heavy Industries, Kubota Iron Works, etc. We often collided with or resisted against the IBM marketing directions, such as VSPC as the only IBM program product oifering the APL environment but announced initially without TSIO, which could have been the only external file access interface from APL. At that time what I thought was the ideal APL environment was APL-SV. But APL-SV was not made into an IBM program product. I had to choose TSO as an alternative APL environment to promote APL because it was the only one that allowed an APLSV like operation under VSAPL. We relied very heavily on technical advice from Dick Dunbar and invited him to Japan twice to help in our marketing activities. |