×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
At 06:58 AM 10/23/97 -0500, you wrote:
>Vern Hamberg wrote:
>At 07:00 AM 10/18/97 -0500, you wrote:
>
>> You port the byte code. It's along the lines of a compiles language. Every
>> JVM is supposed to be able to interpret these byte codes for its platform.
>> That's the basis of the 'write once, run anywhee' concept.
>>
>> As far as data queues go, what the app gets is just data—it knows diddly
>> about DQ's. The Java class is imported into the app, and that's what knows
>> how to get to a DQ.
>>
>That would be great, but I'm a little confused. I'm not convinced that
>the java vm on any given platform is that advanced. You still have to
>differentiate object
>types on an as/400, (rpg pgm XX0001 could have the same name as physical
>file XX0001 as well as data area XX0001, as well as job description
>XX0001. Some of these discrepancies can be explained using pc style
>extentions, but not all. I can't see microsoft adding a "data queue"
>layer to thier jvm. I'm not as well versed on pc or unix platforms, but
>I'm guessing there are similar discrepancies.
I think we're talking about the crux of the matter here. This feels really important, because I think it's about who does what in these kinds of application. I won't pretend to know that much yet—maybe never :^), but here's what I think is going on, after importing the AS/400 ToolKit into VA4Java:
There're a couple data queue Java classes in the ToolKit, one called COM.ibm.as400.access.BaseDataQueue, another called COM.ibm.as400.access.KeyedDataQueue, say. These classes are all Java (byte) code. As I understand it, the Java code uses Sockets to connect to servers on an AS/400. This connectivity is universal—all that's required is to know the format of the packets being exchanged between client and server. (It's like APPC, maybe, which only creates the connection, right? Then you exchange certain verbs (messages) with, say a DDM "server".) That's why this can work from any JVM, whether in a browser, on a Mac, in Windows, or even on the AS/400 (repeating now, so long as we don't use AWT classes). The JVM need not know anything about the AS/400—it's the classes that already have taken care of this.
The only responsibility of the JVM is to execute the byte codes that it gets from the class or classes. It is, in a way, a runtime engine for a compiled object. This makes it appear to be somewhat interpreted, and maybe that's the case. That is the same argument that said VB did not generate true executables. Well, it did, but the executables had P-code, something like byte codes, I suppose, and these were passed through the runtime vbrunx00.dll.
I ramble—is this at all clear? as mud? or as 3-day old coffee?
Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480
+--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "JAVA400-L@midrange.com". | To unsubscribe from this list send email to MAJORDOMO@midrange.com | and specify 'unsubscribe JAVA400-L' in the body of your message. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
