• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Obtaining UBE job number in a CHILD job

johndanter

Legendary Poster
Hi list,

I always use BSFN B984054 Get OneWorld Job Number to bring back the job number. It works like a charm. I then use this happily enough to go and do various job number related things. Mainly email the output as an attachment

However...............

Now I need to do the same in a Child job. So UBE 1 calls UBE2 and what seems to be happening is the BSFN is always bringing back the Parent job number of UBE1. I need UBE2

Now they share the same ProcessID but I can't really add +1 to the Parent job # as E1 isn't always as simple as that with it's job numbers :)

I can't use the API in UBE1 to call UBE2 as I can't have UBE1 wait for UBE2 to finish and produce the output file

I could use the ProcessId and Job # to look on F986110 using table IO?


Any ideas?
 
Last edited:

johndanter

Legendary Poster
Fixed

What I do is use table IO to look at F986110 where JOBNBR > parent job number and a matching PROCESSID and FNDFUF2

I pass this child job # value back to Parent UBE1 whereby any subsequent calls of UBE2 can now perform the same select to find a JOBNBR # than the parent and then on future calls, the last child JOBNBR
 

johndanter

Legendary Poster
EDIT:

NOT Fixed :)

It appears the F986110 record is committed or inserted AFTER the Child UBE has run. (no idea where P986110B gets it's grid data from if that's the case

So I will have to move my PDF finding code to be in Parent UBE1 after Child UBE2 ends
 
Last edited:

JEMILLER

VIP Member
Hi John,

I had started to draft a response but then saw you thought you had solved it. I hope this comes in time to help you.

The trick to getting the job # of the synchronous child *while* it is running is to use the F986114 job execution statistics table instead of the F986110. The job statistics tables gets written to for child jobs whether they are synch or asynch and when they start and end. I am not certain this will work on a 9.0 system but at tools 9.1.5.3 I believe the below should work.

I lookup the job's process id and host (in this case your parent job's info) and then do this table I/O in an NER:

=======================================================================
NAMED ER: Fetch Server Job# via Execution Host and Process ID
=======================================================================
evt_ServerJobNumber
evt_JobstatusOW
OPT: Using Defaults
0001 VA evt_JobstatusOW = "P"
0002 F986114.Open
0003 F986114.Select
BF szMachineKey = TK Execution Host Name
BF szProgramId = TK Program ID
BF szVersion = TK Version History
BF mnServerProcessID = TK Server Process ID
VA evt_JobstatusOW = TK Job Status
0004 F986114.Fetch Next
VA evt_ServerJobNumber <- TK Server Job Number
0005 If SV File_IO_Status is equal to CO SUCCESS
0006 BF mnServerJobNumber = VA evt_ServerJobNumber
0007 End If
0008 F986114.Close

I use FoundationGetProcessId (B0000024) to get the UBE process id and GetAuditInfo (B9800100) to get the Machine Key.


I have built a mass invoice print parent/child approach to allow one of my sites to run 30,000 invoices and statements in a parallel split run that which then in turn feeds to Bottomline Transform. The requirement is to wait until all processing in both JDE and Transform is done before collecting all the output and send it to an offsite printing/mailing provider. I use the F986114 and a tracking table to allow each child job to figure out if they are the "last child" and decide if the final processing should be kicked off to bundle up all the output and FTP it to the printing provider. I originally left off a search for Status = P which was a bug that didn't hit us until a few months after go-live when we eventually had enough job history that the same UBE/Version, Server, Process ID crept into the F986114. By using Status "P" you know you are looking at the active jobs under that process id Since that fix the lookup in the F986114 has totally reliable for child job identification.

What led me to this solution was the Execution Details WSJ row exit. I noticed that if you choose Execution Details for a parent job of a synchronous child(ren) that it displays all the synch children. (App P986114A, Form W986114AB).
 

johndanter

Legendary Poster
Legend, thanks Justin

I can do this I/O in any event?
Do you need to anything special to F986114? No overrides needed? Just a simple Table IO?

I was looking at my log and I could see the F986110 is written (committed) when control returns to the parent.
I did see inserts to F986114 with that child job # alright occurring much earlier in the log:) So it's good to have a hunch confirmed.


Thanks again
 
Last edited:

JEMILLER

VIP Member
Glad to help John,

Yep, you can do this in a simple table I/O and should not need a DS override since you are doing this inside the UBE which then gets its F986114 map from the Server Map for the server it is executing on.

To be clear, the default mapping in the Client OCM (System - 9xx) is still System - 9xx just like the F986110. So if you wanted to view this table from a client you would need the override. I believe the Execution Details form is already using a DS override on the F986114 since it is coming off the WSJ application which does the override on the way in.
 

johndanter

Legendary Poster
Awesome, this is fantastic.

For now I got my code working by letting the child end and work out the parent job # in the child End Report event. I passed this back to the parent and then did the F986110 SQL (as the Child F986110 get written as the child ends)

I may do your code in phase II of this as I'd like to let be asynchronous so it's faster

Thanks again
 
Top