From YiPs Wiki (i powered)

XMLService: XML Service Common

This page has a few ideas to be talked about at Common, maybe next big improvement on the horizon.

go faster XMLSERVICE

XMLSERVICE was designed to be called from anywhere, using any language, or, in fact just HTML/XML (no language at all). Up front is this design, and, embodied practical outcome trade of ‘convenience and flexibility’ vs. ‘high performance’ custom call ALWAYS faster. We should not violate design ‘convenience and flexibility’, but completely reasonable to explore xmlservice ‘go faster’.

Go faster #1 - stateless and state full available today

*here - stateless
- reloading the ILE *PGM (slow)
*sbmjob - state full 2nd time(+)
- no reload ILE *PGM (fast)
*submit - state full 1st time
- reload program (slow)

Go faster #2 - What about “pure” PASE implementation?

i am not discouraging a PASE toolkit effort, but blind ‘PASE only’ design may lead into a hole, wherein, we are better off expanding roles of XMLSERVICE.


Go faster #3 - change the XML flowing between XMLSERVICE and language client

Current XMLSERVICE allows any language specific toolkit to remain completely written in the language of the client (php only, ruby only, nodejs only, etc.). Perhaps careful inspection using slightly different XML protocol, may lead to greater return on xmlservice investment. The following technique is already available in XMLSERVICE, proven much faster, but no toolkit uses <records> to date (Alan understands).

      *   - data='records' - data follows in record format
      *      fast "many records" i/o big data (see below)  (1.7.5)
      *      <parm comment='wsopstdcnt'>
      *       <data type='3s0' enddo='wsopstdcnt'/>
      *      </parm>
      *      <parm comment='findMe1'>
      *       <ds var='findMe1' data='records'>
      *        <ds var='dcRec1_t' array='on'>
      *         <ds var='dcRec1_t'>
      *          <data var='dcMyName1' type='10A'/>
      *          <ds var='dcRec2_t'>
      *           <data var='dcMyName2' type='10A'/>
      *           <ds var='dcRec3_t'>
      *            <data var='dcMyName3' type='10A'/>
      *            <ds var='dcRec_t' dim='999' dou='wsopstdcnt'>
      *             <data var='dcMyName' type='10A'/>
      *             <data var='dcMyJob' type='4096A'/>
      *             <data var='dcMyRank' type='10i0'/>
      *             <data var='dcMyPay' type='12p2'/>
      *            </ds>
      *           </ds>
      *          </ds>
      *         </ds>
      *        </ds>
      *       </ds>
      *       <records delimit=':'>:Rgr:B:Ok:nd1:nd1:1:1.1:...:</records>
      *      </parm>
      *      a) <records delimit=':'> simply match in order input
      *         of any complex structure. Output matches
      *         order input (see above)
      *      b) <records  delimit=':'> delimit can be any character
      *         not in your complex records (see above)
      *      c) works with any <parm> or <return>
      *      d) dou/enddo works, but tricky script to design (be careful)

We need more research here to see if this is the ‘good enough’ answer.

Go faster #4 - what about ‘pooling’ xmlservice jobs

XMLSERVICE state full ‘pooling’ is already available to user whim using ctl = "*sbmjob"; ipc = '/tmp/myroutetojob' . In fact, under many conditions state full programming is MUCH faster over stateless default in most toolkits ctl = "*here" .

The trick is to build a scheme of routing fits the task(s) ipc = '/tmp/myroutetojob1'; ipc = '/tmp/myroutetojob2', ... . However, feedback says that state full XMLSERVICE programming is difficult for ‘normal’ programmers. Worse, IBM i operators have a nasty habit of randomly killing XTOOLKIT jobs.

Technically, state full XMLSERVICE use semaphores to sequence multiple client usage of the route to one-at-time ipc = '/tmp/myroutetojob' . Semaphores are performance impacts.

It could be argued that a ‘pooled’ xmlservice connection could be ‘designed’ only one-user-at-a-time ‘running’, in fact, many other toolkits use a supreme secofr daemon job to spawn their children to a task at a time (no semaphore needed). All in all, we have never fully explored the ins/outs of xmlservice pooling, and, may be a very interesting topic for a Common ‘toolkit’ meeting.

Go faster #5 - What about custom protocol?

My first reaction is no. However, there may be a case when used in concert with a pooling idea (previous), a bit of custom protocol could offer generous performance improvement.

For example (only example) …

We could invent a mother xmlservice job that simply routed requests to children xmlservice jobs. Essentially, a knock-off of FastCGI (or CGI ILE named activation), but, probably not sockets, although sockets are possible, maybe even good for async requests (nodejs). Instead of sockets, more likely high speed memeory-2-memory (tagged pointer magic dare i whisper the words).

Go faster #6 - What about “mix” PASE implementation and ILE (similar XMLSERVICE)?

Ultimately, a hybrid solution may produce the best possible result, while maintaining classic XMLSERVICE flexibility / adaptability. However, when talk of performance turns to PASE c code, often, ‘toolkit’ complicity for each language seems to go logarithmic.

We need more ‘mixed’ research here.


A generalized topic of 5250 screen scraping, with eye to near zero investment of existing code impact has been tendered by Aaron. Frankly, as i have never used a screen scraper, i may be either best or worst possible comrade for a group 5250 project. In any event, sounds interesting for a side toolkit Common topic meeting.

5250 XML #1 - What is the possibility of XMLSERVICE being used to call an interactive 5250 program?

Retrieved from
Page last modified on March 27, 2015, at 11:11 PM EST