× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.