Mit java in ein bestimmten Spool schreiben.

[LoCal]

Hallo,

ich hab mal ne Frage:
Wenn ich mit System.out.println() was ausgebe wird das ja in die QPrint geschrieben. Im Prinzip langt mir das ja, aber nun ist es doch ne Anforderung, dass ich das in einen bestimmten spool schreibe.
Gibt es dafür ne spezielle klasse in der Toolbox?
Und kann ich irgendwie den namen vom Anwender rauskriegen?

Danke schonmal,

LoCal

[BenderD]

Hallo,

ad 1: was heißt hier bestimmter Spool? Ein Spool ist immer dem Job zugeordnet und kann nicht cross Jobs verwendet werden. Ansonsten => Toolbox Doku (tue ich mir nicht an, ich würde da ein Streamfile als log nehmen)

ad 2: System.getProperty("user.name") ist Dein Freund

Dieter Bender

ad2:

Hallo,

ich hab mal ne Frage:
Wenn ich mit System.out.println() was ausgebe wird das ja in die QPrint geschrieben. Im Prinzip langt mir das ja, aber nun ist es doch ne Anforderung, dass ich das in einen bestimmten spool schreibe.
Gibt es dafür ne spezielle klasse in der Toolbox?
Und kann ich irgendwie den namen vom Anwender rauskriegen?

Danke schonmal,

LoCal

[LoCal]

Hallo,

ad 1: was heißt hier bestimmter Spool? Ein Spool ist immer dem Job zugeordnet und kann nicht cross Jobs verwendet werden. Ansonsten => Toolbox Doku (tue ich mir nicht an, ich würde da ein Streamfile als log nehmen)

Sorry, hab mich falsch ausgedrückt. Bzw. kann schon leicht falsch bei mir an.
Also bei uns haben User teilw. andere Drucker als Standard hinterlegt. Und genau auf dem soll die Ausgabe erfolgen.

ad 2: System.getProperty("user.name") ist Dein Freund

Dieter Bender

ad2:

Ja, das ist mir auch nach dem posting eingefallen. Allerdings taugt das nicht so ganz für die JDBC anmeldung... also user.name schon.. aber passwort kommt keines mit.

Trotzdem vielen Dank.

[BenderD]

Hallo LoCal,

ad 1 müsstest Du mal bei den Konstruktoren von dem Spool Scharmonz nachsehen, oder bei irgendwelchen Settern, da müsste man erwarten z.B.: ein Printfile angeben zu klönnen und daran kann man dann sowas vernageln.

Zu der JDBC Anmeldung, die kann man bei lokaler Datenbank (zumindest bei dem sogenannten native Driver) auch für current ohne Kennwort machen (siehe Treiber Doku). Hört sich allerdings alles danach an, als ob Du da für jeden Job eine JVM aufmachst, das kann kaum gut gehen, was die Skalierbarkeit und den Ressorcenverbrauch und die Performance angeht.

mfg

Dieter Bender

Sorry, hab mich falsch ausgedrückt. Bzw. kann schon leicht falsch bei mir an.
Also bei uns haben User teilw. andere Drucker als Standard hinterlegt. Und genau auf dem soll die Ausgabe erfolgen.




Ja, das ist mir auch nach dem posting eingefallen. Allerdings taugt das nicht so ganz für die JDBC anmeldung... also user.name schon.. aber passwort kommt keines mit.

Trotzdem vielen Dank.

[LoCal]

Ja, ich mache für alles ne VM auf. Aber als Server Job möchte ich das hier nicht so ganz laufen lassen bzw bin ich mir nicht sicher, ob das hier so gern gesehen wird.
oldschool wäre noch geschmeichelt.. IMHO

[BenderD]

Hallo,

für jede AQnforderung eine VM aufzumachen ist im Endeffekt eigentlich immer tödlich. Spätestens, wenn das in allen interaktiven Jobs passiert ist die Möhre um (einfache Rechnung: Hauptspeicher - Anzahl der Jobs * Grösse der JVM < 0 => Möhre tot)

Ja, ich mache für alles ne VM auf. Aber als Server Job möchte ich das hier nicht so ganz laufen lassen bzw bin ich mir nicht sicher, ob das hier so gern gesehen wird.
oldschool wäre noch geschmeichelt.. IMHO

Das hat doch auch Vorteile, wenn man nicht zuviel fragt, wie man das machen soll (schließlich fragt Dich Dein Bäcker auch nicht, wie er das Brot backen soll).
Da schreibt man sich einen einfachen Java Server Dienst, dem man eine Anforderung in eine DTAQ stellen kann (wenn die keine Sockets haben wollen) und der dann eine Antwort in eine AntwortQ stellt. Drumherum für einfache Benutzung ein kleines CL, RPG oder COBOL Programm, dass man mit einem einfachen Call bedient und das den ganzen Asynchron Mechanismus inklusive Connect an den Java Serverdienst maskiert.

Vielleicht gleich hinterher noch einen RPG basiertes Pendant, damit man sich den ganzen Toolbox Zinnober mit Spoolfiles etc. im Java ersparen kann.

mfg

Dieter Bender

[LoCal]

Stimmt schon. Also das mit dem Speicherfrass und so. Es laufen hier aber eh nur drei Programme mit Java. Zwei davon nur sehr sporadisch und das andere zwar sehr oft, wird aber eh durch eine JobQ dazu gezwungen dass es nur einmal läuft.
Das die von mir verwendete Methode sehr unelegant ist, bin ich mir bewusst. Aber:
- ich bin froh dass ich übhaupt java daruf laufen lassen darf
- muss ich gestehen, dass ich mit der ganzen AS/400 umgebung nicht extrem tief vertraut bin. Und bevor ich irgendwas zerschiesse mach ich es auf dem sichersten weg.
- Können die Sysadmins hier kein Java und würden bei einem eventuellen Serverjob auch (aus prinzip?) keinen finger rühren wenn das was schiefläuft. (Kommt mir zumindest so vor.)

[Fuerchau]

Mir stellt sich nur die Frage was du hier mit Java lösen musst, was du mit RPG/LE usw. nicht lösen kannst !?

[BenderD]

@Baldur

Mir stellt sich nur die Frage was du hier mit Java lösen musst, was du mit RPG/LE usw. nicht lösen kannst !?

ich bevorzuge hier die Frage, was man hier eigentlich noch mit rpg lösen muss, wenn man doch Java kann.

Dieter

[LoCal]

@Baldur
ich bevorzuge hier die Frage, was man hier eigentlich noch mit rpg lösen muss, wenn man doch Java kann.
Dieter

Jap, auch wenn ich RPG lernen musste, so hege ich doch ein sehr tiefe Abneigung gegen diese Sprache.
Liegt wohl daran, dass ich doch etwas zu jung für RPG bin