system commands and multithreaded

[abmusse]

Original report by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

See below for issue creating a user when system -i vs. just system is used. I would have expected the opposite of this given the description of the -i option in the documentation:

Run the CL command in the same process (IBM i job) where the system utility runs. When option -i is omitted, the CL command is run in a separate process that is created using the ILE spawn API. This separate process is not multithread-capable unless you set the ILE environment variable QIBM_MULTI_THREADED to Y. Many CL commands are not supported in a multithreaded job.

$ system -i "CRTUSRPRF USRPRF(USR1) PASSWORD(xxxxx)"
CPD000D: Command *LIBL/CRTUSRPRF not safe for a multithreaded job.
CPF0006: Errors occurred in command.
$ system  "CRTUSRPRF USRPRF(USR1) PASSWORD(xxxxx)"
CPI2221: Special authorities granted *NONE.
CPC2204: User profile USR1 created.

What are the ramifications of running system without -i? My guess is it would allow processing to continue before the previous CL command had ended and thus have hard to debug consequences.

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Closing as this appears to be an issue on my system (bleh).

The :sh option has been implemented and is a workaround for now.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Not PTFs ... will be your changes

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Something's wrong on my system. Just went looking at some past copy/paste stuff and the below line used to work and now it doesn't unless I take -i off. My guess is either I broke something (I don't know how I could have) or the most recent PTFs I loaded caused it to break.

system -i 'dltusrprf e01'

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

Well, i am losing track, but dropping :system, replaced by generic :sh, may also work.

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Doing CRTUSRPRF with -i fails (the user does not get created). The bigger issue is CRTUSRPRF only works in multi-threaded mode, when that is the mode it seemingly should not work, per the warning. Seems like a bug.

then do you want two kinds of directives :system and :systemi or something like this???

That would work. I can see how this could grow into many different versions of :system-andsomeotheroption. It is for that reason I've created a :sh entry for one-off commands that shouldn't be part of our spec but needs to exist for flexibility.

It looks like the following. I haven't put this into git yet because I've only just started testing it.

function chroot_sh {
  cmd=$(echo "$1 $2 $3 $4 $5 $6 $7 $8 $9 ${10} ${11} ${12} ${13} ${14} ${15} ${16} ${17} ${18} ${19} ${20}" | sed -e 's/[[:space:]]*$//')
  echo "chroot $CHROOT_DIR $cmd"
  if (($CHROOT_DEBUG==0)); then
    chroot $CHROOT_DIR /QOpenSys/usr/bin/bsh -c "$cmd"
  fi
}

Then an entry in chroot_myversion.lst looks like this:

:sh  
system "CRTUSRPRF...."

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

I think most commands actually work, but simply offer an error message "not multi-thread safe ... yack, yack ... user beware" ... i assume you command actually worked, yes?

I dunno about 'to -i or not to -i", due to above, please experiment and see if message goes away. And, if message does go a way, then do you want two kinds of directives :system and :systemi or something like this???