outqueue

is there a way that when i run a report from oneworld that i can put it in a different queue on the as400 rather then putting it in the standard queue qbatch.
is there an option to define that program r55vrk22 version fin0003 always runs in queue qbatch2.

If your using Security Server, the System Roles JOBD can be used to specify which jobq by default. The ES JDE.INI can specify a one queue for all. The workstation ini can specify a queue for anyone using that machine (or by user if TSE). The UBE itself can be sent to a specific JOBQ with the submit options.

Ck your version out then change the Job Queue on Version Detail to run =
in your qbatch2 then ck it back in.

Carrie Ricotta
Project Manager/Senior Consultant
M&D Information Systems, Inc.
407-808-8455
775-719-9912 Fax

"The Extra Mile Isn't Crowded" - Bradley Allen
----- Original Message -----=20
From: Herman=20
To: [email protected]=20
Sent: Wednesday, February 04, 2004 7:44 AM
Subject: outqueue


is there a way that when i run a report from oneworld that i can put =
it in a different queue on the as400 rather then putting it in the =
standard queue qbatch.is there an option to define that program r55vrk22 =
version fin0003 always runs in queue qbatch2.
--------------------------
To view this thread, go to: =
http://www.jdelist.com/ubb/showthreaded.php?Cat=3D&Board=3DOW&Number=3D67=
286

This is the JDELIST One World / XE Mailing List. To stop receiving =
these messages, login to http://www.jdelist.com/forums, click Control =
Panel, then click Edit by "Subscribe / Unsubscribe from receiving board =
posts by email, change message notifications, etc." and adjust your =
subscription preferences. JDEList is not affiliated with JDEdwards



M&D Information Systems, Inc.

Sure. You could setup job-descriptions on your 400 and submit a CLP under that JOBD that calls RUNUBE.

I don't have a 400 in front of me, but that's how I remember it being done. The JobD maintained which job-que the CLP would run in... RUNUBE would inheret that location.

hth!

I am on SP22. I can change the jobq on the Version level and submit.

Hallo,

there are several ways to put reports into different job queues. If you want to run a version permanentley in a disinct job queue, you should hardcode the queue in the version. Under Revise Version (OMW) there is a field for the job queue. You should define the Job Queue in the UDC 98/JQ. Also the job queue must be defined on your AS/400 system.
If you want to use the OneWorld Scheduler application only, you can override the default job queue by definition of your scheduler job.
If you use RUNUBE on the AS/400 you can always override the jobqueue with the submitjob parameter.

regards

Thomas

Ok - its been a few days since I played on a 400... so, our terminology may
need some fixin.

All jobs from JDE actually go a single AS/400 job-queue (iactive).
JDE controls what UBE hits the processor by scheduling jobs into JDE Queues,
virtually within itself. Each JDE Queue is controlled/scheduled by JDE to
the same AS/400 queue (by default they all go to the same place)...

Am I sniffing paint and remembering things all wrong?

Daniel Bohner





Looking for work out west
Daniel Bohner | JDE P/A III | Freelance-JDE/Web/Photo
www.ExistingLight.Net | www.ExtremeSights.com | [email protected]
JDE XE | SP20 | AS/400 | V5R1

If you need to change a lot of versions or need to change them often, we sell a software tool that can do this - please, e-mail me directly, if you need more details...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

We are able to manage JOBQs by using JOB Description on as400, giving JOBQ name in verion details and in case of Scheduler Jobs, Jobq can be easlily changed without checkin/out etc.,

I would like to know how the job RUNPRINT on AS400 can be made to run in a different jobq instead of QBATCH. It seems it is run for every UBE to print the output. (Is it right?)

Can anybody help?

I saw in the log (DSPMSG) that RUNPRINT is being launched by the user ONEWORLD with the Jobdescription ONEWORLD, so changed the JOBQ in JOBD to a different JobQ.
Now RUNPRINT jobs are running in a separate dedicated JOBQ. This should improve the performance a bit.