Conference rdgeng::cics_technical

	If I understand the question correctly you are referring to the fact
  that CICS is linked with the -taso switch. This does not change in V2.1b
  and in fact is very unlikely to change in any foreseeable version.

	As to a workaround. Are you building your application using the
  -taso switch. We've done this in the past it seems to be OK to include
  a non -taso library in a larger object that is built with -taso.

	Let me know if his helps.

	Geoff.

    hi!,
    thanks for your fast answer,
    unfortunately, our application is the Java Virtual Machine so I cannot
    build it with -taso.
    
    What do you suggest in this case?
    
    Are there possibilities to use a static CICS library to build my
    dynamic one?
    
    thanks again,
    			Marino
    
    

	Um. I'm not familiar with the Java Virtual machine. Could you explain in a little
  more detail what you are doing, particularly, what you are linking and what you are
  trying to build.

	Thanks,

	Geoff.

    Hi,
    following more....
    
    JAVA allows you to invoke a non java code eg. C from inside a Java
    application
    The process is:
    	- Write the application in Java that calls the C function.
    	- Write a Java class that exports that empty function (method),
    	  specifying the library file that implements that function.
    	- Using Java Development Kit, generate two files: one .C and one
    	  include.
    	- Write the source C that implement that function.
    	- Compile source C to obtain a dynamic loadable library (.so on
    	  Unix, .dll on Win95).
    
    At this point execute the Java application (virtual machine with the
    application as parameter), the dynamic library is automatically loaded
    and the Java code can call the C function
    
    Here the problem arises:
    To call an ECI function from Java, we have to generate a .so library
    that has to include the ECI libcicsecico.so library; but this last one
    has been generated 32 bit (-taso) so also the library that has to be
    generated (which includes libcicsecico.so and its C code) must be built
    with -taso (otherwise the linker get an error).
    
    at this point you get the following:
    
    dlopen: Cannot load TASO library ./libecicall.so for non-TASO
    executable (./libecicall.so)
    Exception in thread "main" java.lang.UnsatisfiedLinkError: no ecicall
    in shared library path
    ....... that means that Java interpreter is a 64 bit image and the
    loader doesn't allow the load of a dynamic taso library.
    
    One solution could be the use of a static libcicsecico to build a .so
    not "-taso".
    
    tell me!
    
    thanks in advance
    
    Marino Formia
     

      OK, lets try this. There is a -taso switch to the loader (as opposed to
  ld) which tells the loader to put everything in the truncated address range.
  You could try doing that before running the Java Virtual Machine and you
  might get away with it. See the man page for loader(5) but the basic trick
  is to define the environment variable _RLD_ARGS to be -taso.

      I'm investigating a couple of other possibilities and I'll get back to
  you as soon as I can.

      Geoff.

      To finish my previous note, there is another possibility that isn't
  complete yet. IBM have been working on a gateway between Java and CICS. As
  far as I know this isn't finished yet, furthermore, there are no plans to
  ship it on Digital Unix. If you can make a good case for it to be available
  on our platform please contact Iain Smith @ REO (DTN 830 4021, VAXmail
  RDGENG::SMITHI).

  	Thanks,

  	Geoff.