comparing Java/Eclipse to C#/Visual Studio - IBM AS400

This is a discussion on comparing Java/Eclipse to C#/Visual Studio - IBM AS400 ; It is a new year kids and my forecast is that the decline of IBM will continue. As the execs start to panic there is no telling what harm they will do. Here are two brief but useful comparisons of ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: comparing Java/Eclipse to C#/Visual Studio

  1. comparing Java/Eclipse to C#/Visual Studio

    It is a new year kids and my forecast is that the decline of IBM will
    continue. As the execs start to panic there is no telling what harm
    they will do. Here are two brief but useful comparisons of C# and
    Java:

    http://devlicio.us/blogs/jeff_perrin...java-land.aspx

    http://codebetter.com/blogs/jeremy.m...Java-Land.aspx

    -Steve


  2. Re: comparing Java/Eclipse to C#/Visual Studio

    "Steve Richter" writes:

    > It is a new year kids and my forecast is that the decline of IBM will
    > continue. As the execs start to panic there is no telling what harm
    > they will do. Here are two brief but useful comparisons of C# and
    > Java:


    Nice little comparison. Unfortunately .NET is not available on the
    AS400 platform yet, so if you write code that will run there you don't
    have a choice.

    I looked at the Mono project, but it is not ported to iSeries. If
    "somebody" would port it to PASE (aix) then we would be able to use
    ..NET natively.

    Until then it is Eclipse for me....

    --
    Thorbjørn Ravn Andersen

  3. Re: comparing Java/Eclipse to C#/Visual Studio

    Thorbjoern Ravn Andersen writes:

    > I looked at the Mono project, but it is not ported to iSeries. If
    > "somebody" would port it to PASE (aix) then we would be able to use
    > .NET natively.


    Apparently "somebody" already did...

    http://threebit.net/mail-archive/mon.../msg00380.html

    The links to Bill Seuer are down for me though.

    --
    Thorbjørn Ravn Andersen

  4. Re: comparing Java/Eclipse to C#/Visual Studio


    Thorbjoern Ravn Andersen wrote:
    > "Steve Richter" writes:
    >
    > > It is a new year kids and my forecast is that the decline of IBM will
    > > continue. As the execs start to panic there is no telling what harm
    > > they will do. Here are two brief but useful comparisons of C# and
    > > Java:

    >
    > Nice little comparison. Unfortunately .NET is not available on the
    > AS400 platform yet, so if you write code that will run there you don't
    > have a choice.


    I would argue that .NET client type programs could work very well with
    the as400. Write all your interactive code as .NET desktop programs.
    Use the as400 as the shared database and batch job facility. My first
    attempt on something like this would be to not use ODBC, but use
    sockets and some sort of XML based datastream to pass messages and data
    between the PC client and AS400 server.

    -Steve


  5. Re: comparing Java/Eclipse to C#/Visual Studio


    "Steve Richter" wrote in message
    news:1167796367.055026.179970@48g2000cwx.googlegro ups.com...
    >
    > Thorbjoern Ravn Andersen wrote:
    >> "Steve Richter" writes:
    >>
    >> > It is a new year kids and my forecast is that the decline of IBM
    >> > will
    >> > continue. As the execs start to panic there is no telling what harm
    >> > they will do. Here are two brief but useful comparisons of C# and
    >> > Java:

    >>
    >> Nice little comparison. Unfortunately .NET is not available on the
    >> AS400 platform yet, so if you write code that will run there you
    >> don't
    >> have a choice.

    >
    > I would argue that .NET client type programs could work very well with
    > the as400. Write all your interactive code as .NET desktop programs.
    > Use the as400 as the shared database and batch job facility. My first
    > attempt on something like this would be to not use ODBC, but use
    > sockets and some sort of XML based datastream to pass messages and
    > data
    > between the PC client and AS400 server.
    >
    > -Steve
    >

    Actually, I am in the process of implementing just such a scheme. On my
    AS/400, i have socket listener job, that spawns a socket server for each
    client connection. The connection server job spawns a socker writer job
    and then spawns a socker reader and then waits for the reader job to
    place entries on a data queue. The reader job performs buffered
    non-blocking reads and translates the buffered data using iconv(); it
    then places the request on a data queue. From the data queue the server
    job pulls off requests, which is a string of XML data. The server job
    parses the xml string and then invokes the appropriate program to handle
    the request, upon return from the handler program, the server then
    writes the response as an xml string to a second data queue for the
    writer job. The writer job translates the response data using iconv()
    and uses non-blocking writes to write the response to the socket.

    I know using 3 jobs to service requests seems heavy, but this allows me
    to avoid using pthreads and awful ILE c. It also allows the socket
    clients to batch up multiple requests and pull the responses off in
    batches as well. On the AS/400 side, while the client server is
    processing a request, the readers and writers can be doing the their I/O
    ..

    On the client side, (an ecommerce website) I am using a connection pool
    so that I may reuse already established connections. The pool manager,
    based on apache's commons-pool.1.3 package, controls how many
    simultaneous connections are made to the AS/400 and evicts connections
    that are dead or that have been idle too long.

    The advantages of using this method

    1. Much, much, much better performance of prepared stored procedure
    calls.
    2. The fire wall only has to open a single port that my listener is
    accepting connections on. and *not* the well known database ports.
    3. The socket listener only handles requests that it recognizes, the
    ODBC/JDBC server jobs will attempt to process any sql statement.
    4. I can test my socket server using an ascii telnet client.
    5. Much better control of when the web application can access the
    backend. If you want to shut off access, then end the listener job. With
    JDBC this is much more problematic.

    If you have the means to take this kind of approach, I highly recommend
    you do it.

    By the way, writing your connection server job in java to run on AS/400
    negates some of the benefits. If at all possible, you should write your
    server side in a native as/400 language. We use ILE C to handle the
    socket I/O and PL/I for the XML parsing/processing (it's a homegrown
    parser and although it is not a fully compliant parser, there hasn't
    been an XML file that it couldn't handle in the last 7 years. IMHO the
    XML and the SAX/DOM specs are way over-bloated for the uses most people
    make of it )






  6. Re: comparing Java/Eclipse to C#/Visual Studio

    Tim M said the following on 3.1.2007 6:15:
    > Actually, I am in the process of implementing just such a scheme. On my
    > AS/400, i have socket listener job, that spawns a socket server for each
    > client connection. The connection server job spawns a socker writer job


    As I see it, you are creating security hole in AS/400.
    Do you have authentication and encryption of your streams?
    Are you spawning threads for execution under the user that has requested
    such a request?

    Just consider this. I know you are getting performace boost :-)
    --
    Dejan Rodiger - PGP ID 0xAC8722DC
    Delete wirus from e-mail address

  7. Re: comparing Java/Eclipse to C#/Visual Studio

    "Steve Richter" writes:

    > I would argue that .NET client type programs could work very well with
    > the as400. Write all your interactive code as .NET desktop programs.
    > Use the as400 as the shared database and batch job facility. My first


    > attempt on something like this would be to not use ODBC, but use
    > sockets and some sort of XML based datastream to pass messages and data
    > between the PC client and AS400 server.


    For .NET you should look into using IKVM to convert the JTOPEN toolbox
    to .NET, and use it to talk to the AS400. others have reported it
    works well.


    --
    Thorbjørn Ravn Andersen

  8. Re: comparing Java/Eclipse to C#/Visual Studio

    "Tim M" writes:

    > then places the request on a data queue. From the data queue the server
    > job pulls off requests, which is a string of XML data. The server job
    > parses the xml string and then invokes the appropriate program to handle
    > the request, upon return from the handler program, the server then
    > writes the response as an xml string to a second data queue for the
    > writer job. The writer job translates the response data using iconv()


    It sounds to me like you are reimplementing webservices

    How does your implementation behave under load?

    > parser and although it is not a fully compliant parser, there hasn't
    > been an XML file that it couldn't handle in the last 7 years. IMHO the
    > XML and the SAX/DOM specs are way over-bloated for the uses most people
    > make of it )


    In a situation similar to yours, we decided to let Java pretty-print
    the incoming XML-files so that we were guaranteed that they would
    be parsable by the COBOL XML-subset parser we are using.

    Worked very well, and is simple to code.
    --
    Thorbjørn Ravn Andersen

  9. Re: comparing Java/Eclipse to C#/Visual Studio


    Tim M wrote:
    > "Steve Richter" wrote in message
    > news:1167796367.055026.179970@48g2000cwx.googlegro ups.com...
    > >
    > > Thorbjoern Ravn Andersen wrote:
    > >> "Steve Richter" writes:
    > >>
    > >> > It is a new year kids and my forecast is that the decline of IBM
    > >> > will
    > >> > continue. As the execs start to panic there is no telling what harm
    > >> > they will do. Here are two brief but useful comparisons of C# and
    > >> > Java:
    > >>
    > >> Nice little comparison. Unfortunately .NET is not available on the
    > >> AS400 platform yet, so if you write code that will run there you
    > >> don't
    > >> have a choice.

    > >
    > > I would argue that .NET client type programs could work very well with
    > > the as400. Write all your interactive code as .NET desktop programs.
    > > Use the as400 as the shared database and batch job facility. My first
    > > attempt on something like this would be to not use ODBC, but use
    > > sockets and some sort of XML based datastream to pass messages and
    > > data
    > > between the PC client and AS400 server.
    > >
    > > -Steve
    > >

    > Actually, I am in the process of implementing just such a scheme. On my
    > AS/400, i have socket listener job, that spawns a socket server for each
    > client connection. The connection server job spawns a socker writer job
    > and then spawns a socker reader and then waits for the reader job to
    > place entries on a data queue. The reader job performs buffered
    > non-blocking reads and translates the buffered data using iconv(); it
    > then places the request on a data queue. From the data queue the server
    > job pulls off requests, which is a string of XML data. The server job
    > parses the xml string and then invokes the appropriate program to handle
    > the request, upon return from the handler program, the server then
    > writes the response as an xml string to a second data queue for the
    > writer job. The writer job translates the response data using iconv()
    > and uses non-blocking writes to write the response to the socket.
    >
    > I know using 3 jobs to service requests seems heavy, but this allows me
    > to avoid using pthreads and awful ILE c.


    what is the problem with ILE C and threads? Is SQL within ILE C
    threadsafe? I know RPG is not threadsafe in a practial way

    I just checked if the recio database functions like _Rreadk are
    threadsafe. They are, but the commitment control functions are not.
    http://publib.boulder.ibm.com/infoce...zan5mst234.htm
    http://publib.boulder.ibm.com/infoce...zan5mst234.htm

    -Steve


  10. Re: comparing Java/Eclipse to C#/Visual Studio



    >> I know using 3 jobs to service requests seems heavy, but this allows
    >> me
    >> to avoid using pthreads and awful ILE c.

    >
    > what is the problem with ILE C and threads? Is SQL within ILE C
    > threadsafe? I know RPG is not threadsafe in a practial way
    >
    > I just checked if the recio database functions like _Rreadk are
    > threadsafe. They are, but the commitment control functions are not.
    > http://publib.boulder.ibm.com/infoce...zan5mst234.htm
    > http://publib.boulder.ibm.com/infoce...zan5mst234.htm
    >
    > -Steve
    >

    I *hate* C. It is ugly and has no redeeming qualities. But I don't want
    to get into a language vs. language war.

    Now, if you choose to implement your socket server in C using pthreads,
    you are quite welcome to. You would end up with a conceptually similar
    design as I have.
    You would have a thread that serves as a socket listener to accept new
    connections that forks new threads as connections are made. The server
    thread would then fork socket reader and writer threads.

    However, if you intend to use RPG and/or Cobol applications, I would
    recommend that your socket listener SPAWN your server application, that
    would then fork reader and writer threads. This way multiple instances
    of your connection server will not block each other when they invoke the
    RPG/Cobol programs to service requests.

    If you want to use multi-threaded with non-safe SQL access, there is an
    mode of the SQL-CLI which connects to the database via the JDBC/ODBC
    ports. Of course this negates the purpose of writing a specialize socket
    service.






  11. Re: comparing Java/Eclipse to C#/Visual Studio


    "Dejan Rodiger" wrote in message
    news:enffmg$kfq$1@ss408.t-com.hr...
    > Tim M said the following on 3.1.2007 6:15:
    >> Actually, I am in the process of implementing just such a scheme. On
    >> my
    >> AS/400, i have socket listener job, that spawns a socket server for
    >> each
    >> client connection. The connection server job spawns a socker writer
    >> job

    >
    > As I see it, you are creating security hole in AS/400.
    > Do you have authentication and encryption of your streams?


    No. there is no need for such a thing for the services I am
    implementing. the Web servers sit behind a firewall in a DMZ. The
    backend AS/400 sits behind its firewall and only accepts connections via
    specific ports from specific servers.

    > Are you spawning threads for execution under the user that has
    > requested
    > such a request?


    The connection server runs under the authority that I start it with. The
    socket service is a helper to an ecommerce website as such there is no
    "user" in the fashion that your question pre-supposes.

    >
    > Just consider this. I know you are getting performace boost :-)


    Of course the exact same objections can be made if you are using
    JDBC/ODBC to connect. So there is simply no way that the socket server I
    wrote which only answers requests specific to my implementation that
    invokes programs that I have written that I have implemented can be
    *less* secure than a connection accomplished through a generic
    multi-purpose utility such as JDBC.

    > --
    > Dejan Rodiger - PGP ID 0xAC8722DC
    > Delete wirus from e-mail addres




  12. Re: comparing Java/Eclipse to C#/Visual Studio


    "Thorbjoern Ravn Andersen" wrote in message
    news:yu2wt44v9uw.fsf@luhmann.netc.dk...
    > "Tim M" writes:
    >
    >> then places the request on a data queue. From the data queue the
    >> server
    >> job pulls off requests, which is a string of XML data. The server
    >> job
    >> parses the xml string and then invokes the appropriate program to
    >> handle
    >> the request, upon return from the handler program, the server then
    >> writes the response as an xml string to a second data queue for the
    >> writer job. The writer job translates the response data using iconv()

    >
    > It sounds to me like you are reimplementing webservices


    That's right. And I don't have to use the overbloated SOA/SOAP
    protocols. And I don't have to pay megabucks to IBM for websfear. And I
    don't have to re-implement all my business rules in Java. But rather I
    can use the programs that have proven themselves over the years. And I
    can get it done rapidly.

    And I don't have to implement kludgy wrappers around my programs using
    the JNI, or Stored Procedure, or RPC, Jt400 program call mechanisms.
    >
    > How does your implementation behave under load?
    >

    Performance tests are looking good. But remember, the load was always on
    the system. It is simply being moved from the heavy JDBC interface, to
    the slimmer socket interface.

    >> parser and although it is not a fully compliant parser, there hasn't
    >> been an XML file that it couldn't handle in the last 7 years. IMHO
    >> the
    >> XML and the SAX/DOM specs are way over-bloated for the uses most
    >> people
    >> make of it )

    >
    > In a situation similar to yours, we decided to let Java pretty-print
    > the incoming XML-files so that we were guaranteed that they would
    > be parsable by the COBOL XML-subset parser we are using.
    >
    > Worked very well, and is simple to code.
    > --
    > Thorbjørn Ravn Andersen




  13. Re: comparing Java/Eclipse to C#/Visual Studio

    "Tim M" writes:

    > That's right. And I don't have to use the overbloated SOA/SOAP
    > protocols. And I don't have to pay megabucks to IBM for
    > websfear. And I don't have to re-implement all my business rules in
    > Java. But rather I can use the programs that have proven themselves
    > over the years. And I can get it done rapidly.


    All these factors are important and it sounds to me you thought this
    carefully through.

    Regarding websphere you don't have to. I have successfully run both
    Tomcat and Jetty and JBoss on an iSeries, where it is trivially simple
    to implement a webservice with Apache Axis.

    > And I don't have to implement kludgy wrappers around my programs using
    > the JNI, or Stored Procedure, or RPC, Jt400 program call mechanisms.


    We have found that the jt400 mechanism is fast "enough" for almost all
    purposes, but that it is difficult to use debugging on the programs
    called.

    We have been very satisfied with the performance of the Java+Cobol
    combination, but you have to watch out for memory usage.

    --
    Thorbjørn Ravn Andersen

+ Reply to Thread