Welche Aufrufe lösen einen zusätzlichen Thread aus?

[hel400]

Nicht immer an das Gute glauben ... :-)
Anruf gestern (Montag) eines Kunden.
Ich: Bitte Remotesoftware (PCvisit) laden und starten.
Kunde: Wenn ich das starten will steht "Verlangt mindestens XP-SP2"
--> Der war also DARUNTER!

[Fuerchau]

Ist der Kunde u.U. das Computermuseum in München?
Zumindest haben die mit Hackerangriffen überhaupt kein Problem, da die Hackersoftware auch mindestens XP-SP3 voraussetz.

Und was QDLS angeht: Wie kommen die dann noch mit den 8.3-Namen zurecht;-)?

[Edefauler]

Und was QDLS angeht: Wie kommen die dann noch mit den 8.3-Namen zurecht;-)?

Das ist richtig pfiffig gelöst: Dateiname = Programmname (8-stellig) + '.ZIP'
Die Jobs werden in eine JOBQ gestellt, in der nur ein Job zulässig ist... mannmannmann...

[Fuerchau]

Pfiffig? Da dürfen Programmnamen ja auch nur 8 statt 10 Zeichen lang sein. Was für eine Verschwendung.

Damit bekomsmt du zwar QDLS nicht weg, aber es läuft dann auch:

Erstelle ein neues Subsystem und schiebe die Jobqueue dahin.
Anschließend änderst du das Subsystem auf single threading:
https://www.ibm.com/support/pages/subsystem-single-or-multiple-threads

[Edefauler]

...das 'pfiffig' war ironisch von mir- ich finde die Vorgehensweise dezent angestaubt ;-)
Naja- es ist eben eine über Jahre gewachsene Ansammlung an Programmen, die eben noch den SNDDST verwenden (seit welchem Rel. gibt´s den SNDSMTPEMM?).

Das von dir verlinkte Dokument hatte ich schon gefunden- es hilft mir nur leider nicht:

Die problematischen Jobs laufen im SBS QBATCH mit der QDFTJOBD. Hier wurde von uns bezüglich Multithreading nix verändert- somit sollten die Jobs eigentlich als Singlethread laufen.
In diesen Jobs werden SQLs aufgerufen- und dort entstehen (sobald der Sysval QQRYDEGREE abweichend zu *NONE gesetzt ist) mehrere Threads (SQL-Optimizer).
Das SBS ist dabei nach wie vor als Single definiert.

Aber ich glaube ja eher dass es den Jobs in einem SBS völlig egal ist, ob das SBS als S oder M definiert ist. D. h. ich glaube nicht, dass ich einen Job mit "CALL QWTMAINT PARM(1 7 SBS BIB S)" dazu zwingen kann als Singlethread zu laufen.

[Fuerchau]

Das bleibt eben auszuprobieren. Wenn das Subsystem dies verweigert, dürfte auch SQL das nicht dürfen.
Aber da kann auch eine QAQQINI helfen:
PARALLEL_DEGREE ist eine einstellbare Option.
Du kannst im SBSD eine zusätzliche Subsystemlib einstellen und dort eine QAQQINI erstellen.
Dann würde Batch eben nicht von der Parallelausführung im SQL profitieren, der Dialog und andere SBS' schon.

Es gäbe noch eine interessante Variante:
SQL im Servermode:
http://www.redbooks.ibm.com/abstracts/tips0658.html

Du brauchst also nur das API QWTCHGJB() mittels Vorlauf-Programm aufzurufen und SQL's werden in einem Serverjob gehosted. Das habe ich ganz früher mal ausprobiert (bevor das mit den ACTGRP's ging) und funktioniert reibungslos.

Es gibt doch bestimmt ein zentrales Service-/Programm, dass von jedem Programm initial aufgerufen wird. Dann kann man dies darüber gut steuern.
Das Mulitthreading findet dann im Serverjob statt.

[Edefauler]

Eine separate QAQQINI für diese Jobs scheint mir eine prima Idee zu sein.
Momentan können wir zwar mit einem QQRYDEGREE *NONE gut leben, ich werde aber mal rein vorsorglich diese Jobs in ein separates SBS verlegen.

Merci
Ede