Posting Jobs

  • Thread starter steven_lawrence
  • Start date

steven_lawrence

Active Member
I've often been warned never to run simultaneous Posting jobs. It's a rule I've always stuck to. However this morning two managers ran a post job a the same time - one A/P one G/L, and one changed their queue without checking what was in the other queue. My question to list is... what problems might have occurred ? I don't actually know what happens if you run 2 post jobs at once ! I can't see any obvious errors and both posting reports check out. Thanks for any words of comfort :) ...... Steve Lawrence, Coral Racing Ltd, A7.3 cum 10.
 
Steve,

Run the AP to GL integrity by offset. If there is a balancing error then
run the AP to GL by batch integrity (try to tighten up the selection
criteria otherwise it will run forever). If there has been a problem then
what you most likely find is that the value of the AE's created for the
batch/batches don't agree to the value of the transactions. I can help you
with some specifics then (the dreaded DFU and some JDE repost activity) if
you contact me offline.

On the G/L side try running companies in balance and also the Transactions
to Batch Headers (P007021) and Batch to Detail and Out of Balance (P007031).

When two G/L posts run simultaneously you don't always get corruption but
then again it does happen. Run the above stuff and then contact me offline
if you want some help.

Next step is to consider how to stop the users from doing this - one way
might be to revoke object authority to the CHGJOB command on the AS/400,
another is to look at what JDE does when the user takes HS 33 and maybe play
around with that.


----- Original Message -----
From: "teven_lawrence" <[email protected]>
To: <[email protected]>
Sent: Saturday, June 07, 2003 3:08 AM
Subject: Posting Jobs


rule I've always stuck to. However this morning two managers ran a post job
a the same time - one A/P one G/L, and one changed their queue without
checking what was in the other queue. My question to list is... what
problems might have occurred ? I don't actually know what happens if you
run 2 post jobs at once ! I can't see any obvious errors and both posting
reports check out. Thanks for any words of comfort :) ...... Steve
Lawrence, Coral Racing Ltd, A7.3 cum 10.



Colin Hugill
Consultant
(World A7.3 cum12)
 
Steve, I recall having an issue in version A3 when two very large G/L posts were running simultaneously, but don't recall the specifics. I would suggest you run the F0911/F0902 integrity, and that if it checks out, and both batches posted w/o errors, you should have peace of mind.
 
Hello Steven,

One problem I have come across is that record locks can occur if the same batch is included in more than one post running at the same time. This results in a part posted batch. I have been lucky on the two occasions i've come across this and the batch has posted after being changed to 'post out of balance' on batch header without causing integrity issues. I wouldn't think you'd get any locks as the posts were differing types.

Regards,

Paul Thompson.

A73 Cum 7
IT Business Analyst
Daniel Thwaites PLC
E-Mail: [email protected]
 
Steve et.al.,

I heard the admonition even more strongly once: Never ever submit two JDE
jobs to run simultaneously (very likely a rule to help avoid running posting
jobs).

What we did here is we set up one, just one, single-threaded job queue for
all the JDE work to "funnel" through, and that also avoids the posting jobs.
However, the folks running off the JDE software are few, and this may cause
a problem in bigger shops.

If there must be more, is there maybe a way to specify or override the
actual job queue on a specific menu option?

- Alan
 
A concern I have is that even though we can control which jobq is
referenced in the dream writer version (and hence that posting jobs
all run through the same jobq), it is still possible for a user to
move the job to another queue.

Is this a problem in other shops? How do you prevent it?




Chuck Bower
VP of IS
Coachmen Industries, Inc.
A73C8
 
Hello Chuck,
to answer your question directly, you can impose security on the Jobq
itself.
1. Execute cmd - WRKOBJ
Object . . . . . . . . . . . . . > QBATCH4 Name, generic*, *ALL
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB.
Object type . . . . . . . . . . > *JOBQ *ALL, *ALRTBL, *AUTL.

2. Work with Objects

Type options, press Enter.
2=Edit authority 3=Copy 4=Delete 5=Display authority
7=Rename
8=Display description 13=Change description

Opt Object Type Library Attribute Text
2 QBATCH4 *JOBQ QGPL

3.
Edit Object Authority



Object . . . . . . . : QBATCH4 Owner . . . . . . . : QSYSOPR

Library . . . . . : QGPL Primary group . . . : *NONE

Object type . . . . : *JOBQ ASP device . . . . . : *SYSBAS



Type changes to current authorities, press Enter.



Object secured by authorization list . . . . . . . . . . . . *NONE



Object -----Object------ ------Data-------

User Group Authority O M E A R R A U D
E
QSYSOPR *ALL X X X X X X X X X
X
QSPL *CHANGE X X X
X X X
*PUBLIC *ALL X X X X X X X X X
X


Bottom
F3=Exit F5=Refresh F6=Add new users F10=Grant with reference
object
F12=Cancel F17=Top F18=Bottom



in this example, if I wanted to restrict everyone from QBATCH4 I would
eliminate *PUBLIC.

Ray Bassett













Iseries - 820
 
Well, That can be prevented in the OS/400 itself with user security, in the
user-class value (*USER, *SECADM, etc.). If there's no reason they can't be
changed to *USER then do that. Some shops are implemented with way too much
open authority to users.

Another, more to the point, is the SPCAUT() value for the user profile. The
value (*JOBCTL) has to do with various changes to jobs including that one.

But be very careful before changing this yourself, depending on your OS
technical level. Even me, I haven't had to do this in this way (almost all
my users are restricted to user menu options), and by the way, someone more
familiar than me with the sys-admin and operator menus for JDE might know a
way to this through those.

- Alan

----- Original Message -----
From: "cbower" <[email protected]>
To: <[email protected]>
Sent: Monday, June 09, 2003 4:00 PM
Subject: RE: Posting Jobs
 
Setup objet level security on the JOBQs. Using Authorization list will
simplify the process. We have one JOBQ for finance and one for distribution
with authorization list attached to it.

Nandan Shah
KASP
JDE A7.3 Cum 11



At 13:00 09/06/2003 -0700, you wrote:



A 7.3 Cume 11
 
Back
Top