|
midrange.com
Jon,
I have included some responses to your questions. Thanks very much for
listening to my disagreeable comments.
>>> Jon Paris <paris@ca.ibm.com> 02/12 9:29 AM >>>
>Thanks for your comments David - even if I don't agree with them <bg>
>Your organisation has made the decision to jump to Java.
We have only made the decision to use Java to generate Java bytecode.
>You are obviously comfortable that you have the skill set and resources to
>make that
work for you.
Hopefully we can leverage these skills to reduce the total number of languages
we use
in our current environment which has grown exponentially in recent years. This
is our
main reason for embracing JAVA.
>Some comments on the requests that are "ours":
>"Allow variable type like OPTIONS(*VARTYPE)" - of course this is of no use
without full descriptors, otherwise you might as well simply use a pointer
which you can do today.
Passing a pointer is our current solution. What are the attributes of what the
pointer is
pointing to? Now you need to pass that also. With *VARTYPE and full support
for
operational descriptors you don't have to pass the attributes.
>"Allow constants to be protected via addressing."
When a parm is CONST it's underlying memory should be protected. Like a watch.
This way you could do %ADDR etc. of a constant and pass by reference. I can't
change a memory location that I do not have a pointer to. If the pointer
carries my
authority why can't that be used to provide this type of function. If the
system can
return an error when I try to access data outside of my authorized space why
can't
it provide a similar function when I try to update a constant space?
>"Allow renaming of procedures within the binding language (Don't force us to
generate meaningless procedure names and their corresponding prototype) - Sorry
I just
don't understand what you are asking for here, can you please explain further
We generate standard procedures for files, etc. The procedure names have to
be unique
in the service program. That is fine. The only way to do that is with a
unique name in the
module. In a module that supports FILEABC we end up with names like
ChnRcdFILEABC.
In a module thats supports FILEXYZ we have ChnRcdFILEXYZ, etc.
>" ...on the procedure interface allow call type "C" or "CL". - Am I correct in
thinking that you need this to handle the differences in handling of single
character return values when calling CL? If not then I'm afraid I don't
understand the request.
Directed more toward "C" and boundry alignment. If you could use a prototype
in
"CL" it would be more relavent. I would also want to use this to specify that
parms passed
into a procedure by reference be passed out with the same OPDESC attributes.
We have
to use copy source and subroutines where procedures would be much better to get
around
this limitation. IE: I pass 3 out of 5 parms to a procedure. It then needs
to pass those on
to another procedure. If I just pass them through the called procedure thinks
I passed 5 parms.
>"Provide a built in to retrieve a system pointer. Provide a built in to
activate a program." - you should be able to do these simply by prototyping C's
MI functions.
We have done that. I have seen several examples in magazines recently about
dynamic procedure calls. They seem to assume only people with a "C" compiler
would have a need. The problem with using MI is there is no documentation. We
backed into a solution based on some old MI source we had. Fortuanately
Barbara
Morris took the time to explain to us the parameters for the required MI
instructions.
>Haven't checked them out but I don't see why it wouldn't work.
I'm not in favour of adding functions of this nature to the language when A)
there is already a way of doing it and B) the limited number of people who
would use it are more than capable of using that facility. These kinds of
requests also appear to run a little bit contrary to the original thrust of
your note which is in the "Let them eat Java" vein, whereas you appear here to
be asking us to add function already available in C.
It may appear contrary today, but I think the popularity of Java on the 400
will be
much closer to RPG than to C on the 400.
Thanks for your interest,
David Morris
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| 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-2025 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.
