JDE Bulk change to BATCH QUEUE in versions

I get asked this all of the time, and thought that I'd write a few notes on the topic (before I forget).  Unfortunately the queue of a version is written to central objects, not F983051 in a nice and easy place.

Note that this is going to assist you if you need to find where a batch version queue is actually at.  As it exists in a number of locations that are needed at runtime.  Starts in F98761 central objects, gets copied to the active package build central objects (pending tools release) then gets converted from there to F989999 and finally ends in cache.

The value is stored in the F98761 BLOB in both central objects and the deployed package.  Central objects being the main concern.  Once again, this is the BLOB field

select * from DV920.f98761DVC920A where RSOBNM = 'R42565' and rsvers = 'TEST';

You could tear this down with some JAVA (CLOB / BLOB) and little endian to change it in SQL - but that is going to be a little difficult.

select utl_raw.cast_to_varchar2(rsrdablob), rsobnm from DV920.f98761DVC920A where RSOBNM = 'R42565' and rsvers = 'TEST';

You'll see that the utl_raw functions in SQL don't help you enough because of the platform independent byte order.  Doh.

Anyways, let's get around.  

All we need to do is create a project, insert all of our batch versions into the project and then save a par file.  You know that a par file is a series of zip files, like a Russian Doll (jeez, I hope that is not racist).  Once you get to the bottom of your file structures, you'll find an entry like:

Which has the following contents:

<?xml version="1.0" encoding="UTF-8" standalone="true"?>
-<RDASPEC xmlns:et="http://peoplesoft.com/e1/metadata/v1.0/erptypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://peoplesoft.com/e1/metadata/v1.0" Version="TEST" Report="R42565">
-<RDARecord>
-<RDAReport PaperType="LETTER" SubSysWaitTime="0" NextTextID="965" ScaleFactor="0" LimitRowsValue="0" SourceStyleFlags="0" DSName="R42565" POTemplate="T42565" ReportFlags="0" PropertyFlags="1092">
<RDAPrintInfo RDAQueueName="QBATCH" RDAServerString1="*NONE" PageOrientation="2" PageSource="15" PageHeight="15840" PageWidth="12240" PageSize="1"/>
<et:JdeLogFont charSet="1" orientation="0" height="-14"/>
</RDAReport>
</RDARecord>
</RDASPEC>

Easy hey?  All you need to do is update the RDAQueueName above [I just write some basic code to do that] - I'm so old I use bash... and sed and awk...  And then BOOM - restore the par file that you pack back up in your scripts

for file in `ls $expDir/*.par`

  do

    #echo $file

    dir=`echo $file | awk -F. '{print $1}'`

    #echo $dir

    unzip -q $file -d $dir

done

That sort of stuff, just lots more.

So, you get back to your fat client and ensure the project is at the correct status and do a restore of the par file.  You can use UTB (as above) to check that the currently deployed package and central objects have been updated...  Nice.  Then you go and run the job - and the queue is still wrong!  Doh.

Referring to the manual (and me) says to run a quick update package, and all will be good.  But if you cannot wait for that.  Follow these steps

Goto P98770 and find the deployed package

Then write up some SQL like this: - where DVC920A is your active full package.

select * from dv920.f989999DVC920A where wboid like '%R42565%';

delete from dv920.f989999DVC920A where wboid like '%R42565%';

commit;

Then you run it again and it still does not work... WHAT!!!

Oh, delete the cache from the web instance!

BOOM!

Now, you can look at the F989999 and see the NEW QUEUE defined

select wboid,utl_raw.cast_to_varchar2(WBJPO) from dv920.f989999DVC920A where wboid = 'RPTJOBQUEUE-R42565-TEST';

Note how consistently inconsistent JDE is, if you run the command above, you'll see that the job queue can be read (and written by a human).  So if you were a REAL cowboy and had to change the queue on the "superfly" - you might be able to manipulate the F989999 and clear cache only.  I would only attempt that if I was desperate (or in a rush... or wanted a rush)...

I'm still working on the script for the actual bulk queue change, else I might just post it here.  I believe I've provided everything you need to get this done yourself.