Re: JDBCR4 JVM Creation fails

There is no limit of jobs in the sub-system



Don Brown





From: "Evan Harris" <auctionitis@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 19/04/2018 06:35 AM
Subject: Re: JDBCR4 JVM Creation fails
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Hi Don

how many jobs are allowed to run in the SUBSYSTEM you submitted the job to
?
If you have a limit on the number of jobs in the subsystem that might
prevent the JVM job from being started as suggested by Richard.
Solution would be to change the MAXJOBS parameter to *NOMAX;
the number of jobs that will actually get into the subsystem would be
controlled by your jobqueue settings so that should not be a problem.


On Wed, Apr 18, 2018 at 9:10 PM, Don Brown <DBrown@xxxxxxxxxx> wrote:

IBMi Version V7R3 and current on PTF's
JDBCR4 version - not sure but I have downloaded again from Scott's web
site.

I have a service program that connects to a MS SQL server and retrieves

a

list of records, converts the results into json using yajl and returns

the

string.

If I run this from the command line it works perfectly.

If I call externally using XMLSERVICE it fails.

I have run the process in debug and in JDBCR4 the procedure start_jvm()
used to start the JVM , it simply calls the java method java.lang.String
with wwStr = s('Temp String'); which should start a JVM if there is not
already one running.

I have pasted the joblog below.

I have tried submitting the same process to batch using the same job
description (library list) and running under the same user profile and

it

completes normally.

I have looked at the dump files created but none of the content is
meaningful to me or for that matter indicates a reason for the failure.

Any suggestions most welcomed - I have been going in circles with this

for

quite a while!!

Java Virtual Machine is IBM Technology for Java. PID(15710)
Object domain or storage protection error for offset X'000000002B25B800'
in object XTOOLKIT PHPUSER 065558.
JVMDUMP039I Processing dump event "gpf", detail "" at 2018/04/18

07:50:46

- please wait.■
IBM Java[15710]: JVMDUMP039I Processing dump event "gpf", detail "" at
2018/04/18 07:50:46 - please wait.■
JVMDUMP032I JVM requested System dump using
'//core.20180418.075046.15710.0001.dmp' in response to an event■
IBM Java[15710]: JVMDUMP032I JVM requested System dump using
'//core.20180418.075046.15710.0001.dmp' in response to an event■
JVMDUMP010I System dump written to

//core.20180418.075046.15710.0001.dmp■

JVMDUMP032I JVM requested Java dump using
'//javacore.20180418.075046.15710.0002.txt' in response to an event■
IBM Java[15710]: JVMDUMP032I JVM requested Java dump using
'//javacore.20180418.075046.15710.0002.txt' in response to an event■
JVMDUMP010I Java dump written to
//javacore.20180418.075046.15710.0002.txt■
JVMDUMP032I JVM requested Snap dump using
'//Snap.20180418.075046.15710.0003.trc' in response to an event■
IBM Java[15710]: JVMDUMP032I JVM requested Snap dump using
'//Snap.20180418.075046.15710.0003.trc' in response to an event■
JVMDUMP010I Snap dump written to

//Snap.20180418.075046.15710.0003.trc■

JVMDUMP007I JVM Requesting JIT dump using
'//jitdump.20180418.075046.15710.0004.dmp'■
JVMDUMP010I JIT dump written to

//jitdump.20180418.075046.15710.0004.dmp■

JVMDUMP013I Processed dump event "gpf", detail "".■



Don Brown

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD