Re: Autostart Printer Writer not working

Le 01/03/2023 à 21:19, Patrik Schindler a écrit :

Hello Marc,

Hello

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.

Correct.

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. :-)

You are probably right here, except that IP is not started when trying to start the writers, not at the end of QSTRUP.

I have used another way in the past to check IP stack status. It was required in order to start inetd service, which is used by PowerHA. If IP stack is not active, inetd did not want to start. However I am not sure that my way works properly in the context of a 150 system pretty slow ;-) .

In a modified QSTRUP program, I was using a ping with a high number of packets and wait time (time out on each packet). Something like PING NBRPKT(999) WAITTIME(5). I was pinging the default gateway IP address (which, of course, was allowing icmp requests). The PING command was running until both IP stack and interface are active, once the ping succeeds, or once 999 packets were sent. 5*999 is about 5000 seconds which sounds reasonable for IP and interface to get ready. It can be changed however. The interest is that you do not have to write any loop for that. When the gateway becomes reachable, remaining of 999 packets will be sent quickly, and the ping command will end. You can, immediately after, start QSPL subsystem and start the writers with QSYS/QWCSWTRS program and start your applications.

There are API to help (for instance Retrieve TCP status), but a lot of them were introduced with V5R1.

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. :-)

Basically, using APIs, it produces a list of printers devices in a user space, browses this user space to retrieve the status of the device, and with some retries and delays, it starts the printer writer when the device is varied on. There is nothing inside related to IP.

I'll try that out!

Again, thanks!

Welcome!

:wq! PoC