XDN listener must be started manually

[Former Member]

We have made the change from XDA to XDN as per OSS note 1257635. I have also modified QSTRUP as per note 1703667. QXDAEDRSQL starts up just fine and STRRMTDB runs. However, the listener job (XDNDEVLSN) does NOT get started. If I log on as DEVADM and start it manually, it starts just fine. This sounds like an authorization issue but I can't find any logs or joblogs indicating this. Can someone tell me what is going on?

Thanks,

Rick

[Former Member · Accepted solution]

Hi Rick,

which version of XDN did you activate ? With port 963 "for the complete iSeries" or with port 39nn "per SID" ?

... in the first case, it would be normal, that the job would be missing, because it wouldn't be needed at all (even when I do not recommend that setup ...)

Regards

Volker Gueldenpfennig

[Former Member · Accepted solution]

Hi Volker - the per SID (actually it's port 96nn). If the XDN listener job is not running, I will have dozens (hundreds if I'm not fast) of SQL dumps. I even put a DLYJOB DLY(120) after the start of QUSRWRK in QSTRUP to make sure that QXDAEDRSQL was started (and it was). I feel like I'm missing something obvious here.

[Former Member · Accepted solution]

Hi Rick,

oh yes, sorry - the port is indeed 96nn ;-))

What XDN parameters did you activate in detail ?

I guess, you are using dbs/db4/allow_cancel - I would strongly recommend, to remove that, except, when you would really need this feature (I do think, I do have no customer, that needs that).

=> the XDN server is no longer critical for you in my eyes (even when it should be up in general)

Regards

Volker Gueldenpfennig

[Former Member · Accepted solution]

Hi Volker,

The only parms I know of are:

dbs.db4/driver_type = XDN

dbs/db4/xdn_port = 9601

dbs/db4/xdn_trace_file = XDNTrace

It's the listener job that won't start automatically.

[Former Member · Accepted solution]

Hi Rick,

then, I'm running out of ideas offline ...

You could open a ticket with bc-db-db4 ...

Regards

Volker Gueldenpfennig

[Former Member · Accepted solution]

I think I'm going to try this CALL from OSS note 1434967 inside QSTRUPPGM:

CALL PGM(XDNCONTROL) PARM('SpawnListener'

'pf=/usr/sap/<sid>/SYS/profile/DEFAULT.PFL' '-priority20'

'-jobqueueQUSRNOMAX' '-wait120')

It's supposedly for distributed systems, which we aren't really, but it does what I want; At least I think it will. It's kind of hard to test stuff that requires an IPL!!

[Former Member · Accepted solution]

FWIW, this call to XDNcontrol did NOT work.

However there is CL code in OSS note 71085 to create a program called STRSAPSYS which holds great promise. It sets all the environment variables for a given instance with a call to R3INLPGM before calling STARTSAP. First test is good. My apologies to anyone who was offended by my earlier comments. (shouldn't let frustrations out on a talkboard)

[Former Member · Accepted solution]

The CL program in OSS note 71085 solves my problem. I don't know why this is an issue with the XDN driver but it was not with the XDA driver, but at this point I don't care. Thanks.