cmd call with output parameters

[Steven Scott]

Hey guys,

I've been looking at making an iToolkit alternative for Node based around db2sock and its JSON transit format, and noticed that the base toolkit/XMLSERVICE combination uses 'rexx' to call CMD objects with return parameters.

It doesn't seem like db2sock has something like this implemented yet, and was wondering what the plan was in this regard. Is this something that will be added to db2sock in the future, or will it need to be handled by some external method?

[Former user]

call CMD objects with return parameters ... db2sock ... Is this something that will be added to db2sock in the future, or will it need to be handled by some external method?

Short answer: Yes. db2sock will add json call cmd i/o and json call shell (qsh, pase shells).

call CMD objects with return parameters ... a little whining

Longer answer (with whining): IBM i is unique having commands with input/output parameters (RTVJOBA). In fact, from Unix shell perspective, whole idea of IBM i I/O parameters is an abomination against all that is terminal (shell). Green screen QCMD can't even handle calling RTVJOBA. The manual dances on the head of a pin explaining why you need to use CL or Rexx (or a toolkit in java, php, etc.). My opinion, command I/O like RTVJOBA is directly attributed to IBM i mad scientist left too long in cold Rochester weather (see, told you, a little whining).

So, my personal feelings exposed, we have a choices ...

1) Force customers to write CL programs to wrapper IBM i commands with I/O (RTVJOBA) ... db2sock takes a stand calls PGM, SRVPGM, CMD, but not cmd i/o (later RTVJOBA).

2) Enable rexx call CMD I/O (like xmlservice) ... db2sock gets a D- grade, but better than nothing.

3) Rip command I/O calling guts out of rexx to make a 1st class handler ... db2sock spends a month chasing the command I/O unicorn (i hear unicorns be fluffy).

My opinion, db2sock takes path of least resistance (is futile), and again uses simple rexx program like XMLSERVICE. Aka, D- grade work, for a D- grade command I/O problem.

Do you have a different opinion?

[Steven Scott]

I agree with you, I'm not a fan of how XMLSERVICE uses rexx to call CMD's, but it is still better than nothing.

I'd probably go with the path of least resistance, at least initially. And in the future, maybe someone will have the time and motivation to dig into a better alternative.

[Former user]

... XMLSERVICE uses rexx to call CMD's

This is only FYI. For the record ... actually XMLSERVICE allows three different ways to call CMDs (exec='cmd|system|rexx'). So, choice of CMD call 'weapon' is largely up to toolkits. Aka, whim of a language toolkit author. XMLSERVICE was largely agnostic to any of these three methods. Of course, human equation prevails, wherein commands with i/o parameters (like RTVJOBA), every toolkit ends up going with rexx (exec='rexx'). The unspoken truth being nobody knows how to do this dynamically as 1st class API. To wit, me included, but i think CMD I/O paramters is just crazy anyway, aka, D- xmlservice API for D- rtvjoba problem (you will be assimilated; resistance is futile).

      * ---
      * <cmd [exec='cmd|system|rexx'
      *       hex='on' 
      *       before='cc1/cc2/cc3/cc4'
      *       after='cc4/cc3/cc2/cc1'
      *       error='on|off|fast'
      *       ]>values (see IBM i *CMD)</cmd>
      * ---
      * cmd         - command tag
      *  values     - (see IBM i *CMD IBM i- 5250 cut/paste)
      * options
      *  exec 
      *     cmd     - qcmdexe only return true/false (default)
      *     system  - system utility return CPFxxxx
      *     rexx    - rexx output parms and return CPFxxxx
      *                 (?) character type
      *                 (?N) explicit cast numeric

Anyway ...

[Former user]

... probably go with the path of least resistance, at least initially. And in the future, maybe someone will have the time and motivation to dig into a better alternative.

Ok. Will try to add soon.

[Former user]

Ok, added rexx based command i/o option, slightly better xmlservice, and chroot safe.

• Yips Driver - 1.1.0-sg6 - toolkit added rexx for command I/O (RTVJOBA)

bash-4.3$ test1000_sql400json32 ../json/j0341_cmd_rexx_rtvjoba 
input(5000000):
{"cmd":{"rexx":"RTVJOBA CCSID(?N) USRLIBL(?) SYSLIBL(?)"}}


output(276):
{"script":[
{"cmd":["STRREXPRC SRCMBR(CMDIO) SRCFILE(DB2JSON/QREXSRC) PARM(''3 RTVJOBA CCSID(?N) USRLIBL(?) SYSLIBL(?)'')",
{"records":[
{"CCSID":"37"},
{"USRLIBL":"QGPL       QTEMP      QDEVELOP   QBLDSYS    QBLDSYSR"},
{"SYSLIBL":"QSYS       QSYS2      QHLPSYS    QUSRSYS"}
]}
]}
]}

result:
success (0)

[Former user]

Ok, better added rexx based command i/o option errors (json joblog). Added simple db2sock/tests/json RTVJOBA test, bad rexx command, etc.

• Yips Driver - 1.1.0-sg7 - toolkit finish cmd i/o rexx errors, plus escape single quote cmds

Are you verifying this support meets needs?

[Former user]

Scott, You should consider adding your bitbucket id to watchers of db2sock project. This will give you email response when i complete your task(s). Aka, stuff moves fast for these easier items, couple of days or less common.

[Steven Scott]

Tony that's awesome! Wasn't expecting it to get done that fast.

I'll take a look at the changes later this afternoon or tomorrow, and let you know if I run into any issues.

[Former user]

As long as you are testing ... Can you check new qsh commands (added today).

Yips Driver - 1.1.0-sg8 toolkit add qsh command processing

FYI -- Some qsh shell tests in db2sock/json, but not enough to really know much.

bash-4.3$ test1000_sql400json32 ../json/j0361_cmd_qsh_ls   
input(5000000):
{"cmd":{"qsh":"ls -1 /QOpenSys"}}


output(678):
{"script":[{"cmd":["ls -1 /QOpenSys",{"records":[
{"R1":"QIBM"},{"R2":"QOpenSys"},{"R3":"QOpenSys.bak"},
{"R4":"QSR"},{"R5":"bin"},{"R6":"builder"},{"R7":"cert"},
{"R8":"cert.crt"},{"R9":"cert.key"},{"R10":"cert.p12"},
{"R11":"certificate.p12"},{"R12":"certificate.pem"},
{"R13":"chroot1"},{"R14":"db2sock"},{"R15":"dev"},
{"R16":"etc"},{"R17":"home"},{"R18":"lib"},
{"R19":"lib64"},{"R20":"mydebug.txt"},
{"R21":"new_chroot"},{"R22":"node4"},{"R23":"node6"},
{"R24":"opt"},{"R25":"pkgs"},{"R26":"ranger"},{"R27":"sbin"},
{"R28":"tmp"},{"R29":"tools"},{"R30":"tools-internal"},
{"R31":"usr"},{"R32":"vac101"},{"R33":"var"},{"R34":"yum"},
{"R35":"yum2"},{"R36":"zend5"},{"R37":"zend7"}
]}]}]}

result:
success (0)
bash-4.3$ 

[Steven Scott]

Hey Tony, one thing I noticed while building the new rexx code is that if the "QREXSRC" file doesn't exist yet, 'make rexx' fails on the dltf call.

This can be worked around by adding a dash (-) before the dltf call in the makefile, the error will still be output (*FILE not found), but the next commands continue to execute, and the error cleans up after the file exists, so the second run works with no error output.

cpyrexx:
    -dltf --lib $(ILELIB) --file QREXSRC
    crtsrcpf --lib $(ILELIB) --file QREXSRC --option "RCDLEN(92) MBR(*NONE) TEXT('rexx')"
    cpyfrmstmf --from cmdio.rexx --to /qsys.lib/$(ILELIB).lib/QREXSRC.file/CMDIO.mbr --option "STMFCCSID(819) DBFCCSID(37)"

[Former user]

-dltf --lib $(ILELIB) --file QREXSRC

done. thanks.

BTW -- New version fix a few 'bad characters' qsh output json that are actually next line. I really don't expect everything to work 100% with new rexx and qsh, but ... well ... maybe get lucky testing.

[Steven Scott]

Ran a couple quick tests over cmd with output and qsh calls, and they seem to be working well.

I haven't done exhaustive testing, just a few dir listings, and command calls for qsh, and a couple random calls for cmd. But everything I did try seemed to work well

[Former user]

Great. Thanks for your help checking the new support. We will continue to refine json interface until a formal release (next year). We will include a full DB2 driver completely json based (your toolkit can be really good).

Please open new issue should need arise. Thanks again for your support.