I can honestly assure you that anything said in this thread has absolutely nothing to do with Easycom.
There is no comparison of different toolkits at all here, only comparing differences of XMLSERVICE running on two different machines.
Let me rant a little bit more.
The first problem (that you didn't comment at all on your response), which as I mentioned is most likely an error on my part, is that we are running in local machine here (1st tier as you call it), but still we are for some reason ending up in QRWTSRVR jobs. If I have understood documentation on yips site correctly this shouldn't happen in 1st tier situation, it should only happen in 2nd tier calls. Like I said, this is most likely because of something I have done, that has messed things up, but I don't know what that something is. I thought you might have an idea what could cause the XMLSERVICE to be routed to QRWTSRVR instead of QSQSRVR in 1st tier program call situation.
About the other thing, yes obviously we could be using "startup program" to CHGLIBL the right library list for the job, but upkeep of such a programs is pure pain. That's why we have a working method, that was implemented long before there was any php toolkit in existence. The method is that with JDBC/ODBC/FTP/what-have-you external connections (integrations with other systems) we mostly won't use CHGLIBL programs/commands because it's much easier to manage changes when we only have to change the connecting user profile and/or the users job description (INLLIBL value) to set the correct library list for the job. If something with that particular integration changes, we can just change the job description instead of editing some cl source and compiling again and/or making changes to several different external systems using that integration. We also have couple of external integrations that do use CHGLIBL startup programs and like I said those are pain to manage compared to the ones that only use INLLIBL from the user's job description. Also same thing as with INLLIBL vs. CHGLIBL goes for INLASPGRP value of the job description vs. SETASPGRP command. We also use this method to get the correct iASP from user's job description as well, instead of using SETASPGRP command. I seem to remember many IBM documentation on the subject also specifically recommend using job description's to control initial asp group instead of the SETASPGRP command.
I could be very wrong here, but I just don't quite understand why 2nd tier would make the situation different here, since we are already in IBM i job anyway, and IBM i job should be able to use user, which has job description with initial library list and initial asp group. But if your earlier response means that this kind of behavior isn't possible in 2nd tier (QRWTSRVR) situation with XMLSERVICE, then that's fine and I accept that.
-Timo

