SYSVAL AUTOVRT

[Fuerchau]

OUTQ eher nein. Wobei z.B. im Windows-Printserver in der Warteschlange durchaus noch Ausdrucke warten können. Das regelt aber der Prozess "PrintQueues".

Eine JOBQ ist im Windows mit Aufgabenplanung gleichzusetzen und in Unix mit cron-Tables.
Das sind halt wartende Jobs, die irgendwann dran, aber noch nicht gestartet sind.
Eine JOBQ (mit Subsystemen) direkt ist mir nicht bekannt, es gibt da aber bestimmt genug Werkzeuge, die sowas auch wieder anbieten.

OUTQ ist ein Fall der IBM i, da dort halt Jobs geparkt werden, die noch Ressourcen haben, i.W. wartende Joblogs oder eben Spools.

Im Windows/Linux sind nach dem Neustart alte Prozesse erst mal weg, im Gegensatz zu Hibernate oder Standby.
Allerdings kann es da auch jede Menge Schrott im System geben, da es keine automatischen Aufräumprozesse gibt. Diese muss man selber anstoßen.
Z.B. Plattenbereinigung und Löschen von %TEMP%-Verzeichnissen, da viele Programme vergessen hinter sich aufzuräumen.
Das währe ähnlich den Bereinigungsaufgaben der IBM i.

Temp's gibt es auch gerne bei der IBM im IFS/PASE.

Windows ist da besonders schlimm, da es viele Standorte von Schmutzdaten gibt:
%TEMP%, %APPDATA%, %LOCALAPPDATA%, %DriverData%, %ProgramData%.
Zusätzlich noch im Systemverzeichnis von Windows.

[Pikachu]

Das erklärt warum IBM i alle Jobs (wegen Status JOBQ oder OUTQ) in permanente Objekte schreiben muß aber andere Betriebssysteme bei denen nach einem Neustart sowieso alle Jobs oder Prozesse oder wie das da heißt weg sind dies nicht machen müssen!?

[Fuerchau]

JOBQ sind nicht gestartete sondern geplante Jobs und daher als Objekte auch sichtbar.

Das hat auch den Effekt, dass ein aktiver Job eine JOBQ bremst und nach dem Neustart dann die Folgejobs noch ausgeführt werden.
Wenn z.B. sog. Nachtjobs in einer JOBQ durch einen wartenden Job (DLYJOB) die Queue anhält und das System neu gestartet wird, dass die Folgejobs dann plötzlich losrennen.
Das ist schon passiert, dass durch Stromausfall und Wiederanlauf am Morgen die Subsysteme wieder beendet wurden und die Datensicherung anlief.

Im Windows z.B. gibts je Aufgabe die Einstellung: falls der Job nicht gestartet werden konnte, dann gar nicht ausführen.

Und trotzdem finde ich die IBM i immer noch am besten.

[Pikachu]

Im WRKJOBSCDE gibt's *SBMRLS, *SBMHLD und *NOSBM.

[Fuerchau]

Ja, aber manche machen einen Job in eine QUEUE mit
DLYJOB RSMTIME(180000)
und submitten alle Folgejobs über Tag in diese Queue.
Ab 180000 werden diese Jobs dann alle ausgeführt.
Mit scheduled Jobs funktioniert das dann so nicht.
Vergleichbar ist das mit HLDJOBQ, SBMJOB's in die Queue und um 180000 einen Scheduled Job mit RLSJOBQ.

Vorteil: die Jobs für den Abend sind dynamisch und müssen nicht kompliziert irgendwo definiert werden.

[Pikachu]

Wobei ein Job selbst kein Objekt in IBM i ist aber trotzdem über Neustart-Grenzen hinweg im System vorhanden sein kann.

[Fuerchau]

Das ist nicht korrekt.
Ich habe mich halt mal früher mit der inneren Architektur befasst.
Alles ist i.W. eine Objekt. Ein Objektname besteht immer aus Typ, 2 Bytes, (Lib, File, usw.) einen Kontext (Lib), 30 Bytes und dem Namen, 30 Bytes.
Am besten sieht man es am Jobnamen, der ja 26 Stellen lang ist und als Objekt im Kontext der internen Jobliste steht. Jobs sind im SBS und der JOBQ als Objekte sichtbar und es gibt ja auch CMD's dafür.

Man kann per MI Objekte erstellen, die längere Namen als 10 Stellen haben.
Auch Groß/Klein-Schreibung ist möglich. Und man kann eben auch unsichtbare Objekte erstellen.
Es gibt z.B. USRSPC-API's für bestimmte Zwecke wie Listen aus API's füllen.
Als MI gibts da den Befehl CRTS, der eben einen vollen Namen haben darf.
Auch der Kontext darf da z.B. auch leer bleiben und man hat dann ein unsichtbares Objekt.
Per Pointer kann man sich mit eintsprechender Berechtigung durch das ganze System hangeln und in fremde Jobs und interne Strukturen reinschauen.

Aus der objektorientierten Programmierung ist die Definition so:
Ein Objekt ist eine Einheit, die spezifische Eingeschaften und spezifische Methoden hat.
Ein Objekt kann Eigenschaften und Methoden vererben.
Und genau dies tut die IBM i.

Das Basisobjekt hat den Typ, die Beschreibung und die Berechtigungen.
Alle anderen Objekttypen erben von diesem.
Usw. usf.;-).

[holgerscherer]

da wird zu viel unterschiedlicher Kram in einen Topf geworfen.
IBM i ist objektbasiert, nicht objektorientiert.
Jobs sind keine Objekte im Sinne der Objektverwaltung, sondern Datenstrukturen im Sinne der Hauptspeicherverwaltung.
Für den Rest verweise ich auf Leif' MI-Handbuch (sofern noch verfügbar), das hast Du gewiss auch gelesen.
Um mal zur ursprünglichen Frage zurück zu kehren:
QPADEV* *DEVD kann man ganz bequem löschen mit DLTDEVD QPADEV*
(und nicht mit DLTOBJ) Gruss an Jürgen ;-)

-h

[Fuerchau]

"IBM i ist objektbasiert, nicht objektorientiert."
Das ist reine Ansichtssache.
Meine Sofware ist objektbasiert, verwendet aber eine objektorientierte Programmiersprache;-).

Un nein, MI-Handbücher habe ich nicht gelese (außer dem Reference-Handbuch von vor 30 Jahren).
Den Rest habe ich mit bei COBOL/RPG-Umwandlungen mit der Compiler-Option *LIST angeschaut.
Da wurde sehr schön dokumentiert, wie man MI verwendet.
Ins besonders konnte man da die Arbeitsweise von RPG kennenlernen (I-Ausführung, O-Ausführung, u.v.m). Das hatte damals dazu geführt, dass ichmir tatsächlich einen MI-Compiler geschrieben hatte:
- Include geschachtelt
- Define von Macros
Und bis auf die Leseroutinen alles in MI geschrieben.
Letztlich diente dazu das auch heute noch funktionierte CreateProgram-Api.
https://www.ibm.com/docs/en/i/7.5.0?...ing-mi-program
Damit kann man on the fly effektive, dynamische Funktionen und Berechnungen bauen und direkt verwenden.

[holgerscherer]

"IBM i ist objektbasiert, nicht objektorientiert."
Das ist reine Ansichtssache.
Meine Sofware ist objektbasiert, verwendet aber eine objektorientierte Programmiersprache;-).

das ist Ansicht von Frank Soltis. Der sollte es halbwegs wissen.

[Fuerchau]

DAS Buch hatte ich auch gelesen, war das nicht aus dem 80ern? Ich habs wohl nicht mehr.
Aber damals hat man, meines bescheidenen Wissens nach, über Objekte und deren Methoden und Eigenschaften eher nicht nachgedacht.
Aber als ich mit diesen Konstrukten in den 90ern in Berührung kam (VBA, VB6, C++), dachte ich damals schon, wie die AS/400 dem schon voraus war.
Auch die Speicher-Jobliste, die ich mir damals schon mal angeshene hatte, muss ja letztlich als Objekt irgendwo auf der Platte gespeichert sein. Sonst gäbe es ja tote Jobs gar nicht.