On the java client we use a ProgramCall to call a program
on the AS/400.
This program creates a userspace and fills it with information
to be read in the java client program (using system api's)
When the call has executed, the client java program uses
the Userspace class to read the created userspace.
This setup normally works ... in 80% of the calls being
made to the AS/400 program.
In the other cases we get a problem when calling the AS/400
program to create and fill the userspace:
-----------------------------------------------------------------
We get the following message in a QPWFSERVSO job:
-----------------------------------------------------------------
Message ID: CPDA031 Severity: 30
Message Type: Diagnostic
Message : Access or share mode conflict for object USP222468
in library GPL.
Cause: The requested access level or share mode conflicts with
an existing access level or share mode for object USP222468 type
*USRSPC in library GPL.
Recovery: Change the requested access level or share mode, or
wait until the current access level or share mode change before
trying the request again
The ProgramCall returns normally after some time, but when trying
to read the userspace we receive the following message on the
client:
com.ibm.as400.access.ExtendedIOException: Sharing violation occured.
at com.ibm.as400.access.UserSpaceImplRemote.read(Compiled Code)
at com.ibm.as400.access.UserSpace.read(Compiled Code)
at com.ibm.as400.access.UserSpace.read(Compiled Code)
at com.client.project.FunctionDeployment.readUserSpace(Compiled Code)
...
-----------------------------------------------------------------
Questions:
What is this QPWFSERVSO job?
Why does it put an exclusive lock on the userspace object?
Why don't whe have this problem all the time?
-----------------------------------------------------------------
Many Thanx for helping & responding
Geert Van Landeghem
geert_van...@msp.be
-----------------------------------------------------------------
Geert Van Landeghem wrote:
I think what is happening is that 1) you or something you call iscreating
USP222468 in library GPL. 2) Either right after 1)
or via some later request, you are looking at the data in that
user space. Most of the time, this will
"work fine" as long as only one remote PC Java client attempts to
create-and-fill this user space at a time.
However, my best guess is that you or whomever creates and
maybe accesses this space for you is always accessing it exclusively.
Thus, if all uses are exclusive, whenever you have
two clients accessing this data at the same time,
you'll get the message above, which is complaining
that it can't get the lock on the user space that "you" (or
someone you invoke) asked for.
Note that "two clients" here may well be "two Windows" on the
same PC, each accessing the data at one time.
But, suppose you check and find that the "look at it" operation
is getting a shared lock? How could this happen then?
You might also get it the message the "fill" operation hasn't finished
before
you send the "request to read it" operation down to the AS/400.
Especially if you have multiple clients involved, and you use a single,
fixed name to get the result, what you have is basically a race
condition in many cases. If the read comes down too fast,
before the "fill" completes, you "lose."
Larry Loen (IBM Corp knows nothing about this; don't blame it)
Apparantly, the problem occurs when:
1) a java client calls an AS/400 program which creates a userspace
2) this userspace is being read immediately afterwards on the
client...which generates the erros mentioned before.