nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

error in iwjoberrors.log

nirali

Following comment is in iwjoberrors.log
"[Fri Oct 24 00:29:05 2008] Could not begin submit in (0xa6c6e5): error 2440"

Whats this a6c6e5 ? Is the job id ? I converted it to decimal from hex and used "iwgetwfobj" , but coulod not find object. I tried to use iwevets" command also, but that also did not give any result.

How to figute out this number 0xa6c6e5 ?

Where can I find details of error 2440 ?

Thanks

Find more posts tagged with

Comments

ISCBorisB

Following comment is in iwjoberrors.log
"[Fri Oct 24 00:29:05 2008] Could not begin submit in (0xa6c6e5): error 2440"

Whats this a6c6e5 ? Is the job id ? I converted it to decimal from hex and used "iwgetwfobj" , but coulod not find object. I tried to use iwevets" command also, but that also did not give any result.

How to figute out this number 0xa6c6e5 ?

Where can I find details of error 2440 ?

Thanks

It seems that you already had Submit operation in progress when you've tried another one. In such case Submit request
re-tries 'submit_retries' number of times, default is (used to be?) 61 - once a second for over 1 minute. If the limit is exceeded
iwserver throws 2440 - "Operation already in progress".

0xa6c6e5 is probably an Object Id of the Branch where all this activity is taking place. For once try to ignore this Hex Object IDs
obsession of yours. 99.99% they would be useless anyway, even if you can figure out what they represent.

nirali

I did not try or retry any submit operation. I just saw this entry in iwjoberrors.log file.

What you mean to say is " user had alreay started submit operation and then he started another submit operation immediately, right ?" Now usually it takes only couple of seconds for submit operation to finish, but for some reason the firsr submit operation laster longer and in case of failure (unable to submit) it keeps retrying for 1 minute every second, right ? Now if second submit operation is performed after 30 seconds of first submit operation, then what happens ? (1) it throws error 2440 or (2) it retries for 30 seconds more after the first operation is complete or (3) it starts the submit operation after first operation is complete and lasts another 60 seconds ?

Now I am not obsessed with object IDs, but I am trying to figure out what this number stands for ? As you said this is object ID of branch where this is taking place. But how did you find that out thats what I wnat to know. I am not getting clear and satisfactory answer and thats why I keep repeating same question.

Thanks for your help

Adam Stoller

I did not try or retry any submit operation. I just saw this entry in iwjoberrors.log file.

What you mean to say is " user had alreay started submit operation and then he started another submit operation immediately, right ?" Now usually it takes only couple of seconds for submit operation to finish, but for some reason the firsr submit operation laster longer and in case of failure (unable to submit) it keeps retrying for 1 minute every second, right ? Now if second submit operation is performed after 30 seconds of first submit operation, then what happens ? (1) it throws error 2440 or (2) it retries for 30 seconds more after the first operation is complete or (3) it starts the submit operation after first operation is complete and lasts another 60 seconds ?

Now I am not obsessed with object IDs, but I am trying to figure out what this number stands for ? As you said this is object ID of branch where this is taking place. But how did you find that out thats what I wnat to know. I am not getting clear and satisfactory answer and thats why I keep repeating same question.

Thanks for your help

Save up some money - pay to go to an Interwoven instructor-led class - and ask them all the questions you want about object ids (just be prepared to refund money to everyone else in the class who has to sit through it all) - or learn to let go - an object id is the id of an object. An object is an abstract concept - it could be a branch, a workarea, a file, an operation, a mole on the back of your right shoulder, whatever -- in this case, as in most of the other cases where you've asked about this - it simply d-o-e-s n-o-t m-a-t-t-e-r. The more you keep asking about it, the less likely many of us will bother to read / respond to your posts.

The question about how Boris determined that 2440 was "Operation already in progress" is a much more interesting question - and I can only assume it is because he's run into this before, as the error codes are not well documented.

ISCBorisB

I can only assume [...] he's run into this before

How did you know? Smiley Happy

scrollbar_Kclark.rptdesign

nirali

ok ok ok, no more Qs on object ID. (I dont like them anyways)

Its just because, I get to see them all the time in log files. So the first thing that comes up is " these numbers have got all the answers". I guess, if its so less important in debugging, then interwoven shd remove them from log files. That will help a lot of people who are getting confused beyond asking.

Thanks for help.

ISCBorisB

(1) it throws error 2440 or
(2) it retries for 30 seconds more after the first operation is complete or
(3) it starts the submit operation after first operation is complete...

None of the above. Subsequent Submission request (#2) tries immediately. Since there is a previous request active,
an attempt fails. #2 will then try again in one second and so on. If it succeeds on the 11th (for example) attempt,
fine. The Thread locks required resources and goes on it's merry way to Modify STAGING.

If however #2 does not succeed on 61 try (or whatever your 'submit_retries' is, it's configurable) it throws 2440 and
terminates