SYSVAL AUTOVRT

[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.

[Pikachu]

Also bei IBM i sind die Jobtabellen wohl permanente Objekte auf Festplatte.

Aber bei Unix sind die Prozesstabellen wohl temporäre Strukturen nur im Arbeitsspeicher!?

[Fuerchau]

Vielleicht schaust du mal selber nach oder fragst dich im Unix/Linux-Forum durch.
https://github.com/torvalds/linux
Es mach ja keinen Sinn, Prozesstabellen zu speichern.
Die IBM i speichert auch keine Informationen über aktive Jobs (Prozesse), sondern nur eine Job-Infotabelle um dann die toten Jobs festzustellen und die zu eliminieren, die keine Ressourcen belegen.

[Pikachu]

Hier steht etwas von IBM zu diesen Jobtabellen in IBM i.

(…) The work control block table (WCBT) is also called the Job Table. (…)

The WCBTs are tables of entries, each of which provides part of a permanent nucleus in the system for each job that is active, on a job queue, or has spooled output. (…)

Also stehen in diesen Jobtabellen auch Informationen zu jedem Job der aktiv ist oder in einer Jobwarteschlange steht oder Spool-Ausgabe hat.

[Pikachu]

Das erklärt doch auch daß bei IBM i nach einem abrupten Abschalten des Systems das nächste IPL die Jobs die aktiv waren beendet und deren Jobprotokolle schreibt!? Das geht ja aber nur wenn auch die Informationen über die aktiven Jobs permanent auf Festplatte stehen.

Bei anderen Systemen ist nach einem abrupten Abschalten des Systems einfach alles weg weil nur temporär im Arbeitsspeicher und beim nächsten Einschalten wird alles normal neu aufgebaut!?

[Fuerchau]

Ohne Akku gibts die Informationen dann auch nicht;-).