You have to start it manually once QSPL subsystem is running and the device varied on. In the shipped QSTRUP program, it is done with this QSYS/QWCSWTRS program.I had a closer look at that and CALL PGM(QSYS/QWCSWTRS) will only be run when the QSTRPRTWTR system variable is set to on. It can't be changed from WRKSYSVAL. I guess this can be set only when doing a manual IPL on the according screen.
When doing an automatic IPL, QSTRPRTWTR is set to 1. Still, the writer doesn't get started at IPL time.
I think that the writer *should* get started at IPL time but can't because when the end of QSTRUP is reached, TCP/IP isn't yet ready for socket creation. I have faced this problem with my own applications, too. Thus I've included a socket(), check return value, sleep 1, try again loop in each of those, so they will eventually succeed. Apparently, IBM didn't do this for TCP printer writers. At least not in V4R5. :-)
Well, I don't IPL *that* often, but I regularly do save 21, so I might at least try to solve part of the issue.In both cases, controlling subsystem and QSYSWRK are started, and program from QSTRUPPGM system value is invoked in QSTRUPJD job. However, most probably the devices are already VARIED ON when running a save 21 while we do not really know their status after an IPL.
Thanks for your valuable hints!
If you want to make it automatic, you can add an autostart job entry, similar to the one which starts remote writers, to QSPL subsystem which will run this QSYS/QWCSWTRS program (preferred solution) or STRPRTWTR DEV(*ALL) (or DEV(WOHNZIMMER) in your case).QWCSWTRS is doing a lot of things, when looking at it's source. :-)
I'll try that out!
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.